Most roadmaps are setting up their product teams to fail.
That's because, even today, most roadmaps still follow the dreaded *timeline roadmap* format
And here's why that sucks. THREAD
That's because, even today, most roadmaps still follow the dreaded *timeline roadmap* format

And here's why that sucks. THREAD

The old school way of roadmapping is a timeline format. You can tell it's still popular by just doing an image search result for 'product roadmap' and seeing the resulting mess.
But here's what's wrong with the format...
But here's what's wrong with the format...
If you deconstruct a timeline roadmap, it's basically just a chart, with:
-
Time on the x-axis, creating a timeline
-
Things to do on the y-axis
Which is simple at first, but the further out that timeline stretches, the more you're making things up.
-

-

Which is simple at first, but the further out that timeline stretches, the more you're making things up.
A timeline roadmap, by its very format, means that you are giving a due date and duration to every thing you're putting on that roadmap.
That's a whole lot of assumptions you're making there
That's a whole lot of assumptions you're making there

One assumption you're making when you make a timeline roadmap is that you know how long each feature is going to take.
This might be easy in the short term when you've got clarity from your developers on delivery plans, but it gets harder and harder the further out you plan.
This might be easy in the short term when you've got clarity from your developers on delivery plans, but it gets harder and harder the further out you plan.
Having a timeline roadmap also forces you to assume that nothing else is going to come in and disrupt your plans.
No new competitors, no changes in the market, no need to change your plans...
No new competitors, no changes in the market, no need to change your plans...
You're also assuming that each feature you build is going to work as soon as you finish it, and that your timeline roadmap can continue along at some magical cadence without looking back.
(For what it's worth, I've never met a product team who gets everything right the first time. Every product and every feature needs to be open for iteration and therefore changes in their timeline!)
And the last assumption any product team working with a timeline roadmap is making is that each feature on the roadmap actually deserves to exist! That each one is the right thing to build and therefore should be assigned a delivery date and codified into the strategy.

And that's a dangerous assumption given how fact things *do* change.
So this is why I implore all the product people of the world:
DITCH YOUR TIMELINE ROADMAPS!
There are alternatives that won't set you up for failure:
DITCH YOUR TIMELINE ROADMAPS!
There are alternatives that won't set you up for failure:
Step 1: Start with a product vision
Here's a format that works well. It's the elevator pitch template from @geoffreyamoore's fantastic book, Crossing the Chasm, and it asks the right sort of questions to get you started on your vision statement.
Here's a format that works well. It's the elevator pitch template from @geoffreyamoore's fantastic book, Crossing the Chasm, and it asks the right sort of questions to get you started on your vision statement.
Step 2: Think outcomes, not output
Your roadmap should be tracked to company-level objectives, not a pile of features for features' sake.
We here at @ProdPad like to use OKRs (Objectives & Key Results), and show the objectives off on our roadmap in bright colours.
Your roadmap should be tracked to company-level objectives, not a pile of features for features' sake.
We here at @ProdPad like to use OKRs (Objectives & Key Results), and show the objectives off on our roadmap in bright colours.
Step 3: Switch out your timeline for time horizons
It makes sense: You've got greater visibility on the things right in front of you, and less on the things further away. Each column represents a change in visibility and flexibility in your roadmap.
It makes sense: You've got greater visibility on the things right in front of you, and less on the things further away. Each column represents a change in visibility and flexibility in your roadmap.
Combine the vision, your objectives, and your time horizons to articulate your product strategy in a new way. Ditch the timeline roadmap and embrace the lean product roadmap.
Here's a couple ways yours might take shape:
Here's a couple ways yours might take shape:
Remember, your roadmap is not meant to be a perfect plan of everything you're doing.
Your roadmap is a prototype for your product strategy.
It's meant to change as you learn more, and a lean roadmap format gives you that flexibility.

It's meant to change as you learn more, and a lean roadmap format gives you that flexibility.
At the end of the day, the value isn't in the 'roadmap' itself. It's in the process of roadmapping, which is inherently a discovery process.
(Just as the value of a prototype isn't the prototype, but in the prototyping and all of the learning that comes from it).
(Just as the value of a prototype isn't the prototype, but in the prototyping and all of the learning that comes from it).
And so that's why timeline roadmaps are causing product teams to fail, and why the switch to lean, discovery-centric roadmapping processes is so important.
Thanks for coming to my TED talk
Thanks for coming to my TED talk

Woah, this hit a nerve!
This is probably a good time to mention that me and my team at @ProdPad do roadmap troubleshooting clinics to help #prodmgmt folks like you
Sessions are free and you can sign up here: https://www.calendly.com/prodpad/roadmap-clinic
This is probably a good time to mention that me and my team at @ProdPad do roadmap troubleshooting clinics to help #prodmgmt folks like you

Sessions are free and you can sign up here: https://www.calendly.com/prodpad/roadmap-clinic
UPDATE: I'm getting so many great questions off the back of this, and it just goes to show how tricky roadmapping really is!
Keep them coming in the comments and I'll get to them all
I might write this up as a big FAQ about roadmaps and their pitfalls. Would that be helpful?
Keep them coming in the comments and I'll get to them all

I might write this up as a big FAQ about roadmaps and their pitfalls. Would that be helpful?
Convincing stakeholders is the trickiest bit of this!
Based on all your great questions, I wrote an article that tackles the objections you might run into and how to tackle them: https://www.mindtheproduct.com/free-your-product-roadmap-and-ditch-the-timeline/
Based on all your great questions, I wrote an article that tackles the objections you might run into and how to tackle them: https://www.mindtheproduct.com/free-your-product-roadmap-and-ditch-the-timeline/