Eisenhower was responsible for planning the Normandy landings, the liberation of Western Europe, and the invasion of Germany (source). He did a solid job. Good planning?

On Writing Product Roadmaps

Gaurav Oberoi
Published in
13 min readSep 20, 2017

--

It’s not uncommon to think of roadmap planning as a pointless exercise that’s done for management’s sake. Why commit to future deliverables if you have low confidence in hitting them? How can one plan months out when requirements keep changing? And when have engineering/design/marketing estimates ever been trustworthy enough for this to work?

These are valid concerns, but they don’t remove the need to plan. In this post, I’ll demonstrate, with an example, that for teams past the product-market-fit stage, roadmaps are critical. This will be most useful for product managers in mid-to-large orgs (50+ people).

Roadmaps are a tool to think about your product beyond the next couple of sprints. They force you to plan, communicate, and get buy in. The win is that your team is aligned, can focus on execution, and reliably achieve long term goals.

First, an Example

Suppose you work at:

A company that runs a vacation booking site (like Hotels.com or AirBnb.com but smaller). You are the product manager on a team of about 10, mostly engineers, with some folks for design, ops, qa.

And you don’t have a roadmap planning process:

Your organization is used to planning on the order of 1 to 2 sprints, which is about 2 to 4 weeks. This works well for shipping features in the short term, but you begin to see issues with longer-term planning. For instance:

  • Your exec team wants to go international and is urging you to agree to “early next year” so they can tell the board, and do financial planning. → Do you warily agree, or risk not being a “team player” by pushing back to avoid overcommitment? How do you confidently plan and commit?
  • There is pressure to build a mobile app, but it’s a huge investment (major refactoring, hiring mobile devs, user acquisition) without clear business value. The exec team wants to know why you can’t you just start and try it out next quarter. → It’s so easy to say yes and just roll with it, but as the product owner, it’s your job to keep the org focused on real business value.
  • You have to fix low checkout conversion soon; but there’s no silver bullet and you need to test various ideas that have been floated by stakeholders across the company (marketing, customer ops, etc.). → How do you commit to a list that you believe will work, and the org will agree to, while also communicating that these are ultimately tests, not guarantees of success?
  • Your engineering lead tells you that he is tired of dealing with late night alarms, and that you need to make time for critical infrastructure tasks instead of always dropping them from sprints for feature tasks. → Sometimes you need to prioritize refactoring and cleanup, and other times you need to convince the team that it’s not worth it. How?
  • The quarter is going along just fine, but suddenly, BAM!: the exec team/head of sales/head of marketing just had a killer meeting with a customer/investor and wants to drop everything to build feature X right now. → How do you push back by effectively communicating the tradeoffs of a late stage pivot? Or how do you address legitimate needs without whiplashing and demoralizing your engineering team?

Roadmaps are not a panacea, but without some future direction, expect the classic problems of failing to plan: missed deadlines, working weekends, shipping unfinished work, political infighting, and ultimately, lost opportunity.

Now suppose you do some roadmap planning:

To illustrate, I’ve created two different documents that show how this org might plan for the future: the first is a detailed plan for the coming quarter, and the second is a vague but longer-term plan for the coming year.

  • Read next quarter’s detailed roadmap. (6 minutes)
    This is a specific plan on what to deliver over the next 3 months. It focuses on a couple of key goals, and then goes on to enumerate what needs to be done and why. I’ll discuss later on how to motivate the entire org behind a plan like this, but first, have a read to get familiar with this approach of quarterly roadmap planning.
Example of a detailed quarterly roadmap.
  • Read future planning notes. (2 minutes)
    This is not an actual plan, but bulleted notes that capture discussions with key folks who help drive our roadmap (exec team, Sales/Marketing leads, customer feedback, etc.). The value of this doc is that it lets you communicate what kinds of major projects the company does want to do some day, but just aren’t a high enough priority to do now. It also helps you think about ordering and priority on a longer time scale.
Example of longer-term planning notes.

These documents are the result of critical thinking about the future, and lay the groundwork for successful execution. But for these plans to work, so much more has to happen: getting buy in, specifying details, addressing changing requirements, dealing with poor estimates; etc. In the following sections, I’ll describe how to use this tool to improve execution and delivery.

Psssst. Have you read the examples yet? You’ll get more value out of the rest of this post if you do.

A Guide to Product Roadmaps

What is a product roadmap?

A three month plan that describes what your team is going to build, and why; and an accompanying process to set clear goals, commit to deliverables, and identify risks.

