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.
A product problem statement is crucial in bringing products to market that consumers not only need but love. This can be a complex process, especially when working on a new type of product or aiming for a new demographic.
But a product problem statement may be pivotal in streamlining the process and guiding your team in the right direction from start to finish.
The product problem statement aims to identify and clarify issues affecting your customers in simple terms. By the time you complete the statement, you should have a tight grasp on the customer experience you plan to deliver, whatever that may be.
Ensure you set up the problem and explain how the solution will impact buyers without jargon or unrealistic ideas. Focus on the practical ways that your product will impact customers.
Your team and stakeholders should be able to understand the statement without in-depth knowledge of the production process. Otherwise, you risk wasting time on explanations — time that you could be devoting to development instead.
A well-considered, well-written statement will empower your team to solve the targeted problem. And if you’re releasing a new product for a different audience, your statement will help you make sense of your new buyers.
It can help you see a problem, and your solution, through your target customer’s eyes. That may prevent oversights and missteps that waste time down the line.
With a product problem statement, your team may find staying on track and delivering a solution to customers easier. Create a statement with care, and you will be in a better position to make key decisions that determine the product’s direction and eventual success. It will help your team align and work towards their shared goal more efficiently.
Your product problem statement should include the following elements:
Establishing the problem is the most essential element of a product problem statement. Comprehensive research into your customers and the market’s top products will help you get this right.
But take the time to explain the problem without rushing to discuss how your product will solve it.
Consider the causes of the problem you want to solve. Are existing products too expensive for most customers in your target audience? Are they too limited? Has the problem gotten little attention?
When you understand the context of the problem, your team can assess the impact accurately.
Think about how the problem prevents potential buyers from achieving their goals as efficiently as they should. Think about how that affects their revenue, reputation, and market position.
Thorough research could reveal that even a minor problem has stronger ramifications than expected. Solving it may improve the customer’s life in a noticeably positive way.
Here are two examples of solid statements:
“Users struggle to organize projects on the go with current project management apps. Existing apps lack collaboration features, are hard to use on small screens, and waste more time than they save.”
“Auto shops have no simple way to find suppliers selling components for specific cars in their area. They spend too much time scouring search engines for the components they need, wasting time they could spend on generating revenue.”
Product teams can use the problem statement to make smart decisions throughout the development process, from ideation to launch.
A product problem statement can act as a statement of intent to refer to at each developmental stage and can help the team stay focused when new possibilities emerge. For example, if fresh ideas threaten to take a product too far from solving the problem, the statement will serve as a guiding light.
Team members may feel better placed to make their own choices when they have a product problem statement to work from, too.
An effective statement can also inspire teams to deliver a product that customers genuinely need. It’s not another generic release to add to the pile. It’s not a pale imitation of another, more effective product. Instead, your product is something with real value and purpose.
Additionally, a well-written product problem statement empowers teams to prioritize features and functions. For example, a proposed addition may add aesthetic appeal to the product, but it offers no practical purpose.
A guiding statement will make prioritizing those elements that help solve the customer’s problem easier. This helps reduce the risk that the finished product misses its target and leads to disappointment.
And let’s not forget — a clear problem statement lets teams measure success. You can study the product’s performance and feedback to identify how effectively it solves the problem that inspired it.
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.
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.
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.
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.
You may not know this right at the start, but it is important to consider as you expand on the problem statement.
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!)
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.
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.
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.
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.
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! ✌️