There are plenty of product road mapping frameworks out there, and selecting which one is best for you’ll be overwhelming. Today, we’re getting to check out a couple of the foremost common ones you’ll run into, their pros and cons, and when to use them.
Here we go!
What All Product Roadmaps Need
A roadmap has got to do two main things — communicate the general product strategy, and communicate what you’re building and why.
So within that idea , no matter what framework you select , there are a couple of key elements any good roadmap must have:
- Overarching theme: what organizational objective / goal is this contributing towards?
- Epic: where does this feature fit into the general product vision?
- User stories: why do your users want this? What problem / job does it solve?
- Feature: technically, what are you building? What’s the functionality involved?
- Effort and importance: what proportion of work is it to create, and how important is it?
Now that we’re clear on what each roadmap must include, we will enter specific frameworks.
Timeline Roadmaps
These are the foremost controversial roadmaps on this list, because strict agile methodology would determine that there should be no timelines with roadmaps.
But the truth is, most roadmaps involve some dimension of your time because communicating to the broader organization without time is extremely difficult.
Pros
- It’s easier to elucidate what’s happening when to other stakeholders
- The time component crystallizes cost , making it easier to conceptualize the downside of building / not building something immediately .
Cons
- It artificially binds your work into timelines, which make it inherently less flexible and agile
- You may find yourself unable to reply as quickly to changing market / customer requirements, so if you’re in a fast-moving industry (e.g. a replacement category) then time-bound roadmaps might not be right for you.
When to use
- If you would like your product roadmap as a key tool to defend your engineering resources, then timeline-based may be a good idea. it’ll help the whole organization better-understand project requirements and therefore the consequences of scope-creep.
- If your product roadmap is more for your engineering team, however, you’ll be more happy with a special format, since therein case the power to create with maximum agility is probably going to be more important.
Priorities Roadmaps
Priority-based roadmaps check out your themes and epics because the source of truth then prioritize features out from there.
This sort 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’ll adjust and reposition easily on the fly as you learn more about your customers.
- Keeps your engineering team focused on things that are getting to have the most important impact, and push your product forward quickly.
Cons
- Dependencies can get messy. If there’s plenty of dependencies within the product, a little thing that’s prioritized can find yourself 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 require it, a priority-based approach is best — otherwise, you’ll find yourself planning dalliance, 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 could also be more appropriate.
Release-Based Roadmaps
Release-based roadmaps are once you anchor your roadmap around key product releases. As an example, Salesforce has few major releases per annum, so their roadmap likely ties into that process.
The key characteristic is that your roadmap is organized into releases.
Pros
- Makes it really clear to your organization (especially the attend market teams) when you’re releasing new features.
- Makes scoping work easier since you’ve got a firm end date.
Cons
- It’s a less dynamic approach, since you’ve got a transparent release date you can’t push.
- Can squeeze your engineering team as things get squeezed into resources.
- Inevitably results in 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 touch more slowly.
Over To You
Planning out your product is usually getting to be hard. Any decision you create is inherently getting to be a choice of trade-offs — you’re choosing to create this, not that.
And that’s definitely going to cause 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 probably a far better approach since it keeps your very valuable engineering resources fluid.
Choosing the proper framework at that time is basically about choosing what suits your specific needs.