Why create a product roadmap?

  1. Lead → set clear goals for the org to get behind.
    Organizations need clear and consistent leadership, and roadmaps are a tool for effectively doing that. But even when goals are murky, and leadership is still figuring it out, roadmaps create a forcing function to make a choice and set clear direction. In larger orgs, this also means creating a unified agenda, and eliminating conflicting goals.
  2. Plan → enumerate deliverables and timelines to achieve those goals.
    Having clear goals is not enough, you also need a believable plan to get there. All orgs realize the importance of planning, but many struggle to do it effectively. Some don’t treat planning like a project that takes time and has deliverables, while others don’t seriously commit to plans made. A roadmap creation process allows stakeholders to have a voice, and forces everyone to prioritize, commit, and execute together.
  3. Communicate → get buy in, set accountability, and align the org.
    Your roadmap is only as useful as the your org’s willingness to accept it. If stakeholders keep butting heads on priorities, devs roll their eyes at estimates, or it seems that roadmaps always come from “up on high” with minimal input from the team — your planning process is broken. Use roadmaps to have discussions about your companies priorities, projects to get there, and timelines, so everyone understands the what and the why.
  4. Deliver → create a reliable cadence for shipping, build confidence.
    An important aspect of product management is driving excellence in execution. If you can repeatedly set impactful goals, with realistic deliverables, and hit them — you and your team will feel like and be treated like rockstars by your customers, peers, and management; and you will have mastered an important skill to grow your business.

How often should I create a roadmap?

The process below is what we used effectively at SurveyMonkey as it scaled from a company of 50 to 700 people. This should work well for most software teams, though tweaks may be needed for enterprise products, physical goods (e.g., Harry’s), or hardware components (e.g., GlowForge):

  • Every quarter → define and publicly commit to a detailed roadmap.
    Three months is about the right planning window size for software projects, and works well with financial reporting/planning timelines. I’ll describe this process in detail below.
  • Twice a year → publish a non-committal set of “planning notes”.
    Setup a two hour meeting with your key stakeholders to: (a) brainstorm a list of ideas, (b) prioritize them, and (c) pick a quarter in which they should ideally happen. The aim is not to make specific commitments, but to identify strategy and and align people, e.g. “if we want to do X two years from now, then we have to start doing Y in the first half of next year”; or “woah, we put too many desired items in Q3, and really need to prioritize”.

How do I go about writing a quarterly roadmap?

As a product manager, your job is not to create a roadmap that’s an average of everyone’s desires; but to take the best ideas and data out there, think through it, and propose what must be done. Here’s one approach on how to manage your team leading up to publicly committing to a quarterly roadmap:

  1. Gather ideas → 1–2 hours; start 4 weeks before quarter end.
    This seems early, but it’s not. You need to start the conversation with stakeholders to reason about options, get estimates, and reach consensus. You’ll need: (a) business goals from management (or write them yourself), (b) feedback on what customers want to see in the product (via customer ops, sales, marketing, surveys, etc.), and (c) ideas from your engineers, designers, and by watching competitors. Ask people to quantify the benefit, and state how they’d feel if you didn’t do it in this quarter. Do this 1–1, not as a group to make it more time efficient, and honest.
  2. Write a rough draft → 2–3 hours; 3–4 weeks before quarter end.
    Write 1–3 major goals, and a list of projects that you think are: necessary, nice to have, and out of scope. Prioritization is the core part of this activity, and can be a post unto itself — but the key is to be able to clearly explain why a given project is a good idea (metrics mover, strategic value, customer delight). Do put in your (likely incorrect) estimate of small/medium/large; you’ll improve this estimate soon.
  3. Review with engineering → 1-2 hours; 3 weeks before quarter end.
    Email your draft to the whole engineering team and ask for feedback. Then schedule time with your engineering lead/s to go over estimates. Your engineers will tell you what is realistic and possible, your job is to listen to them, and make the right cost/benefit decision on what should be kept, vs. axed. Some of this is negotiation, but most of it should be based on trust and problem solving — engineers can’t magically squeeze work into available time because the business demands it. You may find that engineers are resistant to providing rough estimates for real commitments. That’s ok — you can capture uncertainty with ranges, (e.g. instead of 2–3 weeks, it’s 2–6 weeks), and either reduce risk by doing as much early specification as possible, or clearly communicate schedule risk to stakeholders where SWAGs are being made on little data.
  4. Review with stakeholders → 2–3 hours; 2 weeks before quarter end.
    Shop this draft around with your key stakeholders (exec team, sales, marketing, engineering, customer ops etc.). Don’t wait till the last week; you may need time to address feedback. Avoid group review, and instead use existing 1–1s with them to go over this.
  5. Get sign off → 1 hour; 1-2 weeks before quarter end.
    You may have to go back and forth a couple of times to adjust, get new estimates, and finalize. Once it’s looking pretty solid, email it out to stakeholders and ask them to respond with a “I agree”. Unless there is major uncertainty or disagreement, you may not need a sign off meeting.
  6. Present it publicly → 1 hour; last week of the quarter
    To the entire company, present outcomes from last quarter’s roadmap, and plans for the new one, even though most in the room should know what’s coming by this point. So why hold this potentially time wasting meeting? To create a venue for accountability, to ensure that everyone (even the most junior employees) understand the plan, and to create energy and urgency to rally the org into the coming quarter.

