Prioritization is about Confidence, not Value
“Defining value: the most ambiguous word in product development” was the title of a post by Jeff Gothelf at the beginning of last year. If there was the battle for the most ambiguous term in product I’d have ‘value’ take second place to ‘MVP’ but as far as single words go, ‘value’ takes the podium.
In all honesty ‘value’ has made it on my list of trigger words.
It’s just so vague — what kind of value are you referring too? — “Business value”, “user value”, “customer value”, “organizational value”, etc — there are just so many different kinds.
Worse some people can get dogmatic about it, they advocate for one over the other — “customer value is the only thing that’s important” — “no, it’s about driving business value!”
“Value” is on my list of trigger words.Making matters more confusing as a Product Manager you are often told to “prioritize based on value” — but what does that even mean? What value? How is anyone supposed to prioritize on something so multi-faceted and ambiguous.
To give you a picture, let’s just break that down for a sec. With so many different types of value it’s hard to know where to start from…
Customer value
User value
Business value
Product value
Technical value
Market value
Sales value
…etc…
This is overwhelming for any product person let alone an Associate Product Manager beginning to learn the ropes.
Things get even messier when you break each “type of value” down into their components — aka the value behind each type of value.
Revenue
Cost
Retention
Useability
Desirability
Viability
Features
Functionality
Delight
Convenience
Ease
Resilience
Reliability
Availability
Sustainability
Tech Debt
Refactoring
Moral
Social
Safety
Health
Efficiency
Performance
….etc
I think you get my point. How is one ever expected to prioritize this way?
So what to do instead? How do you prioritize? How do you understand value in a less ambiguous way?
1) Focus on outcomes
If you’ve read the article by Jeff Gothelf that I referenced at the beginning you’ll see that we’re far better off articulating ‘value’ in terms of a set of outcomes — “measurable changes in customer/user behavior that generate business value.”
Focusing on outcomes in the product world is a no-brainer. You’ve likely heard it every day however, the theory is simple to grasp but hard to implement.
The way I personally like to define outcomes is by looking for the intersect of your customer pain points/opportunities and your organization’s strategy.
Your Product Strategy is often found at the intersect of your customer problems/opportunities and your organizationsUsing data and discovery as inputs, list out all your biggest opportunities or problems you have with your product right now — it could be customer-related (i.e. usability) of product-specific (i.e. conversion, retention, technical debt) — this is really just your opportunity backlog.
The next step is to overlay all those opportunities with your product group/department/organization’s strategy. Where the two intersect is likely what you should be focusing on first.
This is the crux of product strategy, the alignment of solving the right customer problems to drive product outcomes, and consequently organizational outcomes (often referred to as ‘impact’).
Product Strategy = customer opportunity + organisational opportunity.
Both strategies need to complement each other — products are your connection between the organization and your customers. They’re your avenue to realizing your organization strategy, as such, they’re not mutually exclusive.
2) Prioritize opportunities, not features
Teresa Torres brilliantly said that product teams should be “prioritizing opportunities, not solutions”. One reason for this is that we really should be focusing on the outcomes we want to achieve and not playing ‘waitress’ and taking people’s orders.
“A product team’s job is to create value for the customer in a way that creates value for the business. This is rarely done by fixating on a ranked idea list.” — Teresa Torres
Just as we’ve already explored, Torres also suggests starting with the desired outcome you want to achieve and then work from there.
A by-product of this is that it makes prioritization easier. Not just through good product strategy but also because they’re fewer things to prioritize. Trying to prioritize a list of 5 opportunities is much easier than a list of 50 feature ideas, which is exponentially easier than a backlog of 500+ items.
# of Outcomes < # of Opportunities < # of Solutions
This is one of the reasons why you are far better off focusing your effort into refining your product strategy than trying to create all kinds of prioritization-frameworks, extensive spreadsheets and formulas that are focused on trying to bring order to the hundreds of solutions rather than prioritizing the problems/opportunities that align to your desired outcome.
The tighter your product strategy is, the more defined your desired outcomes will be, and the easier it’ll be to define and prioritize only those opportunities that align with it.
3) Increase confidence
From here it becomes a matter of increasing your confidence that you are heading in the right direction.
Rather than trying to focus on value, focus on gaining confidence — how confident are you that this is a problem worth solving? How confident are you that this will help achieve your desired outcome? How confident are you in the solution to that problem?
When you shift your thinking away from the ‘what’, to how confident you are, you begin to approach things from a different angle.
For example, let's say you have this brilliant idea on the backlog, let’s call it Feature X. If I was to say should we do Feature X the likely answer is yes! — of course, it’s a great idea! — we then accept that we should do Feature X and go into a battle on ‘when’ — before this or after this? This horse-trading is not effective product management.
When you change the question to be about confidence you start to ask the more pertinent questions — how confident am I that this is solving a real customer problem? How much data and research do we have to support this? Have we tested it with customers? How much of my own money would I bet on this being a success? — a year’s pay? a month? today’s lunch?
This helps sideline our natural inclination to jump to solutions, we start to gravitate back up the chain. It helps to force ourselves to strip any kind of solution back to the core problem/opportunity. Before I want confidence in Feature X, I want confidence in the problem it’s trying to resolve — is it actually a customer pain point? actually worth solving?
The only way you’re going to increase your confidence is by getting out of the building and speaking with customers. As such discovery becomes a confidence-building process, as well as a confidence destroying one too.
Discovery is a confidence-building process.
But this is a good thing.
You start with multiple problem spaces and as you go through discovery you’ll narrow them down too but a few. As you shift into the solution space you will also have a number of potential solutions and converging again, dwindle them down too but a few (perhaps just one) based on your confidence in them.
Prioritization in this regard is more about how confident you are than anything else.
Truth is, value is only realized once it is in your customer's hands. Only they can tell you if it’s valuable or not through a shift in behavior.
Until then you’re making a bet — but bets will have varying degrees of confidence, some bets you’ll be more confident in than others.
Many practices in Product Management is really about de-risking. We use techniques like discovery and iterative delivery to derisk by gaining confidence in our bets, or if we’re losing confidence we pivot.
Focusing on confidence allows a sort of Darwinism to ensue where only the best ideas and solutions survive.
De-risking: we gain/lose confidence as we navigate our way towards our desired vision/strategy/outcomes.Conclusion
I often find where places struggle with prioritization it’s not a “prioritization” problem per se, but rather a strategy one.
Either their product or organization strategy is vague or missing, or they're misaligned creating friction between the product’s goals and the organization.
Poor strategy or lack-thereof turns prioritization into ‘fair game’, one without boundaries where often the HIPPO effect and those who jump up-and-down and yell the loudest wins.
Without clarity on what you are doing and why, prioritization becomes hugely subjective, unfocused, and lacking any sort of rigor — and being told to it’s simply based on “value” is not helpful.
Thus you are far better off putting your effort into nailing your product strategy over trying to find ways to prioritize a massive backlog of features — as many attribute Albert Einstein to saying, “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.”
This is how you should approach prioritization. You’re much better off spending 55 minutes nailing your strategy and outcomes — that last 5 minutes then becomes building confidence that what you’re doing is moving you in the right direction.
Instead of thinking about “value”, think about outcomes and then look to gain confidence that you are solving those outcomes in the best possible way.
Vision > Strategy > Outcomes > Opportunities > Solutions*A great way to structure all this is using the ‘Opportunity Solution Tree’ by Teresa Torres, check it out!
📣 Grow as a Product Manager without spending thousands in your own time with deep dives into specific PM topics like this over at productpathways.com.
Subscribe to Product Pathways YouTube channel, where I post regular videos about Product Management.
Learn product online at ProductPathways.com and free on YouTube @ProductPathways.