Category Archives: Product Management

General IT, Product Management, Software Development, Teams

The two warring tribes within small business IT and software development and how to make peace

Leave a comment

Lisa Jaspers LinkedIn article struck a chord. She identified a huge issue that affects any small business IT/Development team that is tasked with BOTH maintaining existing systems as well as facilitating new product development.

In small companies, usually a single team has to do both existing system maintenance as well as new product development. This duality can  create a “two warring tribes” atmosphere. And as Lisa states in her article, you can’t just add roles here and there and solve the problem.

Sometimes the warring tribes exist inside the individual as they feel pressure from both camps to do different, yet equally urgent, work. Sometimes they exist as 2 groups of developers within the same team, competing for resources, priority, or direction.

Warring Tribe #1: Maintenance Tribe

Your existing systems, software, and products carry the company. They pay the bills, enable the work, and serve the customers.

But, over time, these systems require patches, bug fixes, updates, security changes, regulatory modifications and customer feature additions. Maintenance, support, and caretaking of these systems can consume a small team.

It’s like your company is in a boat in the middle of the ocean and the boat is made up of the existing systems and products. Any leaks or issues with the boat have to be corrected quickly lest you risk the boat beginning to sink. This is existing system maintenance. Yeah, small leaks can be ignored for a while. You can hire more folks to ‘bail water’. But in most cases existing system maintenance issues will soon trump new product developer in time and dollars.

Warring Tribe #2: New Product Tribe

New product development, on the other hand, is like building a new boat, while you’re still in the old boat, without sinking either boat.

When there are existing product or system issues or urgent features needed for the paying customers, you pull your team out of the new boat and back into the old boat. When existing maintenance furor dies down the team heads back to the new product and continues on. This back and forth focus shift is more expensive than you think. It causes both tribes to suffer. And it causes the results of both tribes to suffer.

Influences on Tribal membership

When I was a developer, getting picked to go build the “new thing” was special. It was like getting drafted in the NFL. Or like getting asked to the prom by someone you really liked. You were desired and worthy of helping accomplish an important initiative for the company.  Getting “left behind” to continue to maintain systems was not as desirable. You got to sit out the prom. No dancing for you.

However, for others, who had key hands in building an existing system, they wanted to stay behind and continue to nurture their ‘baby’.  They had little desire to go and build something new.

In a large company setting, an engineer may get the flexibility to choose. And some engineers can do either.  But in a small company setting, you don’t always get that choice.

The same tension between  doing something new, or staying behind and shepherd something current, also affects project managers, QA folks, DBA, system admins and other roles within the team.

Ways to make peace

1. The two team approach

If you have enough resources you can divide and conquer to some extent. Pick those who want to go and help out with the new thing and allow them to focus on that exclusive, leaving those in favor of maintaining the existing systems in place.

I have seen this method work well.  Small, competent, focused teams can make progress very quickly. In the end, this is probably the most desired approach as Lisa Jasper shares, “because product development is such a different mindset“. A dedicated team can focus on new tools, new processes, different vendors and the different mindset needed for new product development without distraction.

2. Bring in the reinforcements

Another approach, if your new product development takes too many of your resources is to strategically contract for necessary  bug fixes and feature work on existing systems. Using this approach can help minimize cost, focus effort on only the most important issues and help keep you from ‘gilding the lily’ on existing system improvements.

If your existing systems have a lot of baked in technical debt the outside, tactical contractor engagement may not make sense. The success of this approach hinges on finding a reliable contractor who is familiar with your tools/framework/languages or systems. If this is the case then tactical contractor engagements can be very useful.

The success of this approach hinges on finding a reliable contractor who is familiar with your tools/framework/languages or systems. If this is the case then tactical contractor engagements can be very useful.

3. Bring in another army

If your team is small and they don’t have the experience or knowledge in the  domains of the new product then you can consider outsourcing the new product development.

In one engagement, in the earlier days of the app store, our team was building and maintaining web applications and needed an iPhone app built. Our team knew databases and the languages and frameworks we used but none of us had any real experience with iOS or ObjectiveC. So after some research and comparison shopping, we went with a third party company that specialized in mobile app development to develop the app for us. If your new product need is specific enough this method can work well.

If your new product need is specific enough this method can work well.

4. Refactor

Another approach that is not as glamorous, is to refactor existing products. This is especially true in software. In software, refactoring refers to the process of re-structuring software code to improve its operation and add or take advantage of new features that could not be done in the prior state.

If your new product needs can be broken down into smaller more atomic features, it may be possible to use your existing team and refactor your current product to add certain aspects of what a new product would bring. In the end, this may be a less costly approach overall and bring incremental improvements online faster.

Pass the peace pipe

There is no one size fits all solution.

Each company and situation are different.

By taking the time to contemplate some of these options you may be able to come up with a new and creative approach that will enable you to deliver a great solution within the constraints of your team and budget. The strengths of your team, time to market needs and existing product structure all influence this type of decision.

But in the end, recognize the pulling forces between the two tribes and the different mindset required for new product development. If you do this you are well on your way to a more successful engagement.

Development, Product Management, Software Development, Teams

One simple method to improve the design of your next software app

Leave a comment

The late Stephen Covey, in his seminal book “7 habits of Highly effective people“, wrote that one of the 7 habits is: “Seek first to understand, then be understood”.

An effective way to “seek first to understand” and  communicate with someone is to put yourself mentally “in their shoes”. This is the essence of the habit Stephen Covey introduced in his book.

