What’s a Product Roadmap good for, anyway?
Product development starts with building a product roadmap, I was told. But what is the right way to do that? Here’s what I discovered about product roadmaps when building one.
I just delivered a Product Roadmap.
I was appointed Chief Product Officer at SIG last September and gathered a small Product team. Mostly first-timers at this game, including myself. Our mission: provide the functional design of a new platform to propel our organisation into a new level of growth.
“Start by building a Product Roadmap”, I was told.
Ok. Can do. But what does that mean exactly?
What kind of stuff needs to go onto a roadmap, actually? How far into the future should it extend? How much detail should it provide? In what form should we cast the content? Spreadsheet? Commercial tool? Stuff it into JIRA?
Looking for answers
I went looking for answers. Asking some people. Searching online. An article. A how-to. A template. Is there a book, a guru, a methodology that I can grab onto? Any thing that can guide me towards the right outcome?
I came up short, really. Lots of stuff out there, but all of it gave me broad options, unsubstantiated opinions, general principles, or formats that didn’t quite fit.
The example roadmaps I found? I wasn’t able to translate them back to our situation.
Just do it
Still we managed. We went through a series of movements. Collect ideas, old and new. Do some prototyping, mock-ups. A Design Sprint workshop. Some t-shirt sizing. Talking with future users, developers, and (maybe-not-so) random smart folks.
And we delivered. Our first roadmap draft was there about a month ago. We did a somewhat informal roadshow along stakeholders with the draft, gathering their feedback. The feedback led to some final adjustments and presto.
Last week, we presented the Roadmap to all our colleagues in the organisation. Positive responses all around “We can see where this is going” and “It all makes sense now”.
So?
So now that the Roadmap has been delivered, I thought back to the early moments where it was entirely unclear to me what was expected when I was told “start with a roadmap”. And now I finally can see:
- why there is no one that can tell you the “right” way to build a roadmap, and
- what a roadmap really is.
Here are my answers.
What is a product roadmap, really?
A roadmap is a confidence-builder. Your own confidence, and more importantly, the confidence of those around you.
The word “roadmap” suggests that you can use it to find your way from where you are to your destination. Though not true, that surely is a comforting thought.
And comfort is what we need when we are about to dedicate a couple years of effort to designing and building something that we have not made before, by collaborating with a heterogenous, and continuously changing set of people that each have a mind of their own.
The roadmap creates the illusion of order. What to do first, second, and third. Once you have put one foot in front of the other, once you have set that group of people into motion in a certain direction — in any direction, really — the anxiety dissipates and everyone starts to focus on their own job and discover their own way of contributing to the whole.
Why can no one tell me the “right” way to build a roadmap?
Because your job is not to build a roadmap, really. Your job is to build and inspire confidence. How that is done best is almost entirely situational.
Build your own confidence first. If you need to interview users to build confidence, you interview them. If you need a shiny visual to inspire confidence, make it shine. If you need to sketch, design, and prototype to gain confidence, that is what you do and keep doing until you’re done.
When you are confident about what you need to build, then just choose any process, any format, any timeframe, and use them to channel your confidence. Stare down your detractors, set the team in motion, and off you are.
Good luck!
Joost Visser is Chief Product Officer at the Software Improvement Group.
BTW: Here is some recommended roadmap reading:
