I talk to a lot of PMs and I ask them (and everyone who subscribes to my newsletter) the same question: what’s your biggest struggle as a Product Manager? I get back all sorts of replies, but by far the biggest issues are about prioritization, in some shape or form.
Having put together a fairly popular resource on product prioritization methods, I would’ve hoped the situation to be different. But it’s not. It remains hard for many PMs. The most frequent issues and sources of frustration are around these basic questions:
- How to decide which are the most valuable things to do?
- How to handle multiple valuable things that should be done?
- How to deal with constantly changing priorities?
Prioritization methods are based upon the notion of Value, but given the sort of questions people struggle with, it clearly is ill-defined for many. Why is that?
I believe the main culprits are Mr. Roadmap and Mr. Backlog. Chock-full of Themes, Epics, Releases and Features. Progress bars and Milestones.
They’re filled with “things”, and they are really hard to evaluate and compare to each other. Things are outputs. When we’re immersed in this endless pit of stuff and we think of our job as jugglers and prioritizers of things, we’ve already failed.
Here’s the deal: Value comes from Outcomes, not Outputs.
An output is what we see and experience (the features and products we “touch”). An outcome is what we get out of them—it’s what we’re seeking (and thus, what we value).
Until teams stop thinking in terms of outputs, and start framing their work in terms of outcomes, prioritization will always be a struggle.
So, how do we tackle the issues mentioned at the outset? How do we use an outcomes-based lens to avoid prioritization problems?
Problem #1: How to decide which are the most valuable things to do?
Think about your team’s work over the past couple of months. You’ve likely worked on new features, bug fixes, minor UX improvements, perhaps tackled some technical debt, and so on.
When trying to set priorities people often ask questions like… Is Feature A more valuable than Feature B? How about Bug X vs Feature C? How should we balance technical debt vs our feature roadmap?
Answering any of that is nearly impossible without a well defined notion of the value each of those things create. We’re constantly comparing the proverbial apples and oranges because we’re looking at their description, their functionality… their output. So the first thing we need to understand is the “types of value” we’re providing. Keeping with the analogy, the “kinds of fruit” we’re comparing.
Bugs can be valued in terms of quality outcomes like reducing support needs or improving user satisfaction. Technical debt can be valued in terms of “future change” outcomes like improved delivery velocity or better platform scalability, for example. UX improvements can be valued in terms of incremental optimization outcomes like reducing task completion times or improving particular funnel steps. Finally, new features should be valued in terms of major business or customer outcomes that they’re aiming to serve (increasing CLTV, supporting a new vertical, compliance on new legislation, etc.).
Thinking in this way means that we need to have clearly defined goals. We need to know what we’re trying to achieve (our target goals), but also what we want to maintain (our health goals, borrowing from Christina Wodtke’s terminology in her excellent book on OKRs). Then, any piece of work needs to be tied to a goal. That’s what defines the “type of value” it creates, and what will allow us to easily compare it to other “things” in that “bucket”. Value will then be the measure by which a “thing” impacts its goal, which makes setting priorities straightforward.
My top 2 preferred ways to frame and communicate the team’s work in an outcome-first manner are Asana’s “Pyramid of Clarity” (which essentially describes an OKR organization) and Teresa Torres’ “Opportunity-Solution tree” to describe the problem and solution space we’re exploring, and tying it back to the outcome we’re trying to generate. In practice, I like to combine both tools, which fit together quite well, and it looks like this:
What I like most about this structure is that it combines both opportunity- and discovery-led work with “just have to do it” type of work in a single view, using equivalent concepts. A lot of our product work requires discovery, which is why the Opportunity-Solution-Experiment concepts in Teresa Torres’ tree are ideal. However, other types of work don’t need that. For example, legal compliance usually means we need to support a set of rules (think GDPR), and we can run that as a project- and milestone-based initiative with a set of solutions that doesn’t require much (or any) experimentation at all. Having both kinds of work side-by-side is useful. It’s also important to keep our Health goals visible (i.e. “what we don’t want to mess with whilst pursuing our target goals”), next to the rest of the work we’re tackling.
Problem #2: How to handle multiple valuable things that should be done?
Although the previous point helps with setting priorities along individual “types of value”, it still doesn’t tackle what happens when when we’re dealing with multiple goals at the same time (as most teams are). That is, how should we balance multiple, simultaneous priorities?
Well, that’s the role of a product strategy.
My favorite definitions of strategy are the simplest I’ve found. The one I use most is this: a strategy is what we choose to do. Our choices are guided by research and explained by a rationale, but in the end, the strategy can be described by how we allocate our resources to achieve a set of goals. In other words, the strategy should define how important each goal is, relative to others. So, that can take a simple shape like a set of percentages (one per goal), representing how much of the team’s time should be used to pursue each of them (you can see an example below).
I find it extremely helpful that the entirety of the team’s time is clearly defined, even when that line of work is not managed by the PM (such as technical debt, which should be managed by the engineering organization). It reflects what the team’s focused on, and clearly sets expectations to the rest of the organization as to where time will be spent on.
This definition of the product’s strategy as the percentage of time to be spent on each goal can then be looked at as the first level of prioritization, useful at any point of planning. Every release or sprint can use it as a guideline. Each type of value is already prioritized based on impact on its goal. Then, all we need to do is take a certain amount of work from each “bucket”, in order to hit the balance that is defined by the strategy. Tying it back to our “pyramid” or “tree”, it looks like this:
I have to thank Rich Mironov for these ideas, which come from a couple of great articles of his. One is on the concept I just described, and the other on what happens when the strategy is not clearly articulated. Even when we don’t know what the current strategy is, we can look back at our recent work, classify it and get the percentage of effort we’ve spent on each “type of value”. These numbers will come as the result of all the micro-decisions we make every day, consciously or not—it’s an implicit strategy (which through this exercise has been made explicit).
Having a simple strategy definition like this one is useful as a planning and communication mechanism (it’s easier to share and align with the rest of the organization), but it’s also useful as a reflection tool. It forces us to think about our choices and where we want to spend our time on. Do we want to work on multiple product goals at once? Which ones? Are we spending too much or too little on technical improvement work? You get the idea.
Problem #3: How to deal with constantly changing priorities?
Another big source of frustration for many PMs is the feeling that “people higher up” keep changing their priorities… It makes it hard for them to make meaningful progress and produces a lot of wasted effort. Although this issue is real, it is often either a problem of perception or output-based thinking.
When we feel that “priorities are changing”, we need to remember the concepts described thus far and ask ourselves:
- Is the strategy changing?
- Are goals changing?
- Are the features we work on changing?
It’s only natural that these things change and move over time, and shouldn’t be a source of frustration. It all depends on the level and frequency at which they change. The higher up in the hierarchy of concepts, the more stable things should be: goals and strategy move at a lower cadence than the opportunities, features and ideas that might impact them. When they change too frequently, it’s a sign that some kind of short-term pressure is driving the top-level decision-makers, and that’s a problem. However, with the structure described here, it’s possible to quantify and visualize these shifts over time, so that we can show where the problem is and discuss it with leadership.
Now, when we get to the opportunity and feature levels, frequent change is to be expected, as long as it is in service of our goals. That’s our bread and butter—figuring out what works best, what moves the needles we want. However, if we’re being pressured by others to add a random feature and to move it up the priority list, that’s a problem.
Still, the beauty of framing our work through the outcomes we’re aiming for, is that we now have a well-supported, elegant way of saying No. Is this thing you’re asking with our mission, vision, value proposition? Does it contribute to our current goals at all? More than what’s already in the pipeline? Is it a low (risk) effort? If at any point in this sequence the answer is No, we can justify our answer and prevent that piece of work from creeping in.
Change in and of itself isn’t necessarily a problem, and we need to embrace it, when it’s the right kind. But when it’s a symptom of an organizational issue, we need to understand where it is, and (try to) fix it with the right toolset.
Takeaways
When we’re able to frame our work with these principles in mind, setting priorities becomes a much clearer and straightforward endeavor. That’s why Priority starts at the top. Everything flows down from our Mission, Vision, Value proposition, and Strategy (which defines the Goals to pursue and how important they are).
Priority comes from Value, and Value comes from Outcomes.
However, this doesn’t come for free. It requires a change in our mindset and in our processes. We need to stop thinking about shipping features, and start thinking about how we deliver outcomes. That’s our real job as Product Managers.
If you’re interested in pursuing this path, there’s no better way to start than by reading Joshua Seiden’s excellent book, and of course following Teresa Torres’ blog if you aren’t already.