Here we go!
What All Product Roadmaps Need
A roadmap has to do two main things — communicate the overall product strategy, and communicate what you’re building and why.
So within that concept, regardless of what framework you choose, there are a few key elements any good roadmap needs to have:
- Overarching theme: what organizational objective / goal is this contributing towards?
- Epic: where does this feature fit into the overall product vision?
- User stories: why do your users want this? What problem / job does it solve?
- Feature: technically, what are you building? What is the functionality involved?
- Effort and importance: how much work is it to build, and how important is it?
Now that we’re clear on what each roadmap needs to include, we can move into specific frameworks.
Timeline Roadmaps
These are the most controversial roadmaps on this list, because strict agile methodology would determine that there should be no timelines with roadmaps.
But the reality is, most roadmaps involve some dimension of time because communicating to the wider organization without time is extremely difficult.
Pros
It’s easier to explain what’s happening when to other stakeholders
The time component crystallizes opportunity cost, making it easier to conceptualize the downside of building / not building something right now.
Cons
It artificially binds your work into timelines, which make it inherently less flexible and agile
You may end up unable to respond as quickly to changing market / customer requirements, so if you’re in a fast-moving industry (e.g. a new category) then time-bound roadmaps may not be right for you.
When to use
If you need your product roadmap as a key tool to defend your engineering resources, then timeline-based is a good idea. It will help the entire organization better-understand project requirements and the consequences of scope-creep.
If your product roadmap is more for your engineering team, however, you may be better off with a different format, since in that case the ability to build with maximum agility is likely more important.
Priorities Roadmaps
Priority-based roadmaps look at your themes and epics as the source of truth and then prioritize features out from there.
This style of roadmap will usually involve a Kanban-style board, with columns like idea | now | soon | later or some close variation.
Pros
Keeps your team dynamic and agile. You can adjust and reposition easily on the fly as you learn more about your customers.
Keeps your engineering team focused on things that are going to have the biggest impact, and push your product forward quickly.
Cons
Dependencies can get messy. If there’s tons of dependencies in the product, a small thing that's prioritized can end up eating up significant engineering hours.
Can result in feature-first development, where features are built without a cohesive sense of themes and epics.
When to use
When your product is younger and there are almost infinite directions to take it, a priority-based approach is best — otherwise, you’ll end up wasting time planning, or worse actually build something ‘because it’s on the roadmap’ that isn’t valuable.
If your product and organization is more mature, then other frameworks that suit the business beyond engineering may be more appropriate.
Release-Based Roadmaps
Release-based roadmaps are when you anchor your roadmap around key product releases. For instance, Salesforce has few major releases every year, so their roadmap likely ties into that process.
The key characteristic is that your roadmap is organized into releases. It will look something like this:
Pros
Makes it really clear to your organization (especially the go to market teams) when you’re releasing new features.
Makes scoping work easier since you have a firm end date.
Cons
It’s a less dynamic approach, since you have a clear release date you can’t push.
Can squeeze your engineering team as things get squeezed into resources.
Inevitably leads to more waterfall-based development.
When to use
Just like a priority-based roadmap is best when your product is immature, a release-based approach works best for a more mature product, where themes and epics naturally evolve a little more slowly.
Over To You
Planning out your product is always going to be hard. Any decision you make is inherently going to be a decision of trade-offs — you’re choosing to build this, not that.
And that’s definitely going to lead to natural tension within your organization.
A product roadmap can help communicate to everyone not only what you’re building, but when and why.
For more mature products, time- and release-based roadmaps generally streamline communication across complex and multi-siloed organizations.
For less mature products, basing your roadmap on shifting priorities of the customer is perhaps a better approach since it keeps your very valuable engineering resources fluid.
Choosing the right framework at that point is really about choosing what suits your specific needs.
What are you thoughts on Product Roadmapping Frameworks? Let us know on Linkedin!
