This article was originally published in the Potato Blog.
Over the course of your career you will have probably heard questions like "When will feature X be available?" or "What's our plan to solve Y?". You may have also spent hours in status meetings or steering committees reviewing feature specs. And justifying what your team is working on now, and what they were going to focus on in the upcoming months.
You've probably tried some ways of having people self-serve this information to avoid frequent follow ups on status and timelines. Using Gantt charts or spreadsheets to represent progress, releases and map dependencies. But you soon realised that they become out of date and harder to keep up with pretty quickly. So you end up with the extra task of keeping things tidy and synced there, but also answering questions because not everyone can understand it well.
To add to that, someone in your company saw a feature in the horizon during a status meeting; took it for granted (instead of an estimate) and made commitments that depended on your timeline. So your team starts to feel the pressure of meeting deadlines to avoid disappointing someone else, and in the future inflates estimates to account for unknowns or dependencies. By trying to add more certainty you've ended up doing just the opposite.
You lose the ability to react to change and have options. What if the market suddenly changes and you want to re-prioritise? What if a feature proves too expensive to build and you realise there's not as much demand as you thought it will be? You already committed to delivering months upfront and created an expectation that's hard to change.
But there's another way of doing things. Cue the theme-based roadmap…
- It's very different to a timeline/gantt-chart type roadmap
- It helps communicate the big picture and your strategy in a simple way
- Communicates the problems or opportunities your team will focus on
- It's linked to your business goals and to outcomes before outputs
Photo via ProPad
The priorities on your theme-based roadmap are expressed in a three column layout consisting of "Now", "Next or Near Term" and "Future". If it helps break the ice with your stakeholders, you can think of this as broad time-horizons as well, that can translate into "This quarter", "Next couple of quarters" and "Later this/next year".
As problems and opportunities get prioritised to align with business goals and closer to what your team should focus on right now, the level of detail and certainty increases. This gives you the chance to communicate your product strategy and intentions but fill in the details as you go.
But the most important thing is it allows you to be flexible and adapt to the market and your users. As you're not making commitments or creating deadlines to meet several iterations in advance. You can afford to change direction, be agile and react as needed.
Ultimately, the work your team focuses on should be able to drive an impact on your business goals and align with your business strategy rather than committing to deliver something solely based on a past promise.
If you're interested in learning more about roadmaps, I would really recommend watching the "Guide to Roadmapping" talk by the great Janna Bastow.