How to write an effective and useable roadmap
Roadmaps are a great tool for showing what priorities you and your team are looking to land in the next 3, 6 and 12 months. Done well they can help rally a team around ambitious goals and keep everything aligned and focused on tangible outcomes.
So what rules should you follow when creating your roadmap?
- Link effort to objectives and high level goals. Whether you’re using OKRs or some other form of objective design it’s important to show how your roadmap deliverables line up to the goals you’re trying to achieve.
2. Include contextual information. Putting ‘CRM’ into a coloured box isn’t good enough. Include a single sentence that indicates the scope of the work so people understand what is being delivered. Reading this and the OKR is links to will provide so much value to the reader.
3. Be in the weeds for the first 3 months. Your roadmap should be very detailed for the first 3 months with delivery in 6 and 12 months being less descriptive. The reality is that your plans at month 9 or 11 may look very different from today so put your energy into focusing on nearer term effort. Don’t forget any activities that are still in flight or coming to a close that will still be taking up resources at the start of the roadmap.
4. Forecast effort and impact. Grade your deliverables by the impact they will have on the user and business. You can simply use high, medium and low for this but remember to include descriptors and identifiers so that people can put a high impact deliverable into context. For effort think about resources, time and money. You can use a simple $ sign for something that is low cost or $$$ for something that could be seen as breaking the bank. For human resources try and separate out engineering and non-engineering headcount and hours.
The reality is that even a heavily tech dependent deliverable will have a non-engineering impact. There’s little in life that doesn’t include people, product and process. For resource impact you can again use t-shirt sizing (S,M,L) but remember again to include descriptions of what a small actually looks like in reality — is it two engineers working 40% of their time on the project.
5. Organise your roadmap. Not all your work is transformational. Some will be business as usual effort. It’s important to carve up your roadmap so people can contextualise what you’re trying to deliver. At a recent client we built our roadmap into swim-lanes where 60% of effort was on delivering Big Bets — those projects with high risk, high reward profiles. The rest of the roadmap was 25% allocated to solve technical and operational debt with 15% reserved for moonshots or those crazy ideas that may or may not land.
6. Show horizons of delivery. If something is a pilot then show how it will evolve over the lifetime of your roadmap. If you have a product being piloted in France and then going global in the second half of the year then use your roadmap to tell that story. It helps frame your team’s ambition and helps others understand where you’re going.
7. Be clear when you expect benefit realisation. Avoid plonking deliverables onto a roadmap without showing when the benefits will be felt by users or the business. The reality is that an internal tool might not have its intended impact until several months after launch. If you’re not clear in showing when you expect that benefit to be felt then you risk people having doubt in your ability to deliver change.
8. Show interdependencies. All effort is linked. A CRM system might need an updated CMS system. A change in policy might mean a change in how a process is followed. Try and show links across people, product and process so that people can feel the benefits of having one single source of truth. You should only have one roadmap not 3.
9. Show the priorities. Unfortunately you can’t do everything. It’s okay to start out with a massive roadmap as long as you appreciate that it’ll need to be trimmed based on the resources you have. If undertaking transformation then make the case for more headcount while understanding you might only get 20–30% of your ask. Use your roadmap to discuss priorities as a team. Stack rank everything. Then drop effort that will only hold you back.
10. Share the love. Your work will have an impact elsewhere. If you’re launching a new product then the customer operations team need to be aware of it. While it might be a priority on your roadmap it might be totally absent on theirs. Make sure your central planning team is sharing cross-functional plans to ensure nothing is signed up for that in the long run can’t be delivered due to mis-alignment.
Okay so now you have your roadmap but the reality is that a roadmap is never static. It is under constant pressure as new work comes into play and priorities are re-adjusted. Don’t be afraid to review your roadmap and cull work that isn’t delivering value as expected.
Remember to use your roadmap in every sprint, tracker or performance meeting. It’s the one source of truth and will help you understand how well or how badly you’re performing against delivering your OKRs. If you find work being continually pushed right then question it with your team. Did you underestimate effort? If you’ve landed a change but it isn’t delivering a benefit then question it — did you overestimate the impact it was likely to have?
Don’t forget to communicate your roadmap at regular intervals. Changes and decisions linked to it need to be put in context so everyone knows why something was de-prioritised or changed.
Roadmaps are great practical tools for organising, showcasing and debating workload. Done well then can be the only document you need to get things done.
At Strategy Activist we help clients create effective roadmaps that deliver change. We specialise in supporting clients that are willing to adopt a less is more approach to work. We are fans of ruthless prioritisation so that teams can have an outsized impact. To learn more about how we can help visit us at www.strategyactivist.com or call us on +44 7786063053.
