A product roadmap is a document that describes what you want to achieve with your product and how you’re going to do it. Roadmaps are typically visualized as a Gantt chart.
There are many variations of product roadmaps, ranging from detailed plans that focus on features and deadlines to high-level statements of intent that map business goals on loose timeframes.
There’s a bit of controversy surrounding roadmapping in Agile development. Some experts claim it’s an outdated practice while others support it wholeheartedly. Let’s take a closer look at both points of view.
Why product roadmap is a terrible idea?
Meet Alice, a product manager at a fast-growing startup.
Like many of her peers, she thinks that product roadmaps are a huge waste of time.
When Alice started her career 10 years ago, most projects at her company were managed in a Waterfall fashion.
The development team used to spend months gathering a complete list of requirements, assessing risks, detailing specifications, and planning every aspect of development for years to come.
This approach required a well-defined budget and rock-solid deadlines. On paper, Alice’s roadmaps looked like a solid plan outlining months if not years of development with no flexibility involved.
Yet, even the best plans suffer from budget overruns, missed deadlines, and lost market opportunities.
New people come on board with fresh ideas. Priorities and markets change so you have to react quickly or get left in the dust.
With Waterfall planning, a change in vision creates a cascading wave of changes at the lower levels.
In the Agile world, roadmaps become outdated as soon as you put them on paper. Fast-moving companies often have to pivot following market trends and feedback. The resulting product can be radically different from the one you envisioned at the beginning of the project.
This means you either have to spend a lot of time updating your roadmap or risk building features that nobody needs.
42% of startups fail because they create products without a market need.
Another issue Alice finds with roadmapping is that it can set up false expectations. If you share your roadmap with users, they will expect you to deliver the product as it was advertised.
Delays or cut features could erode trust in your product.
In the end, Alice had to let go of her roadmapping habits. Instead of focusing on long-term goals and features, you can use a more flexible approach like GIST planning (Goals, Ideas, Step projects, and Tasks).
This lightweight planning framework developed by Itamar Gilad while working as a lead product manager at Google. It has no separation between idea generation, planning, and implementation giving you both Agile development and planning.
Yet, many successful products were built by managers who love roadmaps. Let’s hear what they have to say.
Why product roadmap is an awesome idea?
Meet Bob. Just like Alice, he is a fictional character who manages an innovative product at a large bank. Just like Alice, he follows an Agile approach to development.
But here’s a thing.
As organizations become bigger, it becomes increasingly hard to stay purely Agile.
Established companies are different from startups. They have stakeholders and different products that need to fit into a common strategy, supply lines, complex dependencies, and rampant bureaucracy.
Developers have to cooperate with other teams that traditionally operate in non-agile fashion like accounting, HR, or legal departments.
This means you can’t avoid at least some form of long-term planning.
But none of the Agile tools provide the team with the bigger picture.
Agile teams often write features in the form of user stories (a short sentence describing the desired functionality from the user PoV).
As a < user >, I want < a feature > so that < my reasoning >.
All user stories are put in a prioritized list called product backlog. Backlogs are great for sprint planning but suck for long-term strategy. They can easily become bloated with hundreds of user stories and complex dependencies that make prioritization a pain in the neck.
You can, of course, rely on technical features instead of user stories.
But there’s another solution.
A roadmap can show your team the big picture while your backlog will detail implementation. This covers both strategy and tactics.
Roadmaps can also:
- Coordinate work across multiple teams and connect their day-to-day work to the company’s goals.
- Align everyone around your vision. This is especially important for external teams that might lack insight into your company’s goals and values.
- Motivate the team with a clear direction to follow and freedom to reach the desired outcomes.
- Help you adapt to changes in markets and user needs by comparing hard data with target metrics on your roadmap.
- Secure buy-in. As stakeholders rarely think in terms of sprints and features, you’ll need regular status updates to secure their buy-in and maintain interest in your product. A roadmap can translate technical requirements and tasks in Jira into a language that’s familiar to senior management.
- Maintain transparency. Users often don’t believe the development team listens to their feedback or can deliver the promised capabilities (especially in the B2B sector). Sharing an external roadmap can serve as an official commitment to solving user problems increasing confidence in your product.
But, instead of sharing Waterfall-style roadmaps with features and deadlines you’ll never meet, Bob uses Agile roadmaps that focus on short timeframes (up to 6 months) and can be flexible enough to accommodate necessary changes.
Pure Agile works best with goal-oriented (AKA theme-based) roadmaps. They outline business problems, not features, and give developers freedom to explore different ways to achieve the stated outcome.
Such roadmaps can either include no dates at all or use more ambiguous designations (e.g. Completed/In Progress/Future).
When choosing between feature-oriented and theme-based roadmaps, you should account for two critical factors: market stability and product maturity.
So, unless you manage a mature product in a stable market, a theme-based roadmap is the way to go.
How to create an Agile roadmap?
#1 Start with your vision
Where you want to be in 3-10 years as a business?
Maybe you want to become a top insurance provider in the region or build a global e-commerce platform?
Everything you do with your product should contribute towards realizing this high-level vision.
From there you can work on specific goals you want to achieve with your product. These goals are relatively short-term (up to a year), specific, and have clear success metrics (e.g. acquire a thousand new customers by the next quarter).
They are typically aimed to solve high-level user needs (called themes in product roadmaps).
For example, you might want to “provide a better mobile experience” or “improve design” to attract new users.
Note: If you’re building several products, you’ll have to make sure they don’t cannibalize each other’s sales. In this case, it’s recommended to start with a portfolio-level roadmap. It can visualize complex dependencies between your products, reveal new opportunities, and make sure your efforts across different products and departments match your long-term goals.
#2 Break themes into epics and user stories
Themes you’ve identified in the first step are still too large to be useful to the product team.
That’s why it makes sense to break them into epics (i.e. large pieces of work that share a common goal) and into smaller user stories that can be completed within one sprint (1-4 weeks).
It’s easier to deal with dependencies between user stories when they’re grouped into common categories (by business needs, user flow, or technical likeness). Writing each story on a large post-it note will make it easier to move them between different categories.
When classifying stories, imagine how people will use your app and consider what needs may arise once the story is implemented. This will help you find dependencies between stories that will guide the development flow.
#3 Prioritize stories on the backlog
There are many ways to estimate and prioritize user stories. One of the most common is Weighted Shortest Job First (WSJF) that gives the top priority to the easiest tasks with highest value. The formula is quite easy:
Relative priority = Cost of Delay divided by Job Size
Job Size represents the amount of work needed to complete a story (its technical difficulty).
Cost of Delay takes into account 3 factors:
- User-Business Value: how valuable is the story to your business and users
- Time Criticality: how important is it to complete the story ASAP? (e.g. you know your competitor will roll out similar capabilities in the next quarter).
- Risk Reduction/Opportunity Enablement: how much the story can reduce risks or open up new possibilities? (e.g. the feature is required for GDPR compliance – high-risk features are tackled first).
The development team will estimate the Job Size for each story while internal stakeholders will calculate the Cost of Delay.
Both are usually scored using the so-called “planning poker”. For this “game”, you need a set of cards with numbers from the Fibonacci sequence (i.e. 1, 2, 3, 5, 8, 13, and so on) that represent the amount of work needed to implement a feature or its value.
Now gather your team and stakeholders with a whiteboard and a bunch of sticky notes.
Ask the participants rate all stories, category by category (i.e. Job size, then Business Value, and so on).
Each person shows the card that reflects the feature’s value/difficulty (as it relates to other stories). If everybody shows the same card, the number becomes your estimate. If opinions differ, everybody gets the chance to discuss the story and re-rate it.
All estimates are written on sticky notes and placed on the whiteboard.
Once you’ve covered all stories and categories, you can calculate the relative priority for each feature and rearrange your backlog.
#4 Build a timeline for your roadmap
After you’ve calculated the relative priority for all features, you can start planning your first release. This is the perfect opportunity to visualize your intentions on a roadmap.
By using a rough estimate, you can put your themes and epics on a loose timeline that will represent the planned development of your product. If you work in a purely Agile environment, it’s advised to avoid specific dates altogether and group your activities by their theme.
Alternatively, you can use sprints, quarters, or other loose timeboxes like Completed/In Progress/Future.
A roadmap with no deadlines. Source: roadmunk.com
Each story on the roadmap should be linked to its goals and success metrics.
Be as realistic as possible. Don’t commit to deadlines you can’t possibly meet and keep implementation details away from your roadmap.
You can build simple roadmaps in Excel and similar tools or go for specialized software like Aha, Roadmunk, or ProductPlan. Such tools often come with a variety of customizable templates that can help you craft visually appealing roadmaps for every occasion imaginable.
A sprint-based roadmap. Source: roadmunk.com
#5 Share the roadmap with your team and stakeholders
A roadmap is useless if people behind your product can’t access it daily. You should, however, tailor your roadmaps to each audience:
Make the roadmap available to all people who work on the project and ensure they check it regularly. Work closely with stakeholders to ensure everybody’s on the same page.
#6 Adjust your roadmap based on feedback and changes in requirements
Change is inevitable. Your competitors will come up with new features, you will get a ton of feedback, you might discover new opportunities, executives will come with new ideas throwing all that careful planning out the window.
That’s why it’s important to have well-defined metrics for each goal on the roadmap. Measuring data and comparing it to your targets will help you determine when to pivot and when to stick to your guns.
An agile roadmap sets an overall direction for the product and should be updated regularly as you progress towards your goals. The frequency of updates will depend on your approach to development and the product’s nature (e.g. each week, sprint, month, or quarter).
You can combine roadmap revisions with existing meetings (e.g. update the product roadmap after each demo, when all the stakeholders are present).
However, if updating your roadmap takes time away from building your product, it might be better to choose a simpler approach.
Now that you know arguments both for and against roadmaps, you can choose the approach that makes the most sense for your product. A flexible theme-based roadmap will suit most Agile projects but you can try GIST planning or something else entirely.
Remember, our goal here is to realize the product vision and fulfill stakeholders’ expectations on the scope of work, deadlines, and quality.
But putting your intentions on a roadmap is just half the work.
If you need a team of qualified engineers to realize your vision or an experienced project manager to lead the way, you can always drop us a line and schedule a free consultation.