What do you think about project-based roadmaps versus outcome-based (metric-based) roadmaps?
Short answer: Both require you articulate product strategies (problems to be solved), metrics (lead indicators), then guess which projects will move your metrics, over time. Choose what works for you.
(Gib’s note: You can now subscribe to my essays on Medium and I noticed I now have hundreds of subscribers on Medium. But I have a free “Ask Gib” product newsletter on Substack that I want to make sure everyone knows about. I have nearly 10K subscribers there and write 2–4 essays each month. Below I have re-published my top-rated “Ask Gib” essay so you can decide whether you want to subscribe to my Substack newsletter.)
I’ll start with a story from Bruce McCarthy, an author, speaker, and founder of “Product Culture.” Bruce wrote the book on outcomes-based roadmaps — you can buy it here: Product Roadmaps Relaunched.
Here’s Bruce’s story:
“David Cancel, CEO of Drift and one-time VP Product for Hubspot, called roadmaps a no-win scenario. He said to me: “Either I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.”
An outcome-based roadmap describes the path to a successful product in terms of the problems to be solved to achieve the desired results. This approach provides context to product decisions and allows you to plan further out than you can actually see in terms of features and dates.
It also encourages you to avoid committing to particular solutions to these problems too early, before you’ve done enough discovery, design, and experimentation to know if those solutions will actually work.
A lot of product teams complain that their roadmap, backlog, or other priority list keeps changing. The problems in your market probably don’t change that quickly, but your approach to solving them is something you should continually optimize based on what you learn. So if your roadmap is about problems to solve — which is the focus of outcomes-based roadmaps — it can be the steady light guiding you toward success.”
There’s a lot to unpack here, so in this essay, I will:
- Articulate Netflix’s current strategy, concluding with a project-based roadmap, then
- Transform the project-based roadmap into an outcome-based roadmap (based on some coaching from Bruce).
Here goes…
Netflix Product Strategy (w/ Project-based Roadmap)
If I were the product leader at Netflix today, here are the slides I would share at an all-hands meeting to help the company understand the product strategy. (These slides are illustrative, so please don’t buy/sell Netflix stock based on these guesstimates — I have no insider knowledge today.)
The first slide reiterates the product leader’s job:
The following slide defines the job through one high-level engagement metric: retention. At Netflix, retention measures both customer delight and margin:
Retention, however, is tough to move, so you need proxy metrics:
Below is my “Strategy/Metrics/Tactics” (SMT) slide. It lists the product strategies on the left, along with the proxy metric used to measure progress against each strategy, followed by corresponding tactics:
The last slide is the roadmap. I generally refer to this as a “Four-Quarter Rolling Roadmap.” It’s populated by anticipated projects over the next four quarters. Given it’s the end of Q4, 2021, as I write this essay, I begin with Q1 projects and extend into the last quarter of 2022:
The challenge of a roadmap is it creates an expectation that the team will deliver the projects on a specific schedule. When I present a roadmap, I give the following “No Commitment” speech:
“I’m confident about each of the projects in the upcoming quarter, but my assumption is that we will learn so much this quarter, that our future plans will change. So think of this roadmap as a fuzzy plan of how things might play out. The roadmap helps the organization to understand how projects fit together and evolve. Making guesses about the future also helps my engineering partners anticipate potential long lead-time projects.
Do results-oriented CEOs and investors remember this up-front “No Commitment” speech? Half the time, the answer is “No.” Hence the challenge of project-based roadmaps.
The Outcome-Based Roadmap
Outcome-based roadmaps provide a different approach to navigating the implied commitment of a roadmap but still let you tell a story about how things might play out over time.
Below, I have reformatted the exact four-quarter rolling roadmap from my earlier presentation to create an “Outcome Roadmap.” (If you look carefully, you’ll see that this outcome-based roadmap is a mash-up of my “Strategy/Metric/Tactic” slide and the “Four Quarter Rolling Roadmap” slide.)
Here are the differences between the project roadmap I shared earlier and this outcome-based roadmap.
- Project-based roadmaps present their hypotheses — product strategies — while outcome-based roadmaps express “the problem to be solved,” communicated using customer language. (I think this is a nice touch, as it brings the customer’s voice into the mix.)
- Outcome-based roadmaps reiterate the proxy metrics from my “SMT” model and position them as “leading indicators.” For both, the assumption is that the metrics are meaningful, but you don’t know exactly which projects will move them.
- Outcome-based roadmaps avoid a specific quarter-by-quarter plan and instead use the phrases, “Now, Next, & Consider.”
The result reinforces the importance of moving the “leading indicators,” irrespective of the timing or exact composition of each project. Most importantly, there’s no implied commitment to a timeline.
What do I think?
First, a big shout-out to Bruce McCarthy for helping me understand outcome-based roadmaps and for illustrating the differences between them and project-based roadmaps.
Bruce and I agree on the following:
- Roadmaps are an expression of your product strategy. Whether you create a project or outcome-based roadmap, you need to do the heavy lifting of figuring out your product strategy first. Defining your product strategy doesn’t begin with a roadmap — it ends with it. (I articulate my step-by-step process to define a product strategy in this Medium essay.)
- Roadmaps are a story-telling tool. They help the company understand how projects fit together and how your product might evolve. They articulate what you feel is important and the metrics you use to determine both customer and shareholder value.
I think the difference between the two is a style issue. Project-based roadmaps and my “No Commitment” speech work for me, which is the ultimate test for any tool, model, or framework. If something works for you, stick with it.
Whichever you choose, make sure you do the hard work up-front to articulate your product strategies (problems to be solved), your metrics (leading indicators), then fill in the blanks of your roadmap with the projects you believe will move your metrics.
If you enjoyed this essay, I write 2–4 essays like this each month as part of my free, “Ask Gib” product newsletter. You can read and sign-up for my Substack newsletter by clicking here.
If you haven’t read my 12-part series on “How to Define Your Product Strategy” on Medium, click here.
If you’d like to give feedback on this essay — so I can learn to make each one better, please complete this three-question survey — it only takes one minute!
Thanks,
Gib
