How To Define A Product Problem
As product management has evolved over the last few years, so has the way we write, spec, and develop features. Product teams are far more thoughtful and deliberate in the way they carry their work, with outcome-focused work at the forefront of solutions they execute on.
But what does it mean to focus on outcomes? And how do you begin spec’ing things in a different way?
That’s where defining your product problem comes in handy.
Say goodbye to old school product requirement documents, and say hello to your new product problem template!
The Product Problem Template
In the past, extensive product requirement documents (PRDs) were used to detail features.
This also meant that before one team received the template, another team had to write pages and pages of documentation, just to prepare the next group of people to add to that document and prepare to pass it on to the next group.
That’s not only a lot of work, but a lot of complicated specifications to read through.
This is likely still the case in many waterfall environments, but with Agile now becoming the standard for SaaS products, it’s time to change and adapt how we write specs.
The core tenant of Agile is that we focus on your customer and their needs, slowly releasing updates to our products based on their feedback.
Having a template that helps teams focus on those problems is key.
Step 1: Outline the “What”
The first step to defining the core problem is describing the ‘what’ – that is, what problem are you trying to solve.
By understanding the problem first, you remove some of the bias involved in defining the potential solution. This allows you to then focus on what the real core problem is for the customer, not what the perceived solution might be.
Now – if someone tells you they want a blue button, is the solution then to just change all your buttons to blue?
Dear product manager – you know better than this!
The actual problem: The user is colorblind and could benefit from more accessibility solutions added to your platform.
Step 2: The Hypothesis
The second step is to define a hypothesis. What were to happen if you fixed this problem?
It is ok to make assumptions at this point. After all, during discovery what you will attempt to do is rip that hypothesis apart and invalidate it as much as possible, allowing you to find potential loopholes and build a better solution.
Knowledge in what you don’t know is powerful, so don’t assume you know it all!
Step 3: What Value Would it Provide to your Customers?
To truly be customer-centric, you must always consider the value and impact anything you build will have on your users.
It might be difficult to formulate this at first, but it’s really important to have this written down to understand that this isn’t just about the value to your company or business, but to the people using your product.
Step 4: Measuring Success
Provided that you decided to move ahead with this, how do you know if you were successful once the problem is solved?
Product managers must always consider success measurements, whether this be in adoption, retention, or potential churn. Be sure to always link success when finding problems to solve, and that these are linked to your outcomes.
Step 5: Main Action Points
This is your opportunity to start outlining small tasks that may spin off the idea you are evaluating. This may include small discovery, interviews, or surveys you may run that will allow you to understand whether to move forward with this or not.
It’s always a good idea to log everything you do so that you can trackback decision-making, but also learn from the process of what worked and what didn’t.
Writing Specs
Provided that your initial idea assessed and passes the initial discovery process, now it’s time to add additional information and spec it. This will allow you to expand on some of the user experience and technical details that your design and development teams require to implement this.
There isn’t a one-size-fits-all, but some of the information you may choose to include are:
Feedback and Research
Any feedback that you have from potential or existing customers is a must. This may also include any feedback or research from interviews you did during your initial discovery process, or feedback relayed from your sales and other business-facing stakeholders. Make sure you include this and have it handy to support moving forward with the feature.
Mockups and Prototypes
This is where collaboration with your design team kicks in. Whether it’s a quick wireframe, mockup, or a fully-functional and interactive prototype, include this as part of your documentation. It’s key to have the evolution of various designs as well, so you can understand where you started and where you’re going.
User Personas
A user persona is a representation of the type of user who interacts with your product in a particular way. It isn’t something you build based on guesses and it isn’t fictional. Personas are based on research and qualitative and quantitative data collected through user interviews and surveys. It’s important to outline what persona the feature might affect so that you can design their experience and journey more accurately.
User Stories
As your specs begin to get more technical, it’s time to start writing user stories. Stories describe how particular personas will interact with the solution and what their expected outcomes are. Need help? No worries, we’ve got a gherkin template ready for you!
Additional Documentation
Use this to add anything that may be part of your decision-making process. This could include resources such as analytics, product KPIs, analysis of your competition and market research, and any additional user data that may help support solving the problem at hand.
Why this template works to define your product problem
Having a simple template like this one gets your entire team — not just product — to think about outcomes and problems to solve.
Here are just a few of the benefits:
Establish product-thinking
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.
For anyone looking to add product sense or product thinking to their organizations, being able to take a step back and think through things first, as well as understanding problems from the customer point of view is the first step to achieving that.
Remove bias and be more inclusive
It also helps remove bias from the solution and helps you direct the thought process to what the problem actually is, promoting insightful and dynamic thinking both for the person submitting the idea, but also for the product team.
Extend this to your sales, marketing, and support teams – and help them understand what it takes for a solution to be implemented. You can now respond to their needs more empathetically as well, as you all will have a more clean understanding about real problems, as well as raising undiscovered voices from team members that may not know how to communicate what their customers are experiencing.
Remember, the vast majority of users know they are having a problem, but they don’t know what the solution might be. This is your opportunity to engage and learn from your audience.
Solve the right product problem
Most importantly, it will certainly prevent you from solving the wrong problem and realize what every product manager wants: to build better products. There is a difference between adding features and solving problems – the latter highlighting user needs. The template helps identify the real problem and removes the need to jump to the solution, allowing you to achieve success and reduce the risk of business failure.
It also gives you the opportunity to fix problems in a unique way – providing you with a way to differentiate yourself from the rest of the market.
So the next time your team comes up with new ideas, always start with asking the question: what problem are we trying to solve?
It’s a great catalyst for a conversation! Talk it through, find insightful feedback from your customers, and always identify the problem first.
