How To Write a Product Problem Statement - Problem Statement Template
As the product world has evolved over the last few years,so has the way we define product requirements.
Outcome focus and idea discovery have taken over the way product managers lead their work.
Heavily written product requirement documents have become a thing of the past, and a new way of outlining problem statements has emerged.
It shouldn’t require several pages to get to the point of what has to be done, and most importantly, why the decision was made in the first place.
The key to a good problem statement is to make it easy for everyone to understand.
Problem Statement Template
Below is a template I like to use with my team that has proven to be of great success when outlining a problem statement.
Let’s break this down section by section to understand what this all means.
What problem are you trying to solve?
This focuses on the problem, not the solution. Instead of writing down “we need blue buttons,” focus on what the issue at hand actually is: improving accessibility in your product.
This changes the perspective of the issue at hand and gives you a more holistic view to start approaching the problem.
Most importantly, it doesn’t set a solution from the beginning. You know there is a problem (accessibility) but you aren’t defining how to solve it just yet.
Hypothesis
What might be the result if your team tackles this?
How might you start running experiments?
Remember, at this point it is all just an assumption and that is ok — experimentation will help you figure this out further.
Taking the example of accessibility above: By focusing on accessibility, we make the product more user-friendly and increase its usability.
There might even be the possibility of revenue expansion by tackling verticals that were previously not considered.
What value would it provide to our customers?
Always focus on whether or not this brings value to the customer, as it’ll help you narrow down whether or not the problem is worth solving in the first place.
It’s good practice for any customer-centric business to always keep this in mind.
What value would this provide to the company?
You may not know this right at the start, but it is important to consider as you expand on the problem statement.
Main Action Points
Often smaller tasks will spin off from an idea.
This could include some initial discovery work, like creating surveys, talking to customers, or creating a spreadsheet database with some information.
This is your opportunity to log all the tasks involved to drive this idea forward. When you have a retrospective, it’ll give you a chance to understand all the work involved (and also potentially what worked, and what didn’t work!)
Linked Documentation
If there’s any external documentation — perhaps those surveys, spreadsheets and interview docs that may have been created as a result, this is your opportunity to link to them.
This problem outline is your source of truth, so be sure to link all relevant documents in this space.
How do we measure success?
Alongside the problem to solve and the hypothesis, this is probably one of the most important parts of this problem satement.
If you have no way of measuring success and/or no initial base line, it is going to be tricky to identify if your efforts resulted in anything worth your while.
Idea details
You will also notice at the very top of the template there are some details, like status, owner, collaborators, impact and effort.
This template itself is part of a much larger product backlog with a dedicated workflow, so for organizational purposes it’s good to have these handy.
If you’re using a database, it’ll be easy to query certain data, like all ideas that have been reviewed and can be moved forward in the pipeline.
Why this problem statement template works
Having a simple template like this one gets your entire team — not just product — to think about outcomes and problems to solve.
It changes the conversation from “let’s work on this solution” to “do we understand what we are doing and why?” and establishes product-thinking throughout your entire organization.
What happens next?
This will enable your team to understand the problem and start running discovery and experimentation on it.
Once that is done, you’ll be in a position where you can decide whether this moves forward or not (and of course, why or why not.)If it does move forward, you give your team all the information they need to outline this further.
Be it with JTBD, user stories, specific technical requirements, or prototypes, your team knows what and why they are working on, what research was involved, and how the decision was made to proceed.
Is this just for product teams?
Of course not! I encourage any and all teams to use this framework to focus on outcomes. It doesn’t matter if you’re outside the product team and perhaps work in customer success or even marketing, this will definitely still help you pivot your way of thinking.
Hope you enjoyed this; thanks for reading! ✌️
Read also
Experience the new way of doing product management