This is by no means a perfect approach, but one that’s easy to follow, and works reasonably well. Modify it to suit your needs, but try to keep the quarterly presentation. People are social creatures, and public reviews of prior performance, and proclamations of the future create strong incentives to get it right. It’s not foolproof: you will want to ensure that the org optimizes for outcomes, not this process (see Bezos on “resisting proxies”).

Also note that this can be exhausting, especially the first couple of times around. It gets easier as orgs and leadership become better aligned, and as engineering and other parties become more comfortable with this approach.

What should a quarterly roadmap contain?

Your roadmap can take many forms: a document like the one above, sticky notes on the wall, or built using a commercial roadmap tool (like 1, 2, or 3). Regardless of your medium, you’ll know your roadmap is complete if it includes the following key items:

  1. Major goals with the “why” clearly spelled out
    Think of the 2 or 3 things that must happen for your org to feel good about the quarter. Spend time to explain why these are critical so team members are on the same page, and make the right decisions. It is critical that leadership is onboard with these points, and will not undercut them later.
  2. Specific deliverables
    If you can’t immediately look at a line item and answer “done or not”, then it’s not specific enough. E.g., don’t just say “alpha launch”, but do list out what list of features that includes.
  3. T-shirt sizing and priorities
    Try to break down your projects into work that’s no longer than 4 to 6 weeks. Label everything with a small/medium/large so your readers have an idea of how expensive something is. Order projects by priority.
  4. Risks and out of Scope
    Enumerate real risks, typically things for which you don’t have data now, but will get some later — don’t use this to just hedge your bets. Also list projects that people expect you’re going to do now/soon, but aren’t.
  5. Requests to other teams
    As your organization grows, dependencies across teams will increase, and you need to highlight these at the start of the quarter so they can be prioritized, and agreed upon, instead of argued at a later date.
  6. Blank space
    Important requests from other teams will appear, some projects will take longer than planned, and operational issues will eat up time. I suggest 2–3 weeks of unallocated time (yes, 17–25% of the quarter) to ensure you reliably hit your promises, while also addressing unplanned needs (e.g., important bugs, outages, minor feature requests, helping other teams).
  7. Current status
    Note that the last page of the quarterly roadmap is a table that lists out projects, along with their team lead, related docs, and current status. This is what you’ll point stakeholders to when they email you asking “hey, when is feature X going to available?”. Update this every 3–4 weeks.

Ok but I can see lots of ways in which this could go wrong…

Good, because now you can prepare. Here are a few common issues that crop up, and how to deal with them:

  1. How do I deal with constantly changing asks from management?
    It depends. If it’s because your product is pre-product-market-fit, then roadmaps aren’t useful yet since you’re still experimenting wildly. If it’s due to new data (e.g., competition), then it’s necessary to change the plan. Or if it’s because of unreasonable engineering expectations, pressure to hit unrealistic growth targets, political battles, or any number of organizational ills, then… well, work to address the root cause in a professional manner, and consider that even flawed planning is likely to increase your chances of success than none at all (what’s your alternative: do nothing and hope for the best?).
  2. What if I completely misestimate a project?
    Sound the alarm as early possible, and propose how to re-adjust the plan. Take responsibility for the slippage, and try to understand what went wrong so you can account for it next time. There’s no shame in making this mistake, just in not trying to address it as soon as you realize it (in fact you’re likely to make this error several times; scoping up front is one of the toughest parts of planning). Things that help: tighter up front thinking (e.g., writing product specs), healthy pessimism (to spot overly optimistic estimates), and reviewing past errors together (to learn and improve).
  3. How specific should I be on delivery dates?
    In general, you don’t need greater than 2–4 week accuracy, e.g. “we’ll have it done in mid-to-late September”. If you must commit to dates (e.g., for large enterprise customers, or big launches with PR and marketing coordination), it usually helps to be overly conservative — your sales/marketing partners will complain, but they’ll complain more if you don’t keep your word.
  4. Should I share my roadmap with customers?
    In general, no. The reward for doing this doesn’t exceed the cost of getting it wrong. The exception of course is in enterprise products where big customers often require dates. Again, conservatism aimed at hitting goals works better in the long run than missing promises.
  5. What we do works fine. Isn’t this expensive and unnecessary?
    If what you’re doing works, then ignore this and keep doing what you’re doing (and do share in the comments below so we can learn and borrow). In general, smaller orgs, or those supporting products in maintenance mode won’t see as much benefit to this process, but the vast majority of medium-to-large orgs will.

In Conclusion

Quarterly roadmap planning is a difficult and imperfect process: it requires time and investment to do right; collective buy-in from leadership and stakeholders; and constant vigilance to improve the process while making sure that you don’t become a slave to it. But for most organizations, it’s still far superior to not doing any sort of long-term planning at all. As Winston Churchill said of Democracy “[it] is the worst form of government, except for all those other forms that have been tried from time to time” — I feel like the same can be said of quarterly roadmaps.

Read the other post in the series: On Product Specs >>

--

--

I’ve been a product manager, engineer, and founder for over a decade in Seattle and Silicon Valley. Currently exploring new ideas at the Allen Institute for AI.