A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. Creating a product roadmap is a multi-step process, as you will first need to determine your product vision and strategic goals.
In this post, we will walk you through the four basic steps of building your first product roadmap from scratch:
- Determine the “Why” for your product — its strategic reason for being.
- Determine your audience and tailor the roadmap to resonate with them.
- Prioritize your product’s strategic themes — and begin building the actual roadmap.
- Stay flexible — because your roadmap will change.
Whether you’re new to product management or an experienced product manager who just hasn’t had to build a new roadmap in a while, this undertaking can seem like cleaning out the garage or learning French — a project so overwhelming you’re not sure how to take the first step. Actually, it’s even more difficult than cleaning your garage or learning a new language — because you have the added pressure of knowing that the roadmap you create will eventually be viewed, scrutinized and possibly debated over by stakeholders across your company and maybe even by your customers.
As a company that has helped thousands of product managers develop and share their product roadmaps, we offer you the following high-level guide to creating a product roadmap from scratch.
Before we jump into that guide, though, we offer you the following warning. If there is only one insight that you take from this post, let it be this…
A product roadmap is not an operational to-do list. It is a strategic document designed to help you develop a plan for your product and to keep your team on track in executing that plan.
“A product roadmap is not an operational to-do list. It is a strategic document.”
It can be very tempting for a product manager in need of a roadmap to simply say, “I’ll just write out all of the themes, epics, and features we need for this product — and we’ll use that as our roadmap.” Although this sounds logical, and it is an easy way to get something down on paper quickly, it will likely lead to all sorts of problems in your product development. You’ll see why as we walk through the guide below.
1. Before you do anything else, first determine the “Why” for your product — its strategic reason for being.
Why are you developing this product, at this time, in this way, prioritizing these product attributes, for these users?
Those are the key strategic questions you need to ask yourself and your team at the outset of any new product development or update to an existing product. If you can’t answer those questions — ideally with data to support your answers — then you can’t reasonably justify spending any time and resources on the product at all.
It’s amazing how many product managers, even experienced and talented ones, skip this first step. Perhaps they assume they know the answers in their gut and don’t need to clearly articulate them out loud or on paper. Or maybe they’re just in a hurry to get a roadmap into a document because they have a stakeholder meeting coming up. But trust us — if you’re not prepared to answer these key strategic questions about your product’s reason for being, that stakeholder meeting will not go well for you.
Moreover, this first step will reward you in a major way throughout the development process and well beyond your product’s launch. Determining your product’s reason for being with your team up front will make all of your downstream decisions more strategic and cohesive, and ultimately, it will lead to a more successful product.
Indeed, returning to our point about that initial stakeholder meeting, when you can clearly articulate the “why” behind your strategic proposal for your product — and do so in a way that the roadmap communicates strategy how the product will contribute to the company’s strategic goals — you are much more likely to have your roadmap resonate with your stakeholders and earn their support to proceed.
2. Determine your audience and tailor the roadmap to resonate with them.
This is another pitfall many product managers fall into. They create a single roadmap — often using a makeshift roadmap application such as spreadsheet or presentation software, as opposed to using a purpose-built roadmap tool. (Here’s why improvised roadmap software is a bad idea.) Then these product managers present that roadmap to every team or group they meet with. That means their executives and investors see exactly the same roadmap view that their developers see, and that same roadmap may even be shared with customers.
But remember, a product roadmap is a strategic document, and your strategic objectives in sharing it with your executives will vary wildly from your objectives in showing it to the marketing or development team.
Here’s a good rule of thumb. If you are using an identical roadmap document for every audience you present to, you are not doing your job as a product manager. Why? Because when your executive stakeholders gather around your roadmap and say, “Show us what you’re planning”, they don’t want to see the ground-level details of every feature. They want to see how it will help the company increase market share, or what it will mean to your revenue numbers for the next two quarters.
By contrast, when you have a roadmap meeting with your development team, and they want to know what you’re planning, your presentation needs to focus on what the product’s development will mean to them — what technology you’ll be asking them to use, what timeframe they’ll have to get the work done, and what their day-to-day tasks and priorities will be.
This is a critically important component of developing your roadmap. You need the ability to present different views and varying levels of detail depending on the team or audience you’re presenting to.
I’ve shared an example below, here are three roadmap examples to help get you started. If you’re looking for a technology roadmap, these example technology roadmaps are useful. If you’re looking for a marketing roadmap, these example marketing roadmaps are great!
You want your management team to see a roadmap that gives them confidence your product will help meet the company’s strategic objectives. You want your sales teams to see a roadmap that clearly shows them how they can convince prospects the product will meet their needs. And you want your developers to see a roadmap that clearly explains what you’ll need from them and why their work will matter to the product’s ultimate success.
What this means is that, in terms of your roadmap development, you have two choices. You can use a static document tool like a spreadsheet, and then create several different versions of the same roadmap in spreadsheet format. (Again, bad idea.)
It’s worth pointing out here that when you build your roadmap this way, you will need to manually update all versions of it every time priorities, dates or other elements change in your development. Failing to update all versions of your static-document roadmap can quickly lead to version-control problems with the roadmap files and people working on the wrong things.
“Determine your audience and tailor the roadmap to resonate with them.”
Alternatively, you can use a purpose-built roadmap tool to develop a dynamic and visual roadmap that will be easy to present at the right level of detail to the right audience.
3. Prioritize your product’s strategic themes — and begin building the actual roadmap.
At this point, you’ve set the foundation. You’ve determined your product’s strategic reason for being. And (we hope) you’ve found the right roadmap tool. Now it’s time to start typing.
So, where do you start? What goes onto the roadmap first?
Up to this point, you have approached every step in the roadmap creation process from a top-down, strategic point of view. You should use that same approach when building the actual details of your roadmap.
Start by determining what the major themes of the product will be. For each of those themes, create a swim lane on the roadmap. (Remember, if you’re using the right purpose-built roadmap tool, you can always move these themes around later with a couple of clicks or a drag-and-drop, if you need to change the order of priority or move everything back in the timeline.)
Now that you have a series of major themes, you can start layering in epics beneath them. And if you determine you need additional detail, you can also layer in specific features beneath each epic.
The point is that you want to start at the strategic level with every detail you add to the roadmap. Just as you first determined your product’s reason for being, you’ll want to apply the same thinking to each theme, asking why that theme deserves a place on the roadmap — and which specific place it deserves in relation to the other themes, and why.
4. Stay flexible — because your roadmap will change.
Finally, as you’re building out the details on your roadmap, you’ll want to keep in mind that none of those details are set in stone. Companies’ priorities change. Resource levels change. Moves by competitors can force a product’s development or release schedule to change.
“Stay flexible — because your roadmap will change.”
So you want to create your product roadmap — and present it to your various audiences — in such a way that leaves room for the inevitable updates, tweaks, and course-corrections along the way.
And if you can tackle building your first roadmap strategically, and in the order we’ve outlined here, you’ve got the makings of a successful product roadmap.
Do you have additional recommendations for building your first roadmap? Please share them in the comments below.