How to Build Your Startup's First Product Roadmap
How to Build Your Startup's First Product Roadmap
Here's how I built roadmaps as a newly-hired Head of Product at SaaS startups.
TL;DR - In this post I’ll share a step-by-step guide for how I’ve helped multiple B2B SaaS startups build a product roadmap during my first few months on the job. The key: don’t overcomplicate things with fancy frameworks or tools. Just get the team together, leverage their collective knowledge to define and prioritize possible investments, marry that with estimated engineering capacity, and put the results into a calendar. Then rinse and repeat!
Roadmaps are a weird obsession in Product world. Every PM job description includes “create and maintain roadmaps”. Every PM “influencer” reverently talks about roadmaps as the crown jewels of Product work. And junior PMs seem to be more intimidated by building roadmaps than anything else.
Don’t worry, making a roadmap is usually easier than you think! I’ll try to take the mystery out of building a product roadmap for a B2B SaaS startup.
In this post I’ll share a step-by-step process that has worked for me and teams I’ve worked with, focusing on my last two PM leadership roles: Head of Product at UpCodes (SaaS compliance tools for the construction industry) and VP Product at Cantaloupe (SaaS predictive analytics and payment solutions for the vending industry). In my side gig as a PM mentor and consultant, I’ve also helped other PMs use the same process, with success.
What’s a roadmap?
The first step of roadmapping is to agree on what a roadmap is! Here’s my preferred definition:
A product roadmap is a prioritized, usually categorized, and periodically revised list of 10-30 things that your team is going to work on over the next 1-2 years.
Here’s more detail about each part of that definition.
Prioritized. Your roadmap describes the order that your team is expected to work on and ship each item on the roadmap. It forces you to decide which things are more urgent and/or important.
Usually categorized. Most B2B companies work in parallel on multiple business goals. For example, at UpCodes we had a parallel focus on growing self-service signups via Product-Lead Growth (Goal #1) as well as building enterprise-class tools for Building-Code Knowledge Management for the construction industry (Goal #2). Just like your business has different goals, your roadmap will have features and products that promote those goals. And when it comes time to prioritize features, you’ll usually want to prioritize them in regard to specific goals. For example, some features will help one goal but not others.
Periodically revised. Roadmaps are living documents. You don’t want to change them every week or it will confuse everyone. But you should plan to update them as things change: new learnings about your market, opportunities you learn from customers or your own team, competitive threats, and so on. It’s helpful for your team if this update cadence is predictable, like minor quarterly updates, major updates every 6 or 12 months.
10-30 things. Your roadmap should be short enough to be listed on a sheet of paper or viewable on a single screen. It should be short enough to share with a trusted customer and get their quick feedback in a 30-60 minute call. It should be a list you can eventually turn into a slide, or a marketing page, or a white paper. None of those work if it’s too long, so you’ll need to coalesce and uplevel features into groups. The process of coalescing is helpful in itself, because it gets your team to see patterns representing customer needs beyond small features. Any longer and it’s a backlog, which requires a very different process to manage.
1-2 years. A roadmap is a medium-term document. It’s not about this week or next week’s sprint or the next release. And it’s not your 10-year plan for industry domination. Instead, it’s a preview of what your team will do in the medium term, so that your sales and marketing teams know what’s coming, so that your CEO can tell board members and trusted customers what to expect, so that your engineering colleagues can optimize hiring, and so that your company overall can stay excited about the future.
Building & maintaining the roadmap, step-by-step
Over the last 10 years I’ve built roadmaps for a few different B2B SaaS startups, and I’ve been keeping notes about what worked well. Here’s my notes, turned into a step-by-step list for how to build a roadmap within your first few months on the job.
Spend lots of time with customers to understand their needs firsthand.
Talking with team members, lurking on public Slack or Discord channels, etc. are also good ways to get this info, although especially for enterprise customers you really need to go talk with them 1:1, ideally visiting in person.
Learning from customers must happen in parallel to the rest of this list below. Don’t wait!
Talk with the team to write down the current state: what’s being worked on, and what’s already promised to customers in the near future. This is necessarily the start of the roadmap.
Talk with the team to document their promising ideas for the future. Not minor features but bigger investments that will move the needle on growth, competitive, etc. No judgement is required yet; just write stuff down.
When you’re new, you won’t have much to add here, but as you get more familiar with customers you’ll be able to add your own ideas. But initially, plan to lean on your team. Luckily, few teams have a shortage of good feature ideas!
Combine (2) and (3) into a coarse-grained list of current and possible investments.
Coarse-grained means a list of 30-50 possible investments over the next 1-2 years. Note that this is longer than your eventual 10-30 item roadmap. That’s because you’re going to cut or merge a bunch of these 30-50 items! This is just a first pass.
A longer list isn’t a roadmap, it’s a backlog. You must keep the list small enough for everyone to wrap their heads around it, to read it on one page, to show it to a (very trusted) customer to get feedback, etc.
If the list is too long, coalesce and uplevel features into groups or themes. The process of coalescing is usually helpful too, because it helps the team see patterns that map to customer needs beyond single features.
With the founders and others, clarify product-related business goals for the company overall.
You can often find these in your company’s annual updates to investors. Your CEO should know these by heart. It’s your job to translate CEO-speak into product goals.
For example, at UpCodes our initial roadmap goals were “Accelerate signups via Product-Lead Growth” and “Build Knowledge Management Tools for Building Code Compliance”. Ensure that everyone understands and agrees that these are the right goals. If folks don’t agree, STOP! You can’t build a roadmap if folks don’t agree on why to build things. Work with your CEO to resolve this!
It’s OK if product goals don’t map 1:1 to company business goals. Sometimes you may need to split, merge, or reword them to make sense in a Product context.
If you have more than 3-4 product goals, that’s usually an indication of lack of focus. And it makes roadmapping more complicated. Try to coalesce them!
Your goals may stay the same year to year, or they may change. As your company’s goals change, your product goals should change too!
Pick short names or acronyms for each goal, because you’ll be saying them hundreds of times. Wordiness wastes time.
Put the list of possible investments from (4) into a spreadsheet, or your favorite spreadsheet-like tool, e.g. Coda. Then add columns:
Cost: agree on a unit of measure with your engineering leaders, e.g. developer months, or story points divided by 100. Estimates can be really rough, and (important!) Eng doesn’t have to commit to these. This non-committment matters because most engineering leaders are justifiably wary of being blamed for unrealistic estimates. Your task is to ensure that the granularity is coarse enough that your Eng counterparts don’t have to put too much work into estimation, and that they trust you not to blame them if estimates are off.
Business impact: I like T-shirt sizes (S, M, L, XL), but any metric that doesn’t pretend to be quantitatively accurate (like a revenue projection) is OK. I’ve seen numeric measures like 1-4 or 1-5 work well too. Because features usually apply to different business goals, there’s two basic ways to organize your spreadsheet. If most features apply to multiple goals, then create one impact column for each goal, planning to leave impact cells blank if a feature doesn’t apply to a particular goal. If features usually apply to only one goal, then put each goal in its own tab or separate set of rows.
Get the right group of folks (founders + PM + Eng leaders + Sales/Marketing/CSM leaders + other knowledgeable folks) into a room or Zoom. The objective: assign guesstimates for cost and impact cells for each item in the roadmap spreadsheet.
These meetings tend to work better as 2-ish-hour marathons, not half-hour chunks spread across days or weeks, because it takes 15+ minutes for people to get in the groove and move faster through the list. Also, context matters, and if you split into too many meetings then you risk having different attendees each time. Think of it more like a mini-offsite, not a regular meeting. Have short breaks as needed. If in person, order food!
In addition to the main goal of assigning cost and impact, another important outcome is building a shared understanding on the team of what each thing actually is. This alignment is important when it’s time to rank the list.
You’ll end up merging/splitting/adding items as folks discuss and clarify each item. This is good; don’t fight changes! Your role is to help the room coalesce on a shared understanding, not to dictate the outcome.
Another likely result will be a consensus decision to cut some existing or long-planned features that everyone collectively realizes won’t be valuable enough. If everyone wants to cut something but some curmudgeon wants to retain it, that’s OK. It’ll get shoved down to the bottom later without the drama of cutting it now.
You’ll likely need 2+ of these meetings to get through the list. I’ve found that people usually get really tired around the two-hour mark. If everyone is dragging, I’ll usually end the meeting and schedule a follow-up, because a tired and grumpy room won’t make good decisions.
Next comes stack-ranking, which is fun! Meet again with the same folks, with the goal of ranking your roadmap by bang-for-buck.
This meeting will be shorter (90 mins is usually a good target) because the previous sessions have hopefully built a shared understanding on the team.
To speed up the meeting, usually I’ll take an initial ranking guess using cost and benefit info. IMPORTANT: if you do this, share with the team that just because you took an initial stab at prioritization, the team should feel free to change it! Your role is facilitator, not dictator.
“Bang for buck” ranking means that cheap things should be ranked ahead of costly work with the same impact. One way to estimate this: assign a point value to each impact measure (e.g. XL=10, L=5, M=3, S=1), multiply by the cost column(s), and use that result to sort the spreadsheet. But don’t be too finicky about ranking based on numbers. Your team’s collective judgement of which things are more important should trump any simple calculation.
Go through the list one by one, asking “Should this one move up, down, or stay as-is?” What being decided is *not* whether something will ever ship, but simply what the team should work on first. This lowers the temperature.
“Bang for buck” is inherently subjective, but it’s informed by cost and benefit assigned previously. The team overall usually has a good gut sense of which items belong above others, even if they can’t prove it quantitatively.
It often makes sense to do a separate ranking for each business goal, esp. if the goals require largely disjoint work. Ranking in context to a particular goal is *much* easier than ranking across goals.
Don’t waste time arguing. If there’s disagreement, ask what new information needs to be gathered to figure out its priority, park it off to the side, move on to the next item, and follow up offline.
The lower you get in the list, the less time you should spend on each item because you aren’t going to work on those items for years (if ever).
The output is a ranked list per business goal (or sometimes a global list).
Many teams stop at the step above. But having a stack-ranked roadmap without knowing when things will be delivered is hard, especially for Sales that needs to know when they can go after prospects who need specific features to buy, and for the CEO who will lose credibility with the board and investors if they can’t say when things are expected to ship. It’s better to take your stack-ranked roadmap and map it to the calendar. To do this, first you need to project the capacity of your team to build new features. Once you know that, then you can help the founders and other execs decide how to allocate that capacity across time.
The first step is to decide what portion of your new-feature capacity you want to spend on each business goal of your company. I find quarters to be a good granularity. For example, at UpCodes in Q3 ’22 we wanted to spend 75% of new-feature capacity on our PLG (product-led growth) goal and 25% on Knowledge Management, and wanted to even that out to 50/50 in later quarters.
New features aren’t the only thing your team works on. You’ll also want to allocate a percentage for “customer success”: small fixes and enhancements that make current customers happy but don’t move the needle on strategic goals. 10%-20% is usually a good target. You’ll also need a percentage for “tech budget”: retiring tech debt, tools upgrades, refactoring, etc. 10%-20% is usually a good target, although for startups with lots of tech debt this may be higher.
The result is another spreadsheet tab, where one axis is time (e.g. quarters) and the other axis is the percentage of capacity you want to spend on each business goal, plus “other” items like customer success and tech budget.
Now you need to know the total capacity of your team in each quarter. Work with engineering leaders to roughly estimate total team capacity, on a quarter by quarter basis, using any metric that Eng prefers: story points, months, whatever. Something quantifiable, and translatable to the cost units from your roadmap.
Make sure to include expected capacity increases from hiring, onboarding, etc.
It may be appropriate to model a few possibilities, e.g. flat hiring vs. accelerated hiring.
It may be that Eng has never done capacity planning like this. If so, see what you can estimate. It doesn’t need to be perfect.
Multiply (9) by (10) to get per-business-goal capacity for each quarter, after deducting customer success and tech budget allocations.
Now take the per-goal, ranked list of investments from (8) and start assigning them to quarters until you run out of capacity, then move to the next quarter, and so on.
What happens now is a brutal reality check when everyone is horrified at how little of the roadmap can actually get done in each quarter. Once everyone gets over the shock, you’ll want to collaboratively revise the roadmap and start cutting things or rearranging priorities. This often happens at every step above too, but it *always* happens as soon as dates are attached and calendar reality sets in. The result is much less ambitious…but much more realistic.
A common response to this reality check is for teams to realize that something more fundamental needs to change, e.g. planning more fundraising, cutting big parts of corporate strategy to focus on core needs, etc. This is good! Bringing unrealistic hopes down to earth is part of PM’s job.
You may be asked to build a few “what if” versions of the roadmap, e.g. what if we get an extra $10M of funding next quarter? Work with your Eng counterparts to translate those possible changes into capacity numbers, and rinse and repeat the steps above.
Congratulations, now you have a draft roadmap! Communicate the results out to the wider team.
Be transparent about the process, goals, and why things ended up like they did. The more you de-mystify the process, the less FOMO and griping you’ll hear from people who weren’t in the meetings.
Ask for feedback, and adjust in response to inevitable mistakes.
Publish the roadmap in an internally-public place, and invite async feedback.
Review it in an all-hands or whatever convenient non-async venue the company has. Encourage feedback.
Be humble about expected changes, slips, etc. and help team to understand the inherent uncertainty and guaranteed changes that will ensue. Don’t lose credibility by being too certain about uncertain outcomes.
Rinse and repeat. Generally I’ve found that a good cadence is:
Every quarter, adjust priorities and target quarters for everything on the roadmap. Publicize any changes (and explain why) so no one is surprised.
Every year or so (maybe every 6 months in earlier stages), GOTO 1 and fully reassess the roadmap in light of market changes, new business goals, competition, etc.
An important part of updating the roadmap is improving the accuracy of estimations of completed features and capacity estimates for completed quarters. If they’re way off, then work with your Eng colleagues to improve the accuracy of future estimates.
For the first year or two, *everyone* will probably want to be involved in building the roadmap.
This will make your first few meetings large and chaotic while everyone figures out the process and their place in it. And you’ll get a lot of feedback from the team, some of it randomizing. This is OK. Roll with it. Roadmapping, especially at first, is often a weird combo of business strategy and corporate group therapy.
But if people are comfortable that the process is OK and the output matches what they think is good for the business, then usually within 6-24 months most people get bored and they’ll start trusting that the right thing will happen even if they weren’t sitting in all the meetings. By Year 3-4, it’ll probably be just you, other PMs, Eng and Design leaders, hopefully the CEO, and token representative from Sales, Marketing, Support, and Customer Success. When most of your colleagues think of roadmapping as a boring and predictable process, you’ll know you’ve succeeded.
Nothing of above should be set in stone. The best process is a process that the team likes and that produces a good outcome. If any of above isn’t working, then change it! Be flexible.
Building your first roadmap (getting to Step 14) usually takes about two months. Much of that will be delays wrangling calendars for the group meetings, and follow-ups and research needed to resolve open issues and contentious items.
Caveat: big companies build roadmaps differently
I’ve seen the process above work well in smaller startups, meaning <100 employees, <$20M in revenue. It also works well at the team level in a larger company.
Where it won’t work is across teams in a big company, where executives are jockeying for resources and complex personal and strategic dynamics are in play. It’s not realistic to expect 10 teams’ general managers to sit in the same room and come to a consensus agreement that, for example, 2 of those teams shouldn’t exist. The myopic motivations of each team are too strong for solid company-wide prioritization to happen without the CEO forcing it to happen. You’ll need a different process than what’s detailed in this post.
Caveat: a roadmap won’t fix a broken company
I mentioned above that roadmapping can sometimes feel like corporate group therapy. It can expose and help to resolve misalignment and misunderstandings among your colleagues, and can help your team commit to shared goals and priorities even when not everyone was in alignment when the process started.
But PMs moonlighting as amateur corporate group therapists only works if your startup is fairly healthy to start with, meaning:
The CEO, co-founders, and executive team mostly agree about the company’s business goals and the high-level strategy to achieve those goals. Roadmapping can refine and improve a business strategy, but it can’t create a strategy from scratch.
People in your company are mature enough to know how to compromise, and how to resolve disagreements using evidence and/or consensus, with the CEO acting as tiebreaker or veto-er when needed. And when decisions are made, they’re not forever re-litigated.
Your colleagues are not delusional; they can adjust to realities of customer demand, investor challenges, engineering capacity, and calendar time.
Interpersonal dynamics are healthy enough that getting folks in a room together won’t devolve into a shouting match.
Your startup doesn’t need to be perfect to make a good roadmap. All startups are dysfunctional in their own special way. But there’s a difference between moderate misalignment and personality quirks (which roadmapping can accommodate) vs. more serious problems like founders at war with each other, delusional executives, or toxic personalities that derail progress.
If you don’t have a baseline level of teamwork, then you don’t just have a roadmap problem. You also have a more fundamental HR problem that the CEO (and perhaps the board) will need to resolve, and you may need to start polishing your resume. Fixing a broken company is way beyond the scope of this post!
What do you want to hear more about?
I could write a whole post about any of the 17 bullet points above, but I wanted to start with an intentionally-brief overview.
What do you want to learn more about? What parts are unclear or need more explanation? Let me know in comments here on this post, or hit me up on Threads or Twitter.