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.”
“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.
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.
9 responses to “My product management toolkit (4) – Problem statements”
[…] RSS ← My product management toolkit (3) – Goal setting My product management toolkit (4) – Problem statements → […]
[…] Problem statements was the last product management tool I wrote about. Once you’ve defined and understood the problem(s) that you’re looking to solve, the next step is to validate ways to solve the problem. As a product manager, there’s a risk of jumping straight into solutions or features, without really evaluating the best way to tackle a problem. […]
[…] few weeks ago I wrote about identifying and validating problems. I’m now going to focus on assessing the opportunity related to solving a particular […]
[…] on the problem – I loved how Uri concentrated on the problem that you’re looking to solve. He talked about problem solving being a key driver for him and […]
[…] to quote Ash Maurya – “falling in love with the problem, not your solution.” Problem statements are an easy but very effective way to both capture and communicate your understanding of customer […]
[…] identify the most commonly voiced (or observed) unmet customer needs. This will in turn result in a problem statement or hypothesis to concentrate […]
[…] solutions.” Product people are problem solvers most and foremost, and Torres encourages us to start with the problem first and I like the definition of what constitutes a problem by the late David H. Jonassen that she […]
[…] a problem into a set of choices, tradeoffs or options. As product managers we often start with a problem to solve, and it’s important to frame the problem in such a way that it feels solvable or […]
[…] you define the problem you face. For example, through a problem statement you can figure out what the problem is and whether it’s worth solving. The next step is to […]