Measuring business value of feature requests
How do you measure business value in feature requests?
The above question was posted on the product management subreddit a few days ago — and next thing you know, we have ourselves another blog post!
Here’s how the original poster described their current problem:
There is quite a bit to unpack with the question itself, so I’m going to break this down into several buckets of thoughts.
From “feature request” to “feedback”
I’ve said this before, and I think it is worth repeating: stop handling ‘feature requests’ and start taking in feedback.
The change in wording will allow you to refocus how you manage things and carry conversations with others.
A “request” implies that there is either an approval or dismissal of what is being requested. In turn, this means that there is no conversation happening.
A piece of feedback, however, is not to be accepted or dismissed — rather, it’s a conversation starter. This means that you can now start asking questions like why and what problem are you trying to solve, giving you a different perspective as to what the problem might be and how to approach it.
In the words of product leader Bernhard Hecker:
Feedback is more than a request. All feature requests are feedback, but not all feedback is a feature request, like all bananas are fruit, but not all fruits are bananas.
If you look at all the things your customers say about your product, there will be a lot more feedback that may be useless or super helpful, than if you look only at feature requests. If customers tell you that they love your product — without telling you why or what in particular, you (and your team) may feel well and enjoy that, but it will not help you build the next awesome thing that delights even more customers.
Your backlog is not a list of feature requests
Your backlog is not a list of feature requests, or tasks, for that matter. You do not simply build things because someone asked you to, you build things because they have a purpose and solve a problem.
As a product manager, you will find there are actually 3 backlogs:
The feedback backlog: This is where all feedback goes. The feedback here is connected to your product backlog via the concept of problems to solve.
The product backlog: This is your problem space. This is where all new ideas go to be understood.
The development backlog: Where all approved and validated work from the product backlog goes. No new improvements or solutions should be in this backlog without previously having gone through the product backlog first.
All of these backlogs are interconnected. Feedback is used to help support and find new problems to solve, and all problems to solve are validated before being passed to the development backlog for implementation.
Not all items from each backlog will necessarily make it to the next. This is where you triage and nurture items so that you have all the information at hand before moving items.
Your product backlog is not a list of features
With that in mind — stop treating your product backlog as a list of features to build. If anything, your product backlog is a list of problems to solve, and not every problem has to be solved.
So where do you get started?
For every idea on your backlog, make sure that you’re answering the question, what problem are we trying to solve?
This will help you focus on the problem space rather than jump straight to the solution. For example, if you write in an idea as “Let’s build a Salesforce integration” — how do you know what you are actually building and what that looks like? Do you even know what your customers have said about needing said integration?
A good product problem template will help with that and help remove some of the bias that stating solutions brings to the table.
Focus your work with objectives
When it comes to prioritizing, add focus to your work with the use of objectives and key results.
OKRs come from the top (at the company level) and network down towards each team. As part of the product team, you’ll have certain objectives you want to meet, and those objectives will help identify which initiatives you should be working on. If you’re looking at a potential initiative that do not meet your current objectives, it’s a distraction.
I just gave a talk on prioritization frameworks at Product School and Future Works, and the follow quote by Marty Cagan rings very true when it comes to knowing where to start:
Prioritizing isn’t the same as having focus. You can be endlessly adding inputs to weighted scoring and never really achieve anything. But having the right focus through your vision and objectives will actually allow you to prioritize better.
Focus what you do. Do it intentionally, do it with purpose, and do it with direction so you can build great products.
Identifying desired outcomes
Now down to the OP’s question: To identify if something gives you the desired outcome you are looking for (ie, will this give me the business value I am looking for?) I will forever be recommending Teresa Torres’ Opportunity Solution Tree.
The OST is an incredibly useful tool to help you identify and visualize potential solutions and opportunities that can give you the desired outcome (the objective,) with the initial premise that no idea is better than the other until you have identified all potential solutions and ran experiments. It’s my favorite way of running discovery.
It’s important to keep in mind though — the question will only truly be answered if you understand all of the following:
What is the product’s vision and mission
What your problems you are trying to solve
Why you are trying to solve them
What value they bring to the user
What outcomes you are trying to reach
How you will measure success
There is no single framework that will answer all of this for you… which leads me to my next and final point.
Frameworks suck
Prioritization is not a linear process, and a framework will not help you figure out whether something has business value or not.
Frameworks are there to help foster conversations and help frame the information you have from your discovery process, but they are not there to make the final decision for you.
Thank you for reading !