If you’ve following along this far in the blog, you’ll know that the mysterious ‘product strategy’ that’s so frequently mentioned, yet so infrequently actually defined in any concrete terms, is actually just three separate but deeply interconnected elements; the Vision, Strategic Framework and Roadmap.
The roadmap then, is the most granular part of the Product Management Russian nesting doll we’ve got going on here. It’s the lowest layer; the actual work you’re going to carry out to achieve the strategy and push the product towards the big, audacious vision you have for it.
How to create one
If you’re currently looking at a roadmap from a purely intellectual perspective, having never made one before and wondering how, it can seem like a very daunting and overwhelming proposition. It’s arguably the most important document in the Product Management arsenal because if the roadmap is wrong, all your efforts will be in the wrong direction, but at the same time it’s a blank canvas. How do you know what to put on it?
Well in reality, you’re very unlikely to be creating one in isolation. You’ll be within an organisation, which means you’ll have stakeholders, which means you’ll have an untold number of opinions of what should be on your roadmap, from everyone, all the time.
Frankly, the much more realistic situation is that you’ll have far, far more features than you could (or should) put on the roadmap, and you’ll need to figure out which of those deserve a coveted spot on this most prestigious of documents.
Here’s a few tips to help you decide on that, as well as a few more general tips to consider when building out your roadmap:
- Make sure every feature on the roadmap is aligned with the strategy - if it doesn’t categorically move the needle on at least one objective outlined in the strategic framework, then it doesn’t belong on the roadmap. You need to be laser focussed and employ strict discipline. This will require strong stakeholder management; a lot of stakeholders will ask you for whatever they feel is important for the product, but often they have little to no oversight of the product strategy, so it’s up to you to communicate and manage this. To make this super clear, I’ll explicitly label each feature on the roadmap with the goal or KPI from the strategy that it relates too using colour coded badges.
- Don’t make the roadmap span too long of a time period - about 12 months is usually the standard, any more than that and you’ll extend past the planning horizon. Market conditions, the competitor landscape, organisational goals and company structure are all changes that can massively impact your roadmap, so only plan within a realistic timeframe.
- Be mindful of what you’re communicating with your roadmap - while we’re on the subject of timeframes, be careful about committing yourself to hard dates in the roadmap. This is subject to some debate within the product community, but my personal view is that putting very specific dates against the items on your roadmap is setting you and the organisation up for failure. The problem is how people use the roadmap; the Sales team for instance are going to take it and use it to sell to new customers based on the features on there that the customer would want, and if you put a date against said feature, the Sales team will naturally communicate that date to the customer. If there’s a slippage in timings for whatever reason, you then end up with a very dissatisfied customer who may well have signed up for your product based solely on a certain feature they now won’t have for a while. To avoid this, stick to broad timeframes like “This quarter”, “Next 6 months” and “Next year”, or even just “Now”, “Next”, “Later”.
Prioritising the roadmap
Prioritisation is an essential skill in Product Management and a big, big topic, so I’ve written a separate blog post about it here.
Once the roadmap is created
TAs with any other part of the product strategy, the roadmap is not a ‘set and forget’ document. Once you’ve created it, carry out the following:
- Zoom out - look at your roadmap from a high level and categorise the features on there. It’s important to have plenty of exciting new features on there that will strengthen your product proposition and help win new customers, but don’t neglect enhancements to core features that further satisfy your existing paying customers, as well as the mundane but essential task of tackling tech debt. Make sure your roadmap is nicely weighted across all those areas (unless of course weighting it heavily in one area is an explicit part of your strategy right now, but if so, make sure that’s clearly communicated).
- Compare the sprint backlog to your roadmap - this is a great way to make sure you’re actually acting on your strategy, not just creating one to please stakeholders then never executing on it.
- Review it regularly - revisit the roadmap every 3 - 6 months (or even sooner if you work in a particularly fast-moving environment) to ensure that it’s still relevant in the context of the internal and external landscape.
- Use the roadmap as a stakeholder management tool - as I mentioned earlier, you will absolutely be asked to implement far more features than you feasibly could, or should, by various stakeholders. The challenge is that these stakeholders often outrank you, so it can very easily become a situation where you either blindly do what you’re told, or say no, explaining your opinions as to why and create a ‘me versus you’ battle in the process. Both of these situations are ultimately terrible for the product and your career more broadly, so to avoid this you need something concrete to point to when saying no. The roadmap can help say “no” for you. When a stakeholder asks for something, you can show them the roadmap and explain what would need to move in order to make space for this new request. All of a sudden it no longer seems like you just stubbornly refusing a request, instead there’s now visible and tangible consequences to shoehorning in new requests that stakeholders can more easily understand.