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: I’m on vacation in Bend, Oregon until the end of April 2021. Here are my upcoming public events and special offers:
Click here to purchase my self-paced Product Strategy course on Teachable for $200 off the normal $699 price — the coupon code is 200DISCOUNTGIBFRIENDS but the link will handle this automatically. (You can try the first two modules for free.)
5/27 “Hacking Your Product Leader Career” Masterclass with Productized (6:30 am PT, 3:30 pm CET)
New! I’m on Instagram at “AskGib”
Click here to ask and upvote questions.
Welcome to the 350 new subscribers who joined this past week! After three months, we’re 3,800 strong. Each week, I answer a few “Ask Gib” questions, drawing from my experience as VP of Product at Netflix and CPO at Chegg. If you’re not a subscriber, here’s your chance:
Project-based v. outcome-based roadmaps?
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).
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.)
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 Q1, 2021, as I write this essay, I begin with Q2 projects and extend into the first 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 building.)
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 subtle 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.
One last thing!
I hope you found this essay helpful. Before you go, I’d love it if you’d complete a few of my Four Ss below. Bonus points if you do all four!
1) Share this essay with others! By doing this, we’ll collect more questions and upvotes, which helps me to keep essays relevant:
2) Star this essay! Click the Heart icon near the top or bottom of this essay. (Yes, I know it’s a stretch to say “star” and not “heart,” but I needed an “S” word.)
3) Survey it! It only takes one minute to complete my Net Promoter Score survey, and your feedback helps me to make each essay better:
4) Subscribe! That way you’ll never miss an essay and be part of this fast-growing “Ask Gib” community. (I’ll be adding community elements, soon.)
PS. Got a question? Ask and upvote questions here:
PS. Once I answer a question, I archive it. I have answered more than 50 questions and these questions had more than 2500 upvotes— I’ll need a rest someday.
This is gold! Been working on an outcome-based roadmap and have been facing some challenges with the engineering team. The engineering manager fears having this more "subjective" prediction instead of objective projects, which would allow him to foresee how many people he needs to hire and how to organize the team. Any tips on dealing with it?
One is about outcomes, the other is about output. I don't think there's a 'choose' but more like, why not use both? Focus on outcomes to plan your strategy, then look at your output and outline how and when things are meant to come through with the appropriate context. The issue generally is when people only choose project-based (timelines) that don't fully communicate the full picture and incorrect expectations are given. However, no harm in having both, if anything, it's probably better!