Skip to main content

4 Problems Companies Face in Making Product Decisions


Why is product management important?

Whether or not they employ product managers, companies make daily decisions about how to develop, market, and sell their products. As they make these decisions, companies typically face - or are trying to overcome - four general problems.

The Problems


Products don't provide value to prospective buyers and users.

Products that don't deliver value generally don't succeed in the marketplace. Value comes from solving problems that prospective customers face. "Cool" technologies and feature-laden products, if they don't help customers solve or avoid compelling problems, don't provide value that lead to usage or sales.

Effective product management identifies a set of prospect problems that drive an overarching value proposition, and it empowers the entire product team to deliver and communicate that value.

Developers don't know what to build, and why.

Developing a great product requires a shared understanding, not only of what the product should do, but why it should do it.  In some cases, developers field varying - even conflicting - feature requests from sales and other colleagues and aren't equipped to prioritize them in a sound manner. Moreover, when developers don't know the motivating reasons for implementing product features, they are unable to fill the "gaps" and make the best judgment calls when questions about appropriate product behavior arise. Some developers aren't as motivated to work on products or features unless they recognize the value to buyers and users.

Great product management works with designers and developers to create a shared understanding of the product requirements, which are the least stringent conditions that must hold to solve or avoid the problems.

Sales and marcom can't consistently
articulate the value of products.

When sales and marcom don't have a thorough understanding of buyers and users and the problems they face, it makes it difficult for them to generate and convert leads. In such an environment, sales and marketing messages lack the clarity and consistency needed to foster brand awareness and perception of value.

The best product management develops crisp value propositions, consistent with timeless marketing principles, that sales and marcom can use in messaging prospects.

The process of learning the market is slow and unreliable.

The initial business model for a product is a set of hypotheses. For any particular product, some of these hypotheses almost invariably turn out to be wrong. Guesses about what will appeal to the market may reflect our peculiar personal preferences and not rest on a solid foundation. In other cases, prospects themselves lead us astray, requesting features they'll never use.  The marketing tactics or sales channels we thought would be the most effective don't meet our expectations. 

Companies learn these lessons over time, but often in a painful and expensive manner.  Great product management immerses itself in markets and employs iterative feedback loops to test and modify business model hypotheses, thereby producing more educated hypotheses and quickly discovering mistakes.

Final Thoughts
These problems have many manifestations.  Moreover, as with all problems, we can ask "Why?" and determine problems further up the problem chain.  These four problems ultimately lead to less revenue, wasted time and money, and frustration.

In the next entry, we'll explore the ways that companies make product decisions as they experience, or attempt to address, these problems.


Eric said…
A Great read!! Thanks.
Unknown said…
Nice and concise Roger. I'm sharing this with my team as a healthy reminder.
John Peltier said…
Good post, Roger! It's always helpful to start with the problem statements :)
Unknown said…
You make a good case for product management in terms of improving business results.
Roger L. Cauvin said…
Thanks, Eric, John, Bruce, and all.

It struck me that, while thought leaders have written much about the practice of product management, I hadn't seen a concise enumeration of the problems we're trying to solve.

These problems are just hypotheses based on some executive interviews and my observations over many years. I'd love to hear other perspectives.
Unknown said…
Let me see if I understand your question, Roger.

Our everyday job is to solve market problems, of course, but I think maybe you are thinking bigger than that.

I would say that we get hired and judged in the end by whether we solve business problems for our organizations. There is a fairly standard list of these. Often it just comes down to 'grow revenue,' but there are others like 'increase market share,' 'capture a new market,' 'increase renewals,' 'improve engagement,' or 'generate referrals.'

These kinds of metrics movers are what the executive team wants to see and what justifies our salaries. And I think Job 1 for a new PM is to align with his/her executive team on which 2-3 of these metrics are most important to move. It's much easier to make product decisions when you know what are trying to achieve.

Is that what you were asking?
Subramanian P said…
Nice post, clearly communicated...
Roger L. Cauvin said…
Bruce, effective product managers understand the markets for their products and manage products that address problems in those markets. But my question in this blog entry is what problems product managers solve, not which problems their products solve.

It's easy to say that most companies face problems with revenue not meeting its potential, failure to penetrate desired markets, or lack of engagement or referrals. In most cases, every single person in the organization plays a role in addressing these challenges.

But some slightly lower-level problems are more squarely in the purview of product management. The blog entry attempts to identify and describe those challenges.

Sure, a product manager should align with the executive team on success criteria and metrics. But to what end, short of the revenue, renewals, engagement, or referrals that every member of the organization has a place in maximizing?
Unknown said…
If you are referring to the 4 problems in your post above, I agree, they are primarily the responsibility of product management. Is that what you meant?

