Much like what I expect it’s like to train your dragon (if you’re crazy enough to own one), roadmaps can be difficult to train, they can be big, they can be hard to handle, and they can also be very… mythical too. Also, like works of fiction they can just be there for the pleasure of others.
It shouldn’t be like that, they should be brilliant works of fact, they should guide you as a team and they should allow you to follow a particular path or maybe paths.
My first rule of roadmaps is, in order to make your roadmaps be less fiction and more fact, and less friction too, you have to make sure they align to strategic goals and metrics and, make sure everyone knows what those goals are. Make sure everyone is onboard with the strategic direction, this job should not be solely up to you, your CEO or other management should be making sure everyone is aligned too. The more aligned the management, is the better a roadmap will be viewed.
My second rule of a good roadmap is to make sure it’s truthful. Don’t make it a PR document, make sure you and the rest of the product team can deliver it. Too many times I’ve seen Product managers “squeeze” too much in to a quarter (or month), not leaving space for delays, problems, staff vacation, holidays and things that just come up. In a later blog I’ll give some examples on how you can structure a good roadmap to mitigate for eventualities.
My third rule is to get it signed off by senior management, get them to approve it. We’ve all had the CEO or CMO or any C suite manager want something new, right away. With management sign off comes acknowledgement that they are affecting the target goals if they add things to the roadmap that do not align to the company strategy.
Fourth rule, keep it updated. If something changes, document it and amend as required. A roadmap is a living plan, not a plan set in stone. It might be nice if it was, but we all know, things happen and change.
On to my fifth and penultimate rule, get your engineering team to understand what you are trying to get done, get their early feedback on it, give them the information they need to help you make it happen. “Please help me make this happen” is a lot more powerful than “Well that’s what the roadmap says, so do it!”
On to my final rule, rule six. Have regular roadmap update meetings with the management team, keep a list of new things arising, rearrange the roadmap with them as you get more data and results from experiments. Some managers think a roadmap is set in stone, others think they can just ignore it. You need to find your company’s cadence for these meetings and get the next one in the calendar at the end of the meeting for the current meeting.
I’m sure there are 100 more little rules and some may say I’ve missed one or two. Every company is different, every team is different, but please don’t do one roadmap and then come back to it in 6 months time, let it live, ebb and flow like a brilliant, adventurous and fun road trip.
One last thing. I get asked all the time what software do I use for my roadmaps and people are astonished when I say I don’t use a software… I use many programs. It depends on the audience. Executives need to see it linked to goals and metrics, developers need to see it with dependencies, and external users need to see something that will excite them. Pick the software and information that’s needed for each audience, but please do keep them all aiming towards the same things, remember they need to be the truth, not a work of fiction.