In High School debate, participants prepare to argue both sides of a presented issue. This means a debater has to thoroughly research, understand and prepare cogent arguments for both the negative and affirmative sides of the issue.  The debater has to put themselves in the shoes of both a supporter and detractor of the issue. The best debaters do this well.

This same metal exercise can also improve your next software application.

Key Mental Exercise

By changing mental viewpoints and analyzing the software project from the new point of view, you can become aware of new issues to solve or new opportunities and features. You can do this regardless of your role on the team.

This exercise helps prepare you for the client meeting, that big design review or the next sprint planning session. It can help you work more closely with the product owner and improve your design and plan.

If you are one of the general roles of a project team, forcing yourself to mentally assume the viewpoint of the other roles in the software project will improve communication, understanding, planning, and results.

Forcing yourself to assume the viewpoint of other roles in a software project improves results. Click To Tweet

7 viewpoints of a software project team

Here are seven viewpoints you can use in your mental exercise:

Designer

The designer creates the look and feel, screen flow and color scheme and page layouts.

Designers are concerned with creating a compelling user experience in a style that complements the genre and use of the application. Style, simplicity, cognitive load, and utility are  key concerns the designer has.

If you are not the designer, you can consider methods to express style, or improve the usability of the app.  Realize there are many opinions that influence the aspects and implementations of design. Many times there is no one right answer. The designer has to arbitrate these, sometimes conflicting, opinions.

Developer (coder)

The developer is the person (or team) actually doing the coding of the application.

The coder has to worry about the execution environment, standards, tools, compatibility across consumption devices, security, language implementation, performance and 3rd party services, code libraries and API’s that will be used.

To put yourself in the shoes of the developer, consider the job of a translator, translating one language to another. There is a lot of work  and knowledge that goes into translating a language. Nuances such as tense, idiom, gender and the like add complexity as well. That’s essentially what a developer does, translating the requirements and desires of the team into software, but also with a lot of other constraints.  Many of the constraints coming from the environment and devices that have to run the app.

Project Manager

The project manager is responsible for schedule and resources.

Their big concerns are resource utilization, schedule, milestones, reporting, test results and barriers to completing the tasks. And, if the project manager doesn’t have direct reporting control of the resources, their job is much more difficult.

To envision their world, think about being the director of an elementary school orchestra. They attempt to get all the band members set up with their instruments and music, on key, and on tempo so that what the orchestra plays will actually resemble music.

Owner

This is the person who is funding the development. The business owner or VP who is sticking their neck out (and budget) to get the project done.

To think from the owner’s frame of reference, consider making a large purchase with your own money. Writing a big check out of your own account always gives you pause. It motivates you to thoroughly investigate the value of the purchase, the terms, guarantees and warranties and lifetime costs and service. You don’t write big checks out of your own account without sufficient reassurance that the purchase is a good one. Thinking about the owners situation in this manner helps you better evaluate the value proposition, return, and on-going or hidden costs. All of which are key concerns for the owner.

Customer

The people who actually pull out their credit card and pay for and use the app you are creating.

They will have lots of needs and questions. Why should they buy? How will they realize value? What will their pain points be? How will they consume the app?

All of these and may more questions will have to be answered in order to produce a product that is valuable and has utility for the customer.

Competitor

Consider those companies with products already in or directly adjunct and selling to the market space you will be in.

What are the pain points of the customers of your competitors? What is the competitors unique value proposition versus that of the app you are building? Why would customers potentially buy from your competitor and not you?

Answering these questions will provide greater clarity about the market position, value proposition and relationship to existing competitor offerings.

Maintainer (another developer)

The maintainer is the poor souls who come after the initial release to clean up after the parade and maintain the app and system that was created.

What documentation will they need? How can you structure the app code to improve maintainability?

The maintainer will be the person fixing bugs, adding features and making other needed additions and improvements. Making their life easier through well architected and written code, template based screen layouts, comments and a software spec will speed maintenance activities lowering long-term cost of ownership.

Summary

If you spend a little time, thinking about your project from the viewpoints of the various roles, you will be a better team member, facilitate better communication among the team and make the project go smoother and improve the results.

Work on assuming the viewpoint of others to more deeply think about your application, improve your results and reap the rewards. And, who knows, you might make it a habit.

Disruption, Product Management, Small Business Growth

10X thinking and your products

Video Leave a comment

Is your industry beseiged by new startups and aggressive offerings from other competitors that leverage out of the box thinking?

Have you gotten into a rut of incrementalism when it comes to your product development?

Are your primary customers being wooed by next generation experiences while you deliver previous generation products?

Recently at the “Mind the Product” conference Ken Norton, Product Partner of Google Ventures, gave a talk entitled “10x Not 10%, Product Management by Orders of Magnitude” that will help.

The video presents ideas that can help break your product thinking out of the a rut and should be considered for your planning and strategy discussions.

In the presentation, Ken provides a framework of thinking to shift and broaden your mindset when it comes to future products and services. He makes a great case that incrementalism will get you totally disrupted. Using a rich tapestry of historical examples that many in the U.S. are familiar with, Ken makes a compelling case for integrating 10x thinking into our product development and management processes. I believe the framework can benefit companies that embrace these ideas. It can be one weapon in your aresenal to help deal with the rapid pace of innovation and change in your market. And, it may help your company be a disruptor, instead of a disruptee.

Martin Eriksson, over at MindtheProduct.com has a nice summary post of the presentation.

Ken’s own blog post is here if you prefer his written version.

The video is worth the 37 minutes.