Roadmaps: Advanced Techniques
Roadmaps: Advanced Techniques
After all, what else does a PM own?
There’s a hilarious video from Sanjeev NC - founder of Supermeme.ai - poking fun at Product Managers’ tendency to be offended when called project managers:
Comedians are often the most astute observers of reality. And one of Sanjeev’s nuggets is worth double-clicking on:
There are certain things only a product manager can do
Okay, so tell me one thing only you can do that no one else does?
[After thinking]… The roadmap
It’s true. The product roadmap is one of the few work products only PMs own. Everything else that is an actual work product, can be done by someone else: engineering, designing, talking to customers.
This is one of the big reasons that, as much as Marty Cagan and Teresa Torres would have you abandon the roadmap, it is here to stay.
I chat with product leaders at different companies all day long, and I haven’t heard from one that doesn’t write and share roadmaps. All of FAANG uses roadmaps.
And the other reality of roadmaps today is that most roadmaps are not hitting their goals.
In today’s tech environment, product team after product team is shipping features that aren’t driving the results the business wants. Tech growth is slowing to a crawl. Just look at YouTube, with three straight quarters of negative revenue growth:
Product leaders are left to blame “macroeconomic pullbacks in advertising.” Everyone who looked like a genius a few years ago now can’t bend reality anymore.
I hear the disappointment from product leaders every day:
“In reality, if we could increase our hit rate from roadmap to actual impact, we would be much better off than hiring another leader.”
“Continuous discovery and tougher product reviews haven’t been some magic solution. We still need help in the basics of prioritizing well.”
If your company’s revenue is growing at <5% and leaders are not thinking those things, there might be a problem somewhere. Great product teams can and should be driving that growth.
So, what I thought could be timely for you all today are some advanced tips - a Roadmaps 201 guide. Consider this the layer deeper after my Roadmaps 101 post a few years ago.
In case this deep dive is not for you, here are some other things I’ve written recently:
Tech: NeRFs are the new big thing: they will disrupt advertising, gaming & film
Product: Alignment is not a checkbox
Here’s our roadmap for today’s piece (see what I did there?):
The different types of roadmaps teams are using these days
+ Templates you can take today and use for your roadmap
My favorite advanced tips and tricks to increase the chance you hit your goals
The common mistakes that I’ve seen teams fall into in my 15 years
Wrap-up and how I suggest you deploy roadmaps
(If you only have 2 minutes, you may want to jump to this section.)
The different types of roadmaps teams are using these days
The three main buckets of roadmaps that are widely in use at the top tech companies these days are: the classic spreadsheet; the now, next, later roadmap; or, a visual roadmapping tool.
The Classic Spreadsheet (50-60%)
The key reason it’s so prevalent: everyone else in the organization has access to it.
Here are a few templates to inspire you:
Simple: 101 Roadmap
Highly analytical: 201 Roadmap
OKR Themed: 301 Roadmap
Advantages of the 201 Roadmap
The 201 Roadmap takes advantage of many of my favorite techniques to upgrade a roadmap:
1: Goes from vague impact to specified
The 201 roadmap asks teams to specify the exact number increase to their OKR in column H. This replaces the low/medium/high impact sizing in the 101 roadmap.
Having a very specific number is valuable for all sorts of reasons. But the most important is: it forces the team to be really rigorous and build a model to understand the impact.
Impact goes from vague to very specific. This helps hold the team’s feet to the fire and built the muscle of really sizing what the impact of features will be.
2: Has a single field to unite teams
The 201 roadmap has incremental annualized revenue in column I. This is one of the most powerful ways to bottom-line impact. It gets everyone trained on thinking about what their work means for the business.
And it doesn’t have to be revenue. It can be profit, or GMV, or a similar universal “output” metric as a field for every team.
It’s also a great reality check if a team is costing more than it’s delivering. Should the team really be that big? Does focusing on that product artifact even make sense?
The one caution is: many up-funnel teams naturally get penalized with such a metric, while platform teams look ridiculously impactful. These are valid criticisms of the approach. But, on the whole, the added rigor and quantitative approach has only had added benefits for the Product org as a whole - in my experience.
3: Incorporate sizing beyond engineering
The 201 roadmap has columns for design and research sizing in columns K and L. This is one of the blindspots I often see product squads run into. They don’t plan around the capacity constraints in design and research. They just focus on engineering.
This has the added benefit of giving design and research leadership visibility into the work. Too often, they are totally extracted from the roadmapping process.
4: Builds in dependency mapping
The larger the organization you are in, the more dependencies in product development become more or less inevitable. To not accommodate this in the planning process is a huge mistake.
In fact, I’d argue dependency mapping is one of the primary values of a “waterfall-like” process such as roadmap planning.
Making it a 301 Roadmap
There’s a lot of customization you can do with the 201 roadmap, like:
Add in the themes for each project
Create tabs for different teams
Organize it to line up with each OKR
That’s what the 301 document does. I highly recommend that as you start working on the roadmap, you make your own adjustments that will make it sing for your organization.
The other thing I would add is: as a PM/pod leader, I also will often write up the document into a 1-pager for my area.
Now, Next, Later (10-20%)
This is one of the “sexier” ways to do things. So, the more a company is interested in improving its product craft, the more likely they are to use it. Here are a few templates to inspire you:
Prodpad template (My friend Janna Bastow invented them)
Advantages of the Now, Next, later Roadmap
1: Helps you avoid the pitfalls of dates
About five years ago, the great enemy of product managers everywhere was putting dates on roadmap items. We were all getting in trouble promising dates to our sales and marketing partners - and then missing them.
The now, next, later roadmap really picked up adoption with product leaders around then. It’s found especially good product-market fit for B2B sales product leaders with a heavy enterprise sales motion. They don’t want to be caught with their hands behind their backs.
2: Emphasizes discovery
About three years ago, the great enemy of product managers was being delivery focused. Everyone wanted to “escape the build trap.” The now, next, later roadmap thus saw another uptick in adoption as teams started trying to practice more continuous discovery.
It allowed you to not churn out things on last year’s to-do list and focus on the new things you are learning. And it’s still good for that.
3: Great for Engineering & Design
The now, next, later roadmap is an especially good fit for working with the builders: engineering & design. In fact, I think it is actually the majority format for engineering sprint planning these days.
What I’ll do on the product side, often, is pair the now, next, later roadmap with a spreadsheet roadmap. I like to have different roadmaps at different levels. A roadmap is just a communication tool, after all. The now, next later roadmap is a great place to operate with the immediate execution team.
Visual Tool Roadmaps (20-30%)
There’s a litany of software you can purchase to organize your roadmap visually, some of which include:
Aha (complete with AI writing assistant)
Productboard (a unicorn company)
Advantages of Roadmap Tools
1: Helps enforce org-wide single source of truth
While every team using their own roadmapping can be great for empowerment, it becomes hard to manage at scale. Mapping dependencies, for instance, becomes less of a process and more political wheeling and dealing. Nobody wants that.
In addition, senior engineering and product leaders’ ability to provide feedback is seriously kneecapped, if everyone has their own format.
A roadmap tool can become a great single source of truth. It can give everyone a view into how things are progressing.
2: Wedge for digital transformation
Instituting a tool can be a great way to get the whole org onto a new process. As a result, they’re very common when you want to go in and improve some of the execution processes in a company that has been around for some time.
Just updating a process without updating the tool often leads to breakage in adoption. Some teams adopt the process, others don’t. Making everyone use a tool that has a process helps make adoption universal.
Such a high percentage of PMs are being hired into digital transformations (think old companies like Ford or J.P. Morgan) that these tools actually represent a high percentage of how PMs think about roadmaps.
3: Drives tracking discipline
Roadmap tools are particularly useful as “systems of record.” They can help you see whatever you want to track on your team:
When a team has updated their roadmap
How many of them hit their OKRs
Who used validated user insights and who didn’t
If these things are lacking in your org, switching to a tool can help. This is especially common as product orgs age (think tech giants like Yahoo or eBay).
Note: The Feature Debate
People on all sides of the roadmap debate tend to get a bit worked up. In particular, much of the product internet is evangelical that feature roadmaps are the devil (Google’s first result for roadmaps says, “Goal-oriented roadmaps always win.”).
I don’t really see any problem with them. You’re going to have to decide on your features at some point. It’s better to bring roadmaps to bear as tools when you need them, and don’t use them when you don’t need them.
In that way, I suggest roadmaps be thought of primarily as a communication tool.
Other advanced tips and tricks
Now that we’ve gone through roadmaps of all types, here are some advanced tips and tricks to increase the chances the items on your roadmap hit your OKRs.
Keep reading with a 7-day free trial
Subscribe to Product Growth to keep reading this post and get 7 days of free access to the full post archives.