Skip to main content

How to Prevent Product Paralysis

Does your company suffer from product paralysis? Product paralysis occurs when progress halts on improving or innovating a product. At some point, you've probably experienced:
  1. A product team can't agree on major product decisions, so they concentrate on minor bug fixes and enhancements that have little or no market impact.
  2. Bold product decisions are made (often by members of the team that just happen to wield the most influence at the time), but the decisions come under fire and are put on hold shortly thereafter.
  3. Team members don't buy into product decisions, so they undermine them, stall their execution, or just aren't motivated to be productive in executing them.
The most effective product managers - to the extent that company executives empower them to do so - employ three approaches to prevent product paralysis:
  1. Base product decisions on market understanding and marketing principles. Teams will not buy in to major product decisions unless they can make a compelling case for them. It's hard to make a smart product decision without understanding the market and the principles of marketing (which are often counter-intuitive).
  2. Involve the team in making product decisions. In the authoritarian model of product management, a product manager becomes an expert on the market, gets input from development on the technical feasibility of implementing new features, and makes unilateral decisions. In the organic model of product management, a product manager leads the process of collective product decision-making and arms the team with the market information and marketing principles necessary to produce quality decisions. A product manager applying the organic approach uses change management and decision facilitation to foster buy-in and to motivate the team to execute.
  3. Iterate on the research and development of products. Product teams will make mistakes. They will never fully understand the impact of product decisions on their customers until the team at least partially executes and tests those decisions in the market. Thus the team will and should revisit decisions. An effective product team leader helps the team confront risks and uncertainty quickly and in a disciplined fashion. Frequent iterations provide a systematic way of learning and of evaluating and revisiting product decisions.
Thanks to Joshua Duncan for helping me to refine my thoughts on the organic model of product management.


Larry said…
Roger, good points but a good product manager should recognize when a company or product line is heading towards product paralysis early. Identifying some of the causes for this ahead of time might avoid a slow down or stoppage of forward momentum. Signs that your are heading down this path would include a roadmap that looks like your first two indicators. The good product manager is going to be guiding the direction and informing the team about where the market and the product need to be heading. The sales process starts internally. If you cannot convince you own team that there is a need for change, trying to convince your market is going to be an uphill battle. Change is never easy but is necessary.

One other thought that you didn't touch on was where in the product lifecycle are you? This can greatly influence the next steps.
Roger L. Cauvin said…
Thanks for the comment, Larry.

Totally agree that internal change management is crucial to prevent product paralysis. It's important to keep in mind that "selling" a product roadmap isn't sufficient. There are important lessons to learn from Sharon Drew Morgen's concept, Buying Facilitation(TM).

I'm not sure I see relevance of the product lifecycle. At any point in the lifecycle, a product team is making strategic decisions about the product. The decision to maintain but not significantly enhance a product is itself a strategic decision. A subsequent decision to kill a product entirely is a strategic decision. To be effective and fully executed, these decisions benefit from at least some of the approaches I've enumerated, right?
Joshua Duncan said…

Great post and thanks for the mention!

I would add some emphasis to your point on how critical it is that the product manager understand how to influence change and decision facilitation to really be effective.

Also, they must really understand organizational dynamics to make sure that they are not only influencing the members of their team but the influences throughout the company.

In my experience, it is the hidden influencers that might not be directly involved in the upfront product decisions that if not sold on the direction can cause the biggest headaches down the road.

Thanks again,

Roger L. Cauvin said…
Joshua, you're absolutely right about "hidden influencers". Often, these influencers lie outside the product team, and their buy-in must also be facilitated.
Very good points .Can someone give me a definition of "Foster Buy-in?'
Roger L. Cauvin said…
"Fostering buy-in" means working with others to ensure they support - or can at least live with - the product decisions that affect them.
Unknown said…
3 great points, Roger:
1. Understand your market
2. Involve your stakeholders
3. Test and learn through iteration

I've just posted something on number one at:

Also Joshua is right on when he emphasizes the need for influence. See my post on being The Hand of the King:
Roger L. Cauvin said…
Thanks, Bruce. Don't forget the application of marketing principles as part of #1. Sometimes people understand the market but fail to apply the timeless, often counter-intuitive, marketing principles that must underlie sound product decisions.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Use Case as a Black Box

Consider the following use case: Purchase Items Actor: Purchaser Precondition: Purchaser types at least thirty words per minute and has a web navigation efficiency rating of at least 40. Postcondition: For the average Purchaser acting at full efficiency, the number of seconds elapsed is no more than 30 + 20 * n, where n is the number of items purchased. The name of the use case represents a functional requirement. What does the product do, or enable the user to do? Purchase items. What are we to make of the preconditions and postconditions? What relationship do they have to the requirements for the product? Answer: the preconditions and postconditions are the nonfunctional requirements attached to the functional requirement . Another way of expressing the nonfunctional requirement would be as an attribute and associated constraint: Usability: For a Purchaser who types at least thirty words per minute and has a web navigation efficiency rating of at least 40, it shall take no

Henry Ford's "Faster Horse" Quote

You may have heard the ( apocryphal ) Henry Ford quote: If I'd asked customers what they wanted, they would have said "a faster horse". Over at the On Product Management blog , Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations. Personally, I think the quote is great, but it's a matter of interpretation. The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are: You must ask the right questions to get valuable answers. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.) Nonetheless, I find the quote is helpful to combat "armchair product management" in the