Building and publishing your first product roadmap can be a daunting experience. From getting stuck in the weeds to committing to dates, there are a number of pitfalls you can fall into building your first roadmap.
Here are a few product roadmap dos and don’ts to guide you through the process.
1. Don’t trust engineering’s dates as gospel.
Remember the Y2K scare? In case you’re too young to have lived through it (and have never heard the hilarious stories), Y2K was a global panic in the late 1990s that the world was going to meltdown on January 1, 2000. Why? Because, supposedly, computers everywhere — including the ones operating hospitals, traffic signals, airplanes, banks, and nuclear silos — would get confused at midnight as the date shifted to 1/1/00, then go haywire and ultimately shut down because they’d think it was actually New Year’s Day in 1900.
Then 1/1/2000 came and… nothing happened.
So apparently, computer engineers built what they later realized might be a terrible bug into their systems — which would totally confuse every computer in the world as to which century it was. And then, when they spotted the potential problem, those engineers were just as wrong in their prediction about what would happen as a result.
It might be unfair to bring up the humiliating Y2K incident as a way to warn against putting too much stock into the dates your engineering team offers you. But the point stands: Your development team will often be wrong in their estimated timeframes for completing work on your products.
So don’t simply add your engineers’ date estimates to your roadmap. Once you do, those estimates become yours — and you become responsible for them.
Tweet This:
“Don’t trust engineering’s dates as gospel. Keep dates on your roadmap as broad as possible.”
Better options would be either not to include dates at all on the roadmap (particularly if you are planning to share your roadmap with customers) or to keep any dates on the roadmap as broad as possible — “2H2018,” rather than “November 1, 2018.”
2. Do make your roadmap gorgeous (or at least not ugly).
Sounds like a superficial point, right? Who cares what a product roadmap actually looks like?
So, here’s a challenge for you. If you work for a company with other product managers on your product team, and one of those PMs uses some visually boring tool for their roadmaps, go to one of that PM’s roadmap meetings — and sit through the entire thing. As the poor product manager drones on saying, “As you’ll see, the 17th item on the list here is…” you’ll have difficulty staying awake. And you’ll notice that everyone else in the room has the same problem.
This is one reason using native roadmap software is such a smart idea. It makes for roadmaps that are easy to grasp at a glance, and it allows your meeting’s discussions to move naturally through the big-picture strategic items on the roadmap because everyone can easily see everything in relation to everything else.
And because these tools allow for real-time, drag-and-drop updating of any item on the roadmap, your meetings will be even more productive, as everyone will know that if circumstances call for it, the roadmap’s epics, features, and priorities can be rearranged as needed during the meeting.
3. Don’t draft your roadmap like it’s your debut novel.
There are places for a product manager to present their product’s vision, plans, and updates in narrative format. Vision statements come to mind. A trip report after an industry tradeshow that led to great learnings about your customer persona would be another opportunity to write a long-form explanation of your latest product insights. Take as much space as you need.
But a product roadmap needs to be high level. It needs to capture only the strategic essence of any theme, epic, story, bug fix, or another item. Any more detail and your roadmap will lose focus, its readers (including your stakeholders) will lose interest and the clutter will create confusion about what you’re actually planning and why.
Want to flex your writing muscles? Write a vision statement. Take up poetry. But when you’re creating or updating your product roadmap, it’s probably best to think of it as “designing” rather than “writing.” That’ll help you keep the words needed to communicate your strategic plan to a minimum.
4. Do focus on themes and epics, rather than features.
When your product roadmap amounts simply to a list of features, a couple of things happen, both bad.
Tweet This:
“When building a product roadmap, focus on themes and epics — not features.”
First, your engineers take it as a sign that you don’t trust their abilities. Yes, they often have difficulty with dates (see above), but they know the technical details of building products better than you do.
This is why they prefer to see your product’s strategic plan from an epic and theme standpoint. When they understand those bigger-picture goals, they’ll figure out how to define and implement the features needed to bring those goals to reality.
The second problem with focusing on features rather than epics and themes is that everyone viewing your roadmap — including you, over time — can lose sight of the product’s larger strategic purpose and how it’s supposed to add value for your user personas. When you’ve just thrown a dozen features onto your roadmap and you check back in with it in a few months, will you still remember exactly what strategic value all of those dozen features add?
There are plenty of places to capture and track individual feature ideas. But to whatever extent possible, try to minimize their presence on the roadmap.
5. Don’t develop your roadmap in a nuclear bunker.
When product managers go off to their silos to draft their product roadmaps alone, it doesn’t matter how much research material they drag into the silo, or how great their instincts are. They will almost certainly lose out on some of the best insights and learnings because they aren’t involving all of the other rich sources of knowledge across their company.
Rope in your sales team, your marketing team, your customer support team, and people from any other departments that are regularly on the front lines with your customers or the public. You don’t have to give all of these people a seat at the table in your planning sessions, but seek out their knowledge before you start hammering out the roadmap.
6. Do expect that your roadmap will have to change.
It would be easier if you could just draft your product roadmap once, publish it to the relevant people across your company, and insist that THIS DRAFT IS FINAL.
But things change. Priorities change. Budgets change. Epics that seemed so important a few months ago… now? Not so much.
So it’s a good idea to think of your product roadmap, even the one you publish and present to stakeholders, as reflecting your latest strategic thinking as of now… not forever.
This is another reason it’s such a good idea to use web-based, purpose-built roadmap software. When you do so, as opposed to trying to make due with a static presentation or spreadsheet document, you will be able to add an epic, switch priorities of two items, or add a line of strategic thinking to your roadmap in seconds and from anywhere.
And you will have to make changes like these to your roadmap throughout the development process. There’s no way around it. So the more you can think of your roadmap as a working, living document — and not your set-in-stone product-plan masterpiece — the more success your products will ultimately enjoy in the market.
