If you want to be a bad product manager, don’t worry as much about defining the problem as quickly finding the solution. Problems are usually very obvious and clear, and any time you spend dwelling on it is wasted time that could be spent on solving it. The sooner you start solving the problem, the soon you’ll have it figured out. How hard is it to define a problem, anyway?
If you want to be a good product manager, get a good understanding of the problem before you try and solve it. Product managers and many others unfortunately assume the problem is evident and jump right to solving it. However, ill-defined problems lead to ill-defined solutions.
Albert Einstein purportedly said that, given one hour to save the world, he would spend 55 minutes defining the problem and 5 minutes finding the solution.
One of the most important aspects of defining the problem is to “size” the problem properly. If you define the problem too narrowly, your possible solutions may be very limited and uncreative. If you define the problem too broadly, your solutions may be out of scope and irrelevant to the business context.
For example, pretend you are a product manager for a technology company which provides communication solutions for consumers. You are looking to identify unmet needs which your organization may be able to solve. This may seem very straightforward — simply talk with customers and prospects to identify unresolved problems, right? However, different definitions of the problem could produce drastically different solutions:
- Taking a very narrow view — “people have problems communicating using email” — would lead to a very specific solution. Google’s GMail was developed based on observed problems users had with organizing and effectively using email. The scope was intentionally limited and focused on email and email alone.
- Taking a slightly broader view — “people have problems communicating online” — would lead to a wider variety of different insights and potential solutions. Twitter and Facebook are two examples of solutions which fulfill the need to communicate online. They are different ways of communicating — not just email, obviously — though the focus is limited to web-based solutions.
- Taking a very broad view — “people need a better way of communicating” — would open up an extremely wide range of potential solutions, not limited just to the web. This could include any of the above examples as well as other solutions like OnStar and push-to-talk on mobile phones.
This is not to say that any one approach is better than the other. How you define the problem depends on your organization, your market, and your overall strategy. An automobile company may define the problem space related to transportation in a different way than a conglomerate whose products range from bicycles and motorcycles to airplanes and subway cars.
Going too far in either extreme may be unproductive and inefficient in many situations. Defining the problem too narrowly may inevitably only lead to incremental enhancements when broader innovations are desired. Similarly, defining the problem too broadly may produce irrelevant ideas which do not fit with the corporate strategy and which would never be pursued by the organization.
Product managers need to avoid the rush to write requirements and add features without having a clear understanding of what they are doing and why. Even problems which may seem clear can benefit from a fresh look and a new perspective. Qualitative research can help refine and redefine issues products are facing and uncover new ways to look at the market — and it need not take months of work and thousands of dollars to be effective.
As with many apsects of product management, extra time and effort up front defining the problem can save time and effort down the road. Framing a problem properly can help product managers balance their innovation efforts, focus research and customer understanding, and help clearly define their product and portfolio roadmap.
Jeff,
Good post. How the problem is cast will directly influence the solution. Scott Berkun talks about this in The Myths of Innovation. The example he gives comes from Scott Cook, founder of Intuit, the makers of Quicken. Cook realized that the greatest competitor wasn’t other software programs, but the pencil. Reframing the problem in this way (i.e., to compete with the pencil) allowed them to develop one of the most widely-used personal finance software packages out there.
Have a look at Chapter 9 of Berkun’s book.
Also, from a designer’s perspective, defining the right problem is critical. In an interview with Peter Merholz, Don Norman suggests that defining the problem one of the most important parts of the design. Don says in unequivocal terms:
“Do not solve the problem that’s asked of you. It’s almost always the wrong problem. Almost always when somebody comes to you with a problem, they’re really telling you the symptoms and the first and the most difficult part of design is to figure out what is really needed to get to the root of the issue and solve the correct problem.â€
http://adaptivepath.com/ideas/essays/archives/000862.php
Cheers
Good point about correctly identifying the problem. In addition, the good product manager will correctly identify the opportunity. There are many more problems than opportunities and the product manager is well-situated at the nexus of the business and technical worlds to identify the true opportunities.
Every problem solving situation involves a time stance. We find our time stance in the immediacy of the the problem.
Am I on fire? Roll on the ground. Get in a cold shower. Call 911.
Will I soon be on fire, run like hell, let the place burn down, but get out unscathed.
Might this place burn down, think about egress and fire suppression, spend the money to implement the preventative measures.
These examples illustrate the time stances: reactive, predictive, and proactive. These examples illustrate how the time stance controls the solution. These examples illustrate how getting to the proactive stance is important.
The EMS shows up, and you don’t have your medical insurance card, so off to the country hospital you go. Then, how will your family find you? No cell phone.
Ok, you’re across the street, now you have to call 911, no cell phone.
You are asleep in your bed dreaming of another wonderful day solving problems at the office. Actually, you never have problems at the office.
These last three examples continue the earlier examples. In the first example, the real nature of reactive problem solving reveals itself. There is always another reactive problem to deal with. The predictive situation eventually diminishes into a proactive problem. And, the proactive stance can successfully eliminate the follow on problems entirely.
Again, get proactive as soon as possible. Rushing is contrary to this goal.
As a product manager, you won’t see the opportunites if you are constantly putting out the fires.
Ooo, I like the way you think, Mr. Locke.
As always, we find ourselves returning to persona-driven design and use cases, the fountain of wisdom from which all good things come. . . in the near- to medium-term.
The black art of anticipating problems remains a black art; if I could articulate how to do it, I certainly wouldn’t as it is as powerful a competitive (and personal) advantage as exists in our trade/craft/profession.
Well, maybe I would if someone asked nicely, and bribed me with ham.
BTW – Great topic, Jeff – thanks for writing it up. You St. Louis guys are OK. And good idea to advertise it on Twitter.
bob
Great post, Jeff. You mentioned three view ranges: narrow, slightly broader, and very broad. Mr. Locke mentioned three stance ranges: reactive, predictive, and proactive.
I just wanted to add that it’s very helpful to have these views and stances in mind while identifying a problem. Exploring the entire spectrum of such views as they relate to the initiating problem as a whole is a helpful exercise in producing a comprehensive (correct) solution. It also helps in the understanding of what that solution does and does not do or where there may be other related or unrelated problems worth exploring.
Well said. I don’t know how many times I’ve responded to a feature request with: “What is the business problem you are trying to solve?” It really opens up the conversation and allows for a better solution.
@Tabita: Agree. In addition to opening up the conversation, having a clearly-stated problem statement also allows you to *shut down* an unproductive conversation.
“The problem we’re trying to solve is X. How does this idea we’re discussing directly address that problem?” If it doesn’t, it’s a great idea, thanks for contributing, and let’s write it over here in our backlog.
When there isn’t a clear problem statement, product managers (or other leaders) often have to resort to some form of “your idea doesn’t work because I said so” – and that does no good to your organization.
Jeff, great post. Though it’s implied in the post and in several comments, it’s important to remember that the problem (or opportunity – I like that word) should be described in terms of the market.
Too often I see problem statements that define problems customers are experiencing with a given product. That’s too narrow and misses the point of problem statements/definitions. Always think in terms of the market(s) you serve. -Michael
Good point, Michael. To add to that, problem statements shouldn’t be written from the company perspective either (“Our revenue and customer satisfaction are decreasing…”). It sounds obvious, though unfortunately sometimes companies get caught up at looking at the problems *they* are facing, and not unresolved problems in their customers / markets.
Jeff: good post, as always. However, now you’ve gone and done it – just how long does a product manager need to think about a problem in order to come up with the perfect answer?
The pressure to always be right can cause even the best of us to “freeze up” and not be able to make a decision. The longer we spend thinking about something, the more the pressure grows to make sure that we reach the “right” decision.
I’d add to your post a note to lighten up. Take enough time to reach what seems to be the best solution at the time. Then make sure that you keep double checking yourself as you move forward – just in case.
– Dr. Jim Anderson
The Accidental PM Blog
“Home Of The Billion Dollar Product Manager”
Sometimes, I am skeptical when a product manager asserts that they have ‘defined the problem.’ My questions may include:
– What the ‘error bars’ associated with your definition of the current problem? Is your definition based on historical data? Was it based on unreliable interviews and stale data? What were the misinterpretations of the folks summarizing the data? What are the unknowns?
– As a product manager planning for a new product that will not be launched for 6, 12, or 18 months, what are the ‘error bars’ on your definition of the problem in the future? At launch? At maturity? How will competitive offerings change the definition? How will world conditions change the definition?
I have found the phrase ‘boardroom logic’ may apply when product management asserts that they have defined a problem. Sometimes, the accepted truthfulness of the claims increases the more the claims are repeated.
Instead of using the term ‘defined, perhaps using the term ‘hypothesis’ may frame the discussion for a higher probability of success.
Since a hypothesis is intrinsically a testable idea that may evolve after testing, there is a wonderful opportunity to collaborate with other team members and discover new insights about ‘the problem.’
The first step of problem solving is alwasy about gaining understanding. Defining the problem is one way to do that.
In most cases those working on the problem don’t have enough information to understand or define the problem well. Most of the time they assume they do. It is important to always seek out more information. Information about the problem is the key to understanding it and defining it.
Thanks for you good ideas.
Nice post.
Listening to your market is a nice source to identify the correct mix of features which would ensure making of a successful product.
It becomes really important to not only identify unsolved problems of your market, but also prioritize them, before actually resolving them.
Key areas which needs to be considered while decideing which problems to solve first:
1. Does the problem require an urgent solution
2. Will solving the problem help you better your win:loss ratio
3. Are people willing to pay for you to solve their problem
I guess Product Management is the only profession which welcomes problem with both hands 🙂
I would also suggest that it is more important for product managers to identify the CORRECT problem to solve before spending so much effort defining it. You do elude to this a little in your article. A good example is “Popping the Why Stack” as touched up in the following article on applying design thinking to product management:
http://www.designfulthinking.com/articles/start-design-thinking-in-five-simple-steps/
Dear Jeff,
I appreciate your site. Thank you for your insights and guidance. I have also gained a lot of knowledge from the others who have commented here.
This is especially important in the midst of the financial crisis, when there’s a lot of bashing and cynicism towards performance evaluation, recognition, and inspirational efforts in the workplace. Just check any bar in lower Manhattan! It’s a shame.
As a VP leading over 100 salespeople, I’ve found that the hard fact is that QUALITY performance recognition works. Not just for morale, but in dollars. I have been using a couple of different tools for retaining
good people and bringing in the larger sales figures. A#1 is Design Your Inspiration
( http://www.dyi.successories.com ), intelligent, customizable with any words or great quotes (like the AMAZING one you mention from Einstein) you want to use. Framed art photography prints.
Again, the quality of these, and the MEANING emparted makes them highly effective for me. So while the cynics shed tears in their beers,
we’re laughing all the way to the bank! Thanks again. Jim
Thanks a lot to all of your guys for your teachings.
Good article and great comments too. Thanks for the interesting read.