I would still say that questions like "what to build" or "how to deliver more value" are secondary to questions like "how to grow revenue" or "how to penetrate a market."
Roger L. Cauvin said…
Sure, Bruce, these problems are not the highest in the problem chain. Let me explain.

In every inquiry into problems and goals, we can keep asking "Why?" until we reach the root problem. In the case of consumer (and maybe even B2B) products, we'll usually end up at a core need such as health, sex, safety, or social acceptance. But when we choose a problem to solve, we typically stop short of solving the core need, because we can't comprehensively and completely solve such problems. Instead, we address needs slightly lower on the problem chain.

Similarly, most companies want to grow profits and revenue and penetrate markets. Failure to achieve these goals is a root problem that product management and the product team cannot fully solve. So we focus on solving problems slightly lower on the problem chain, such as the ones I've enumerated in this blog entry.

Indeed, in the conclusion of the entry, I wrote:

"Moreover, as with all problems, we can ask 'Why?' and determine problems further up the problem chain. These four problems ultimately lead to less revenue, wasted time and money, and frustration."
Unknown said…
Agreed. Though I prefer to drive priorities from those top business goals (even if I can't accomplish them with product alone). If I start by knowing that revenue is #1 (or market share or renewals or new customer engagement), then I can more easily answer the questions of what to build.

If are asking what problems we *solve* (completely, as you said), I agree, product managers are primarily there to answer those core questions: "how do we deliver more value" and the closely related "what do we build."

I think we agree. :)
Roger L. Cauvin said…
Really important point, Bruce! No matter what problems we choose to solve, we should always do so with an eye on the root problems that lie further up the chain. Otherwise, we lose sight of what really matters.
Karol McCloskey said…
If prod mgt (incl prod mktg) is talking with sales regarding prospects' needs and with support regarding current customer hurdles, it's a great start. Never easy but none the less muy importante - it's the only thing that separates you from the competition - if you prove you listen and learn, then develop solutions. Thanks, great post.
Roger L. Cauvin said…
Thanks, Karol. Conversations among the entire team - sales, development, marcom, support - are important to create a shared understanding of the value the product should provide. Product management can help identify what that value, rooted in solving market problems, is. Product management also can facilitate the larger conversation.

Sales provides useful input, but it can be fragmentary and not necessarily representative of the target market. See the pros and cons of the "customer wants" and "deal driven" methods of product decision-making.
Greg Prickril said…
Hey Roger,
Really enjoyed the post and agree with your points. It inspired me to think how I would respond to this question from an executive at one of my clients, something like "In your experience, what compels most companies to adopt product management?". BTW, there is probably a much bigger percentage of software shops in Central Europe that *do not* have product management than in the States. I've gotten this question before!

The most concise answer I could come up with is "These companies simply aren't getting the business results they expect now or fear they won't get them in the future." To your point about root causes, the problems you enumerate may contribute to this perception/condition. In my experience, when execs see product decisions consistently being made outside the context of business objectives, they'll eventually look for a way to increase the authority of a business-related function in the decision making process. Ideally, that function is product management. In this context, progressive companies are those that are achieving desired business results but realize their current setup isn't sustainable. All too often, companies are forced to make drastic changes because they weren't progressive (by my definition).

In practice, I think your points would clearly make good candidates for the next level of decomposition. How would you concisely answer the question I posed (do you see a single unifying concept to "package" your points)? Interesting thought exercise, I think!
Roger L. Cauvin said…
Greg, I think "failure to achieve desired business results" is a reasonable distillation high up the problem chain. At a slightly lower level is "team members make dumb product decisions". Good product management addresses this problem (and the four manifestations of it I described) by informing product decisions and by empowering team members with strategy.

I'm leary of focusing too far up the problem chain, because it obscures what product management can actually do to address the problem.

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

Is Customer Development Pseudoscience?

The “Science” of Lean Startup Lean startup practitioners embrace the scientific method, seeking the "truth" about what business model and strategy will lead to product success. We do so by: Formulating hypotheses Crafting and running experiments to test them Learning from the experiments Iteratively feeding our learnings back into revised hypotheses Sounds pretty scientific, at least in spirit, doesn't it? Yet this process actually neglects a key ingredient in the scientists' mode of operation. To identify what’s missing, let’s examine “customer development”. Customer Development Steve Blank is one of the pioneers of the lean startup movement. He introduced into the lean startup lexicon the term “customer development”. Customer development consists of sessions and interactions with customers to test hypotheses. For example, a product manager might interview a prospect, asking if she agrees with the product manager’s hypotheses about the problem

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware