I guess one of the turning points in my development process as a product manager was learning about problem statements. In 2013 I did an online course about “Design Thinking” where I learned about problem statements. This then prompted me to learn about assumptions and hypotheses, which form another set of tools within my toolkit.
In short, problem statements made me think much more about user or business problems to solve before jumping into features or other solutions. I found a great quote by Albert Einstein which illustrates this perfectly:
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
Albert Einstein
“Design Thinking” consists of five different stages: (1) empathise (2) define (3) ideate (4) prototype and (5) test. I’m finding myself spending myself more and more time on the first two stages, empathise and define. “Empathise” is all about understanding the needs of the people that you design a product or service for. The main idea behind the “define” stage is to frame problems as opportunities for creative solutions.
Tool 4 — Problem statements
What’s a problem statement? — A problem statement is a simple but great way to concentrate on the key problem(s) to solve, constantly asking the ‘why’ of a specific problem or need. One thing I realised when using problem statements for the first time, is an almost innate tendency to include a potential solution in the statement. I quickly learned — the hard way — that it’s important to refrain from including solutions in your problem statements and to restrict oneself to the user problem instead.
Standard formula:
Stakeholder (describe person using empathetic language) NEEDS A WAY TO Need (needs are verbs) BECAUSE Insight (describe what you’ve learned about the stakeholder and his need)
Some simple examples:
Richard,who loves to eat biscuits wants to find a way to eat at 5 biscuits a day without gaining weight as he’s currently struggling to keep his weight under control.
Sandra from The Frying Pan Co. who likes using our data platform wants to be able to see the sales figures of her business for the previous three years, so that she can do accurate stock planning for the coming year.
As you can see from the simple examples above, the idea is that you put yourself in the shoes of your (target) users and ask yourself “so what …!?” What’s the impact that we’re looking to make on a user’s life? Why?
What a problem statement isn’t? — A problem statement isn’t a solution in disguise. The idea isn’t to come up with a solution in your statement. In contrast, problem statements need to reflect your understanding of the problem that you’re looking to solve and serve as a communication tool in ensuring that other people are on the same page with regards to the understanding of a problem.
When to create a problem statement? — Before you start thinking about solutions, please spend a good amount of time understanding the problem that you’re looking to solve. Please, please don’t be intimidated by ‘HiPPo stakeholders’ who already know the solution and tell you to ‘just to make things happen.’ HiPPo stands for the “highest paid person’s opinion”, who based on their experience or status knows exactly what needs to happen and why.
Naturally, these people can well be right, but I do believe that an important part of our role as product people is to understand business or user problems and validate those before committing to a specific solution. You’ll find that having this thorough, real world understanding of user problems will actually help you significantly in getting your recommendations or insights across.
Characteristics of good problem statements — I found this really good breakdown of characteristics by Stanford’s d. school outlining the main functions of a problem statement. A good problem statement:
- Provides focus and frames the problem
- Inspires your team
- Informs criteria for evaluating competing ideas
- Empowers your team to make independent decisions
- Captures the hearts and minds of people you meet
- Prevents you from creating concepts that are all things to all people
- Should be discreet, not broad
Main learning point: Using problem statements to understand and validate the problems you’re looking to solve is a very important tool in every product manager’s toolkit. Critical product decisions like evaluating product ideas are helped enormously by a shared understanding of the specific problems to resolve.
