A Guide for Product Teams
As product leaders, we are constantly asked to share a roadmap of features we intend to build. As well intentioned as the product literati that argues against roadmaps are, after pit stops in product across 6 tech companies, I have generally always seen them produced. They provide clarity to customers, investors, and other stakeholders that want to see your engineering resources put to the best possible use.
What is stunningly lacking on the internet – yes, on the internet in December 2021 – is a coherent overview of how to build a prioritized roadmap. The best resource I could find is, perhaps predictably, from Lenny Rachitsky. The former Airbnb product lead turned newsletter author to more than 85,000 builders wrote, of all things, a legendary Twitter thread in 2019:
That is, for the purposes of the internet today, the canonical text. I’ll cite the next 20 best from the internet throughout this article, but Lenny’s 11 tweet thread, of all things, stands out as the best. So, I will use Lenny’s thread as a structure to go into all the details of prioritization, to create our own little Product Growth version of, “The Prioritization Bible.”
Three Phases to a Roadmap
The process starts with a 3 step process of:
- Ideation
- Prioritization
- Communication
As Lenny notes, “skipping a step will cause you problems down the road.” Sometimes in the name of work life balance pressures, it can be tempting to not go all out in one of these steps. Do not. Doing all three, in order, is key. Err towards extending the process rather than skipping parts.
Step 1: Ideation
Let’s build off of Lenny’s excellent foundation:
Gather ideas. Give everyone on the team a chance to share their best ideas. Run brainstorms, meet with opinionated team members, and get ideas from stakeholders. Collect all ideas into a central doc, and have team members vote. Make it clear voting is just one input.
The ideation process is about more than the PM having good product sense to suggest ideas. It is about getting ideas from everyone, especially the most passionate stakeholders and team members. I often find it important, depending on the size of the company, to include the CEO and head of product in this ideation process. Involving them early helps them prevent them from throwing a wrench in the roadmap later.
One of the trickiest sessions to run is the product brainstorm. Product brainstorm sessions are a bit more art than science, and many times the PM does end up running it. In those cases, three of the best practices I have found most important are:
- Drive understanding of the context: team scope, user problem, and business impact
- Help quiet people speak up by creating room for them
- Keep up the energy level
The voting is another contentious topic. But I think the rules are ultimately just guidelines. Some people swear that you should not be able to vote on your own idea. Others claim that there must be a limit on the number of votes any individual can cast. I find the most important thing is that everyone participates thoughtfully. You can make any rules work.
Step 2: Prioritization
As Lenny says, “this is the hardest part about building a roadmap.” Being hard, it requires lots of guidance – so much so, that Lenny dedicates 5 of the 11 tweets in the thread to this step. In the Prioritization Bible, we turn that into parts A through E.
Part A: Prioritization Framework
To begin to prioritize, you need a prioritization framework. There are a litany of them, and this article from Roadmunk on 9 frameworks might be for you, if you absolutely disagree with Lenny’s framework I am about to present. I tend to think that the framework is far less important than the level of thoughtfulness that went into the use of it. But I do love and consistently reference that Roadmunk article.
Lenny argues you should prioritize based on three factors:
- Expected impact
- Resources necessary
- Risk
This takes the typical work / value framework and adds a component of probability. The third factor, risk, helps add a perspective of forecasted scenario planning to the exercise. It asks you to take the devil’s advocate’s position against your own prioritization.
As Lenny says, “PM should take the lead, working closely with the team. It’s art + science.” There will be team members who have to disagree and commit with the PM on some decisions. But the PM should strive to create a meritocratic environment of ideas.
One technique I have enjoyed to create such a process is the “tournament of ideas.” People pitch their ideas, and ideally even develop their product mocks and design prototypes as they advance further in the tournament, to help the team suss out which bets are most attractive. If the team has time, these tournaments have the benefit of being great team-building experiences.
Perhaps the area that is most debated is expected impact. PMs will regularly lie on the opposite side of the spectrum as a team member. PMs should invite this disagreement. Great prioritized roadmaps are like diamonds hardened under pressure. The disagreement should be used as an opportunity to work with analytics, research, and the overall team to push the logic for and against a certain impact assessment. Then, the PM should make a call based on as objective an evaluation as they can.
Part B: Evaluate Shape
Ultimately, ideas should be sorted by ROI. Then, you should evaluate the overall shape of the selected ideas that fall “above the line” of reasonably estimated engineering capacity for the planning timeframe. The ideal split of projects is:
- 70%: Low-risk, immediate impact
- 20%: Risky, long-term bets
- 10%: Delight, fun, nice to haves the team is excited about
This is the roadmap shape of a grizzled veteran who understands the demands of a business, which needs immediate impact and long-term innovation, plus a happy team. The bulk of work is things that you have de-risked through prior testing or discovery work. 20% of items are riskier, but help you learn. Finally, 10% helps keep the team happy. It is the small things, attention to detail that is “Apple like.”
It can be tempting to over-invest in long-term bets. The problem is that executives and stakeholders will lose faith in your ability to deliver. Product building is unfortunately a game of, “what have you done for me lately?” As a result, it is important to deliver features that you have high confidence are going to perform in A/B tests and graduate to the broader population. Few product teams present failed experiments at all hands meetings. Many present features graduated to full rollout.
Part C: Key Adjustments
You would be wrong if you thought the work was done there. From there, there are three sets of adjustments not to forget to make. Let’s start with Lenny’s foundation:
- Team voting results: consider bumping up a team favorite
- Strategic bets: are there investments the org needs to make know
- Sequencing: what should come first
Team voting results’ spirit has already been mentioned several times in this piece. The unique piece to understand at this point is: you are not fudging the result to improve your reviews. You are not catering to the crowd either.
The idea with this adjustment is that the team closest to work is always the expert on it. Engineers live at the edge of what is newly possible. Designers live the user’s problems and solutions day in, day out. Other voting stakeholders like executives bring wisdom and perspective. Considering the team vote is mixing the art on top of the analytical impact sizing in part A. It is acknowledging intuition matters in product development.
Strategic bets are relatively clear to point out the more senior you get. More senior PMs are assigned more strategic projects, the ones that make it to the news. As a result, it is important for junior PMs to find strategic bets within their given scope to progress to more senior roles. Strategic bets also help you take a step back from the short term and think longer term than the current planning cycle.
Sequencing is just as vital as team voting and strategic bets. Highly impactful projects tend to have blockages. That is why they have not been done yet. As a result, teams often need to plan around dependencies. Building a coherent sequencing of what goes before what, for learning, technical architecture, and other blockages helps with not over-promising in part D.
Part D: Strategy and Vision
Lenny provides the impetus for part D eloquently:
You need your roadmap to be building towards something, not just be a bunch of good ideas. How will your team/company win? And how is the work you’re doing supporting this?
You have to go from prioritized, shaped, and now adjusted ideas to strategy and vision. Strategy and vision help the roadmap build towards something. The worst roadmaps are a bunch of short-term features that a design change 1 year later completely obviates. Product teams consciously need to write a longer term strategy and vision that is communicated with the rest of the company, so their vision is not halted in its tracks accidentally by another team.
The tool I typically start with is OKPS. I line up the ideas by problem and solution. Then I create a tree and tie that back to the team’s OKRs. This allows me to think about the key strands, and assumptions about the user we are testing over the planning period. From there, I draw a through line to create the strategy.
Great strategy is often the stuff of $50M McKinsey projects. But for PMs, strategy should answer how the company will win in the market context by inspiringly describing the current state, challenge and user problem, as well as target condition. “Me too” features are generally unattractive but sometimes table stakes. By taking the external perspective of strategy, you harden your roadmap.
When you step back from your strategy, it should have a great throughline across:
- Company Mission
- Company Strategy
- Product Strategy
- Product Roadmap
- Product Goals
Then, package it together in an innovative format to communicate the longer-term product vision. If you have the budget, Mark Zuckerberg used a VFX crew for his product vision. That is the tool of most game leads as well:
Product vision helps product leadership empower product teams instead of dictate features. So, this is an area the PM should really double click in with the CEO and product leader. After iteration, the product vision should clearly demonstrate the future you are trying to create.
Part E: Gantt Chart
The final task is to make sure everything is doable, and about when it will be done. The tool of choice here is the Gantt chart. As Lenny describes:
Work with leaders from each function to convert the flat list of priorities into a gantt chart. I personally like to have a row for each team member and a column for each week (e.g. 3 months). This will help you see what is doable. Be conservative.
As his details imply, the Gantt charts do not end up only being useful in planning. They help PMs and the team be accountable to certain projects in certain weeks.
For the purposes of planning, though, gantts also help prevent overpromising and under delivering. That is the easiest mistake of young PMs and product teams. They hope to conquer the world, but projects always seem simpler when you are not working on them. When you dive into the details, most revenue-moving features require heavy lifting.
You do not want your software construction to resemble real-world physical construction: over time and over budget. Use the gantt chart as your weapon to plan ahead.
Step 3: Communication
There are two groups to communicate with:
- The team
- External stakeholders
The team should be involved in every step of the process. You should have a meeting before the process to introduce them to it. You should be getting feedback at each stage along the way. This helps them feel a part of the process, and helps you avoid surprises. Product teams work best as missionaries, not mercenaries. So everyone should feel like missionaries for the product vision.
External stakeholders should come in at the end. This is all the ancillary teams that are impacted, like non-requesting sales teams, executives, and other support teams like marketing and compliance. They should be informed at this stage, and their input should be integrated. Sometimes, this might mean jumping back up to an earlier step. Great ideas can come from anywhere.
Once these two groups are communicated and finishing touches are put on the roadmap, it should be published. It should be shared widely. I usually present it to the executive leadership team. Definitely present it to the product leadership team. Everyone should know where it lives, so it can become a source of truth for downstream teams.
This step is important to experience the benefits of roadmaps: great alignment and planning. Companies that do not have roadmaps are often just pushing the chaos down to “downstream” teams like localization and marketing agencies. Companies that use roadmaps can have everyone plan ahead, and maintain work-life balance.
How Often to Refresh
Refresh frequency is one of the most debated topics. Most product teams will have to go with the decision of leadership. But if you happen to be one of the people inputting, Lenny has advice:
I’ve found a quarterly cycle is the best balance between keeping things fresh, and avoiding excessive meta-work. However if you ever feel like things need a change, just do it.
The ideal timeline is a quarterly cycle. A half becomes too rigid. You are not able to respond to new evidence. Anything sooner is just way too high a fraction of time spent planning. A quarter means the team is responding to new evidence and moving fast, while balancing strategy vs execution time on their calendars.
Sometimes, things do just need a change. So, if you feel like that is needed, just do it. One of the scenarios that often causes this is a new product leader. Another scenario might be a highly opinionated engineering leader leaving.
How to Structure
With the rise of software from Coda to Notion, Miro, and more, everyone has their perspective on where to build a roadmap. I agree with Lenny, though. Keep it simple:
I personally found Google Sheets the best place to keep a roadmap. It’s flexible, fast, and anyone can use it. Many PMs like to use JIRA, Asana, and even Trello.
The tool really matters less than you think. Google sheets does work well, because it is built for collaboration. But most modern product roadmapping is explicitly built for collaboration. So just make sure that criteria is met.
Back when Lenny wrote the tweet, many people used Jira, Asana, or Trello. Nowadays, I think the ranking is something like: 1) Google sheets, 2) Google docs, 3) Notion, 4) Miro, 5) Coda, 6) Asana, 7) Trello, 8) JIRA. The keys are: find a tool where you like the vibes, and everyone on the team has a license to collaborate.
Example
So now you know how to roadmap, how often to roadmap, and where to roadmap. What does a great roadmap look like?
>> Here is your free Product Growth Google Sheet Roadmap template. <<
It has three tabs: the roadmap, the backlog, and the gantt chart. The backlog is where you put everything you scoped in the prioritization process that did not make it above the line.
Like with prioritization frameworks, having the right roadmap template is not the key to success. The key to success is thoughtfully using it. With that said, if you do not like my template, here are a bunch of great templates Roadmunk compiled.
A Moment for the Critics
Some of the biggest influencers in product management are vocal opponents of the processes described here. Let us close by learning from them.
The Marty Cagan Counterpoints
It seems like every PM I talk to these days worships at the altar of Marty Cagan. He is not the biggest fan of roadmaps, and has articulated his position very convincingly. For those readers are who experienced PMs, you have probably have been reciting his main points while reading along.
Let us take these one by one. Marty’s first problem is that prioritized roadmaps are feature-centric at the start:
The feature request spreadsheet works against this end by pushing through features that users don’t value or need, increasing complexity, decreasing usability, and wasting engineering cycles
A great PM needs to avoid the planning cycle wasting engineering cycles. That goes back to the quarterly timing. They also need to make sure not to push through features users do not need or increase complexity. These are indeed common pitfalls of roadmapping. But they are avoidable when handled by experienced practitioners.
Marty’s second qualm is that discovery, ultimately, matters more:
Feature requests are specific theories about what might help this, but at the stage of the roadmap you really have no idea if the features described are the right ones, or if they can be designed such that theyÂąll be useful and usable. That will come during product discovery. To lock in specific features at the roadmap level is to effectively skip the most important part of your job, and the key to great products which is product discovery
I think the key here is not to commit to specific solutions in the planning process. Instead, commit to outcomes and user problems with proposed solutions. Then use discovery throughout the quarter to be nimble about solution decisions. Also, on a quarterly basis, use discovery to inform your next quarter. A quarter does not lock you in that long.
Marty’s third problem is that the impact on user experience design:
Good design and product discovery in general can quickly lead you in different directions as you realize that many of your preconceived notions of what is required either just don¹t resonate with the user, or aren’t usable or feasible
I think, again, the key here is not to have feature myopia. Marty is criticizing that. If you are open-ended in your solutioning as your discover new things about the user, you can overcome his three main criticisms of the prioritized roadmap process.
Finally, Marty makes a lot of references to how product people at great companies like Google do not use roadmaps. That is just not true. I think it just makes the books read inspirationally. I worked at Google. Every PM I met there wrote prioritized roadmaps, following a similar process to the one outlined in this article.
The Teresa Torres Counterpoints
The other prominent, vocal proponent against the prioritized roadmap framework presented here is the godmother of product discovery, Teressa Tores. Let us also analyze her points one by one.
Teresa’s first problem is that estimates are tough:
I can’t tell you when we will release something. Estimates aren’t reliable. Problems grow in scope.
This is true. It is hard to estimate things well. But teams, in my experience, can get better over time. And tools like the gantt chart help. Finally, being conservative always helps. Instead of promising right when you think you can deliver something, add a bit of time. There are always unknown problems in building something important.
Teresa’s second qualm with prioritizing roadmaps is the falsity involved:
This type of roadmap does more harm than good. Yes, it does create a sense of certainty. It does tell the rest of the team what you are releasing and when, allowing them to plan their activities and set expectations with customers. But it does this based on a foundation of lies.
That can be true if you are bad at estimating, which is her first point. But if you can build conservative, accurate estimates, this can help. One of the steps I have found most helpful in improving engineering estimates is getting design mocks. So that is a column in the prioritized roadmap spreadsheet.
Teresa’s third problem is that the process has things like team adjustments:
The creation process is often a political game that allows stakeholders to argue over their own interests, rather than putting customers or users first.
To avoid falling prey to her criticism, never prioritize a feature because your CEO or the boss asked you. Always do so for first principle reasons. As I mentioned in the team adjustment section, that team adjustment is not a fudge. It is just an acknowledgement our teammates are doing valuable discovery in their day jobs.
So, ultimately, like Marty, I agree with Teresa’s criticism: bad roadmaps fall prey to those problems. But I think great PMs, with the process in this article, can avoid those problems.
Takeaways
If it is not abundantly clear by now, do yourself a favor and get a Twitter account to follow Lenny. His free content is worth its weight in gold. If you have a learning & development budget, spend it on Lenny’s newsletter. He delivers even more value in his paid newsletter than his free one. I would also argue he keeps getting better; he is better in 2021 than 2019 .
In addition, if you have not read Marty Cagan’s Inspired and Teresa Torres’ Continuous Discovery Habits, order those off Amazon as well. Even if I may disagree with them on prioritized roadmaps, the books are great investments. They will push you to think differently about how you build products.
Finally, coming back to what we went over today, here is the framework in a picture:
Take this out into the world. Use it. And tell me what you learn.
