Mid-week editions of the newsletter are typically for paid subscribers only.
But, in celebration of being named the #11 LinkedIn influencer in the world 🤯, today’s 3,300 word breakdown is free.
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.
TIP 1: Measure analytics on sizing success
The most powerful thing I have seen to improve roadmaps success rates is to make the analytics function responsible for the impact sizing. In this setup, you actually measure and review product analysts on how well they estimated the impact of features. What makes this so magical is: if that’s their main goal, they will be very rigorous.
This then helps the team identify when the features on their roadmap will not hit their overall goals/ OKRs. Then, they can go to leadership for help in finding higher-impact work.
Sometimes, this results in leadership helping develop higher-impact roadmap items. Other times, it triggers a reorg of the team. Both are powerful responses that can help the business.
TIP 2: Build it after you identify your OKRs
The sequence of building in product should be:
First, understand your mission
Use that to guide your vision
Then create your strategy
Identify your OKRs
And, finally, create your roadmap
Sadly, most teams skip steps. The most common failure pattern is they have a mission and vision, but then start building their roadmap (or have key items from a roadmap in mind). They then retroactively create a strategy or OKRs around their roadmap.
This way of thinking is tempting if you feel like you have high conviction in your roadmap items. But the reality is, a roadmap without a clear strategy or OKRs tends to set you off in the direction of features that are good, but not the ones your business needs now. The process of strategy and OKRs helps you figure out what the business needs now.
TIP 3: Change your format
After a while, people tune things out. Sometimes, you should just change it up.
In fact, one of the most effective things to do is actually have a “big rollout” of the “new tool.” I suspect this has helped a lot of companies like Productboard, Aha, and Roadmunk exist.
Sometimes, you just need to get sales, customer success, and executives to pay attention to what’s being built.
TIP 4: Ditch the prioritization framework for an objective function
RICE, Moscow, Kano… prioritization frameworks are everywhere. But ultimately, you want to exceed your OKRs within the quarter or half. So after years of using prioritization frameworks, I have begun to ditch them. The objective function I use is:
Maximize impact given the resources
So in the 201 & 301 roadmaps, you see there is design, research, and engineering sizing. This helps you estimate what exactly you can complete given your cross-functional team. And there is a specific estimate for impact. So I just maximize the impact given those constraints.
As I said this weekend about prioritization: if it isn’t a clear yes, then it’s a clear no. Waiting till you have some solid objective functions is one way for you to wait until you’ve built conviction for the clear yes.
TIP 5: Build a culture of updating roadmaps
There’s a Goldilocks zone" of “just enough” updating roadmaps. But most companies fall on the side of not updating roadmaps enough.
If you build a culture and expectation that things will change as you learn more, it keeps you agile as a team. Many of the best features my teams have shipped were fast iterations on a learning mid-quarter.
A roadmap should be considered a ‘point in time’ artifact instead of a contract for the quarter of half.
The Most Common Mistakes I See in Roadmaps
So now that you know what to do, what about what not to do?
Mistake 1: Roadmap is when you start thinking about what to build
The number one failure pattern for product teams is improper planning. In the rush to move to agile and empowered teams, far too many product teams at fancy tech companies fall into this pattern today in April 2023.
This manifests in a situation where the product manager is racing to complete feature specifications, and designers are rushing on incomplete briefs, just to keep the engineering team busy.
The roadmap should not be the time you start to think about what to build. That should be a process that you’ve thought of long before. The roadmap is just a point in time during the planning process to record and share with product leaders your high conviction big bets. This ties into mistakes two and three…
Mistake 2: Lacks Conviction
When I’m reviewing a roadmap as a product leader, I like to see the team have a point of view on what will work.
If the team has a series of initiatives at every step of the funnel and on many customer problems, that’s a sure-fire bet they haven’t built conviction on what’s high leverage and important to solve now. That’s a scattershot strategy sure to fail.
I’d much rather see everything the team is doing in one part of the funnel or for one part of the problem.
Mistake 3: Big Rocks haven’t validated the riskiest hypotheses
If I dive into a brief for a big rock of a team and there aren’t user quotes, explanation of why the problem is the most important to solve, it’s obvious there is something broken with that team.
Big rocks on roadmaps should have great briefs that have de-risked the riskiest most part of the feature. The best PMs run small experiments the half before for their big rocks the next half.
Mistake 4: Huge list of little things
The key thing to focus is on with your roadmap is the big bets. When a single engineering team is sharing a half-year roadmap with 25 items, they’ve clearly gone off the deep end into waterfall planning mode.
The huge list of little things makes it clear the team is using this as an execution planning document. That’s not what roadmaps should be used for. Use something like Jira or your task tracker for that.
Roadmaps should be communication tools for big rock features to achieve your strategy and vision.
Mistake 5: No Wiggle Room on OKRs
The final mistake I see all too often with roadmaps is the sum total of the items on the team’s roadmap hitting their OKRs. So if the business needs the team to drive $20M in revenue, they’re driving $20.5M.
There should be a fair amount of wiggle room. Your roadmap items should be driving at least >10% of your OKR. The reason? Things always happen in product. It’s not a science. A feature fails or gets pushed back.
Always have a cushion.
How I Suggest You Deploy Roadmaps
A lot of this piece has been generalized since you are a 40K+ group with very diverse situations.
How do I suggest you deploy roadmaps if conditions are ideal? If you are in a high-performing team with capable individuals in the engineering, design, analytics, and product chairs? At a modern tech company?
Use the roadmap to inform senior stakeholders: The easiest way to product purgatory is not having product leaders believe in your decision-making. Use the roadmap to convey the quality of your product sense.
Use roadmaping and planning for dependency clarification: A key problem roadmapping solves is dependency planning. Use the roadmap/planning process to get your key dependencies resolved.
Use the 301 spreadsheet: Don’t get too fancy with a roadmap tool or now, next, later. Just use a Google sheet.
Treat roadmaps as a “point in time” artifact: Publish the artifact in a big publicity tour right before the start of the quarter or half, and then move on. Don’t get bothered always keeping it up to date.
Enumerate your big rocks: The roadmap should be used to highlight each engineering squad’s top 3 or so initiatives. It doesn’t need to go into crazy detail on everything they will do.
Make roadmaps no more than 5% of your time in a quarter: The roadmap just be something you spend a few days on per quarter. “Over-roadmapping” distracts from you the importance of execution.
Of course, not all of these tips will work for every situation. So, customize them as necessary.
Final Words
There’s a lot more to say, and we’ll cover that in Roadmaps 301 down the line. For now, we are again at the email limit.
May your roadmaps drive higher impact than ever before 🚀
Want access to more deep dives like this? Go paid.
This weekend, I’ll be breaking down the product strategy of the hottest company in AI: Runway. You don’t want to miss it.
Aakash, you’re publishing faster than I can read and consume your excellent material 😅🙏🏽
Great list of mistakes and feedback on how to work through them.