A Modern Roadmap
During the past decade, roadmaps have become the pet peeve of many of us — mine too.
How can we be agile, experiment, and be outcome-oriented while keeping a detailed plan of all the output that will happen in the next quarters? Promising a product plan that’s filled with certainty is similar to promising an arrival date for crossing the desert.
Of course, we can create that plan — and we can be very detailed, perfectionists as we are. But it’s still a future that we are guessing or fictionalizing. It will have unrealistic deadlines and, if taken all the way, it might be responsible for missing market opportunities and building features that are out-of-date before the code is even written. That’s not agile, and it’s not acceptable for us modern product makers.
Then, why should we invest time in doing roadmaps? Can we admit that they are not helpful? Can we skip them?
Well, I’ve tried it. But, besides me, few were satisfied: I had executives micromanaging because they weren’t provided a comforting sense that everything is planned and on track; I heard the development team complain that they couldn’t see anything further ahead than their sprint and they were missing the big picture; I had the sales team saying yes to random requests, as there wasn’t anything obvious explaining why not; among others.
While a traditional roadmap is not flexible enough for the lean and agile methods, lean and agile methods have not filled the strategy gap created when roadmaps are left behind. Roadmaps are still missed, even when not reliable. There must be something valuable in them.
Modernizing Roadmaps
A product roadmap is a powerful communication tool. It’s the guiding light of the whole organization, and it has the power of steering it towards a direction. Its value is undeniable.
Traditionally it’s done through a project plan — a Gantt chart with a list of features and projects that tech teams have promised to deliver someday. It’s our guess on what and when we should deliver, without any context on why. No wonder we tend to consider them futile. But it doesn’t have to be this way.
To modernize roadmaps, we can make them less like a project plan and more like a strategy prototype. Instead of being just guides to navigate outputs, they can be guides to navigate outcomes.
If none of this outcomes vs. outputs talk rings a bell to you, I’d recommend reading the article below before moving any further. Most of the terms I’ll use from now forward come from there.
By defocusing on outputs and delivery dates, we are more comfortable thinking about the future and providing a view focused on value instead. It will keep everyone excited about the direction and aligned around a single set of priorities. As we are already providing a transparent view into what we know about the future, we won’t be as pressured to make promises we aren’t confident in. We won’t need a wasteful process of upfront design and estimation.
Once we get confident about the execution of a solution, we can then add complementary details about it to the roadmap. Those details will make it easier to communicate with our stakeholder audiences, helping with buy-in and alignment.
Remember, though, when adding detail to a roadmap, we want to find balance. Too much information can make the roadmap challenging to read.
Components of a Modern Roadmap
Modern roadmaps can have many shapes and forms — we’re not constrained to the Gantt chart any longer. This example is approved by Product Roadmaps Relaunched, and I like it:
The foundation of this roadmap aligns everyone around a common cause:
- Vision — It sets the ultimate direction and provides meaning for everything that follows. The rest of the roadmap describes how we intend to achieve this vision.
- Business Intents — They communicate the current areas of focus to make a big leap forward.
- Product Initiatives —They answer how we can reach the intents by optimizing our products. The best answers are linked to real problems that users want to have solved.
- Broad Timeframe — It provides guidance on when the product initiatives will happen. It reminds us of traditional roadmaps while preserving flexibility.
Secondarily, we can add sub-items to the Product Initiatives:
- Options — They’re the possible solutions to explore. Some of them will turn into shipped features. It’s probably a good idea to only include them when there’s a degree of confidence in them.
Finally, we can tag the items (particularly Product Initiatives and Options) with additional information such as:
- Stage of development
- Confidence
- Target customers
- Product areas
- Schedule and resources
- Dependencies and risks
That’s it, we’ve got our roadmap, with an all-modern look. Can we now frame it and hang it on an office wall? You guessed it — it’s not that easy. Modern or not, roadmaps shouldn’t be set in stone. They need to be updated.
Length and Stability of a Modern Roadmap
Remember, a roadmap is not a contract. It needs to adapt when conditions in the environment change and as we learn more. If only the world would hold still long enough… but it never works that way. However, at the same time, we need to allow execution to proceed steadily.
The answer to providing this stability in an unstable world is to revise the roadmap in regular cycles — similarly to the concept of sprints in Scrum, but on a larger scale. During the ongoing cycle, what’s being worked on will be stable. Everything else can move to reflect any updates and to be in the best shape we know for the next cycle.
The question is: how stable is our environment? It will determine how far out our roadmap should go and how frequently we should update it. The faster the pace of change, the faster our cycle and the more compressed our roadmap should be.
If our product is in the introduction stage of life, it should probably have short cycles. If our product is in the growth stage of life, we might be able to have them a little longer. If our product is in the maturity or decline stage of life, then the cycles might stretch even longer.
By focusing on outcomes, by providing the right amount of details at the right time, by being strict in prioritization but being flexible on timeframes, and by keeping it fresh but steady, we’ll be able to craft an efficient (and modern) roadmap.
If you liked this article, you’ll probably like these ones too:
