How to pull a Product Roadmap out of Thin Air
At some point in your PM career, you’re going to get that call: “We need a roadmap. By Friday”. No matter the company size, the industry you’re in, or the type or maturity of your product, three things are universally true about the above call:
- “We” need a roadmap, but “you” need to provide it because you’re the PM
- All the concerns you’ve raised over the last few weeks/months/ years are still valid, but this time it’s different…
- It’s needed by Friday. It’s always needed by Friday.
In the best-case scenario, you already have some form of the Product Management Stack in place. Ideally, you already have a roadmap pointing to the direction of your company and/or product’s vision, know which OKRs & metrics you will use to measure success, and it’s all backed by a prioritized & validated product backlog. All you have to do is the last bit of connecting the dots for everyone to see.
But the “roadmap by Friday” call usually comes in when there’s lack of clarity, lack of alignment, lack of trust or all of the above. It’s fair to assume that at this point that:
- Things are not working as they should (presumably despite your best efforts as PM)
- You don’t have the time to fix what’s not working by Friday
So what do you do when no one listens to your questions, but everyone is looking to you for an answer… by Friday? For the sake of this exercise, let’s assume that out of all the options available to you, you choose to say yes. Yes, dear stakeholder, we will have that roadmap by Friday, and it’s going to be awesome.
In order to do that, we’re going to solve the problem of creating a roadmap using the only way we know as PMs: We’re going to treat our roadmap as a product, and that product has a release date of this Friday. Let’s dive in.
We’re going to solve the problem of creating a roadmap using the only way we know as PMs: We’re going to treat our roadmap as a product.
1. Resist remorse
Your first thought — and one that is likely going to recur a lot during the week — is, how did I get myself into this situation? Resist the urge to answer that right now. When you are lost in the wilderness, you need to focus on finding your way back to civilization, not blaming yourself for getting lost.
However, do make notes as you progress, because every release is followed by a retrospective. You must learn from this experience what you can do differently, for it not to happen again. Moving on.
2. Gather & prioritize requirements
First, take stock. My frame of reference is what I call the Product Management Stack, but YMMV. What do you have available to you that you can put to use? Which people can you rely on for support, if any? Where can you save time? What can you reuse or adapt?
Most importantly: What is expected of this roadmap? What questions should it be able to answer? What direction is it meant to provide?
Also importantly: What is out of scope? Sometimes (often), there’s a difference between you, as a PM, think the ideal roadmap should be vs what you… actually need to communicate by Friday. Relentlessly cut scope.
Prioritize the must haves, should haves and nice to haves. This will help you break the work down into manageable pieces, delegate where possible and prevent you from overcommitting at best and slow burnout at worst.
Finally, think about what tools you would be using. Do you have to use a specific format? Can you draw something on a whiteboard and snap a picture of it?
3. Design
There are several different types of roadmaps, each suited to a different purpose and a different audience. Depending on the requirements (above) and the time available, your next job is to choose the appropriate one. Let’s look at a few common ones.
a) The Executive Roadmap
The focus here is on alignment across teams/departments, towards key dates, typically spanning quarters. It’s relatively light on details but uses visuals to connect clear goals to a well-understood org structure.
Use this to answer executive-level asks like “What is the overall plan?” and “What is needed from my team to get us there?”
b) The Engineering Roadmap
This type of roadmap is tactical rather than strategic. It could be a sprint-by-sprint development plan, or whatever else is available at hand. For it to be reasonably accurate, it needs a lot of groundwork and collaboration with engineering leads and scrum masters.
Use it to answer tactical questions like “When will feature X be ready?” or “When will we have enough features to release an MVP?”
A variation of this is the Agile Roadmap, which typically groups features by theme and provides a general timeline:
c) The Feature-Based Roadmap
ClickUp has a roadmap here that lists only features, but no release dates.
While this is unlikely to satisfy your internal stakeholders, this might be all you need to provide overall direction, answer burning questions and buy yourself more time to do more validation.
d) The Investor Roadmap
Yes, the above image is a roadmap too. In fact, there’s a whole collection of them here[1]. This type of super-abstract roadmap obviously needs context around it, but it emphasizes strategic direction without getting into the weeds. Sometimes, you don’t need a detailed roadmap until the high-level direction has been agreed upon.
e) The Quick-n-Dirty Roadmap
A bunch of post-its grouped by theme and laid across time can serve as a roadmap too. This approach is very common in UX teams and in startups in the product discovery phase, when things are changing often.
Use this if you have the luxury of prioritizing function over form. Once you’ve been able to convey key messages and build alignment, you can improve readability later.
f) The Outcome-Based Roadmap
Gibson Biddle explains these in his article here[2], and Marty Cagan has been preaching them for decades. Use them when you know what you need to solve and what metrics you’ll use, but you’re not exactly sure how you will get there.
g) The Public Roadmap
Unreal Engine has one of the most unconventional roadmaps I’ve ever seen. Check it out here[3].
This is an example of a roadmap that serves the developer community and partners, and it has none of the elements of a conventional roadmap such as themes and quarters. Sometimes you need to think out of the box, because that’s what your audience expects of you.
3. Build it
Now that you’ve primed your creativity, it’s time to put things into action. Choose a format that best suits your needs, keep it flexible & open to feedback and remember:
- The message is more important than the medium
- A roadmap is a “map of roads. If your outcomes are pre-determined (we will deliver X by Y with 100% confidence), you’re building a tunnel, not a roadmap.
Here are some excellent tips on the elements of a good roadmap[4], courtesy of Mind the Product.
Depending on how (un)realistic expectations are, one more element you can weave in is what I call the “contingent clause”: “We will be able to do X by Y assuming Z,” e.g. “We will be able to launch the new web portal in July assuming we can lock-in the licensing agreement by March.
If you still think your challenge is insurmountable, consider the fact that SpaceX once took a stab at a roadmap to “Becoming a Multiplanet Species”[5]. Surely, you can get some form of your product roadmap out by this Friday.
4. Release Early, Release Often
Start with the outline and get feedback as soon as possible. Have your roadmap peer-reviewed if you don’t feel confident about opening it up to senior stakeholders. Use proxy stakeholders (e.g. leaders from adjacent departments). If you have the time, dry run your presentation with someone else. You’re not looking to practice your words; you’re looking for feedback on what’s unclear and what questions might come up. Test and validate as much as you can. Then go back and iterate.
Before you know it, Friday will come around, and you will present your roadmap to thunderous applause and recognition. (At least that’s how you should visualize it anyway :) )
5. Reflect
Regardless of how your hard work is received, there’s an opportunity here. Firstly, you will learn more about your audience and the communication style that will likely work in the future. You would have also forged stronger relationships with others as you collaborated with them on a timeboxed mission. Finally, reflect on the process you followed & the outcomes you achieved, and then work your way backwards to figure out how to avoid this rush in future.
You might need to take the initiative to proactively set up regular roadmap reviews. You might need to work more closely with your peers to keep your roadmap updated more frequently, so that it is available on demand. You might need to refresh some processes, or the sources of data you rely on, in order to make your roadmap more relevant on a continuous basis. You might realize you have blind spots or gaps in your knowledge that need to be covered.
The best thing you can do the next time is Be Prepared. Roadmaps are hard to put together but easy to forget. But they also represent an opportunity to improve alignment & focus and uncover challenges. They are a PM’s most important tool for communication and connection. While you may be able to put one together on short notice using assumptions and approximations, the more time you put into building & maintaining your roadmap on an ongoing basis, the less likely you are to get that call.
If this article helped you, please follow, share and reuse at will. I’m happy to hear your thoughts and continue the discussion here, on Twitter or LinkedIn. Thanks for reading, and have a great year ahead!
Dive Deeper
- Ten most successful startup presentations, Twitter thread by Alex Banks
- Project-based vs Outcome-based roadmaps, newsletter entry by Gibson Biddle
- Unreal Engine Public Roadmap
- Product Roadmaps in 5 Easy Pieces, article by Scott Colfer in Mind the Product
- Roadmap to Becoming a Multiplanet Species, spacex.com
