Agile Product Roadmap: Pros, Cons, and Best Practices

I’ve been working as a Project Manager at MindK for the last 7 years. It was about that same time that our company embraced Agile as a software development methodology. This made me rethink my opinion on product roadmaps.

So I’ve decided to provide an overview of their pros, cons, and a recipe for making a truly Agile roadmap.

Table of contents:

• What is a product roadmap?
• Why a product roadmap is a terrible idea
• Why a product roadmap is an awesome idea
• How to create a truly Agile product roadmap?
• #1 Start with your vision
• #2 Break themes into epics and user stories
• #3 Prioritize stories on the backlog
• #4 Build a timeline for your roadmap
• #5 Share the roadmap with your team and stakeholders
• #6 Adjust your roadmap based on feedback and changes in requirements

What is a product roadmap?

A product roadmap is a document that visualizes what you want to achieve with your product and how you’re going to do it. Roadmaps are typically rendered as a Gantt chart.

A simple roadmap, created for one of our projects at a pre-sale phase

There are many variations of product roadmaps, 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 a 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. Development teams spent 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 outlined months, if not years of development. They underwent minimum changes during this period.

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 risk failure.

With Waterfall planning, a change in vision creates a cascade 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 to follow market trends and customer feedback. The resulting product can be radically different from the one you envisioned at the beginning of the project.

Another issue 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.

As a real-life example, one of the projects I manage at MindK is a digital self-assessment system for finding an optimal career path. It is very prone to changes, making it hard to create roadmaps. Most of these changes are features requested by third parties after making a deal with our clients. We can’t predict whether we’ll sign a contract with a new partner, much less the changes they’ll request. That’s why we follow a more flexible approach of setting business goals and KPIs, instead of focusing on long-term plans and features.

GIST planning (Goals, Ideas, Step projects, and Tasks) is one of the possible alternatives to roadmapping. It is a 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.

Xelfer, a career path assessment app, created by MindK

Why a product roadmap is an awesome idea

Meet Bob. He manages an innovative product at a large bank. Just like Alice, he follows an Agile approach to development. But here’s the 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 a 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, not so 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 shows your team the big picture, while your backlog will detail implementation. This covers both strategy and tactics.

Roadmaps can also:

• Help you 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. 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 the language of 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.

Here’s another on-point example I’d like to share. Another project that I currently manage is a smaller app for crafting beautiful email signatures. I love using roadmaps to let the team know the general direction of the product. This helps them prepare a solid architecture and create an appealing design. We can prepare the UI wireframes in advance and have them tested by real users. Their feedback helps to improve the app’s visuals.

What’s more, startup founders often come to us with a “Big Idea”. Yet, they rarely have a solid market research business plan. In such cases, we like to have a short product workshop. There, we ask a lot of questions about their vision, user needs, and product goals. We then brainstorm the functionality that could satisfy those requirements.

The result is a high-level product roadmap. Pure Agile works best with goal-oriented (AKA theme-based) roadmaps. They outline business problems, not features, and provides developers the freedom to explore different ways to achieve the stated outcome. Agile roadmaps focus on short timeframes (up to 6 months) and can be flexible enough to accommodate necessary changes.

Part of a roadmap for my email signature project, made with Miro

How to create an Agile roadmap?

A theme-based roadmap is the way to go unless you manage a mature product in a stable market. But how do you create such a roadmap?

#1 Start with your vision

Where do 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 your unique vision.

From there you can work on specific product goals. For example, you might want to “provide a better mobile experience” or “improve the design” to attract new users. These high-level strategic goals are often called themes. They are relatively short-term (up to a year), specific, and have clear success metrics (for instance, acquire a thousand new customers by the next quarter).

A theme-based roadmap template. Source: ProductPlan

#2 Break themes into epics and user stories

The 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 (large pieces of work that share a common goal) and further into 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 flows, or technical likeness). When classifying stories, imagine how people will use your app and consider what needs may arise once the story is implemented. Writing each story on a large post-it note makes it easier to move them between different categories.

#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). It 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 duration of work needed to complete a story or 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 as soon as possible? For example, 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? For example, 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 calculate the Cost of Delay.

Both are usually scored using the so-called “planning poker”. You need a set of cards with numbers from the Fibonacci sequence (which are 1, 2, 3, 5, 8, 13, and so on) that represent the amount of work needed to implement a feature or its value.

Source: scrumdesk.com

Ask the participants to rate all stories, category by category (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 better to avoid specific dates. 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.

Remember to keep your roadmap as realistic as possible. Don’t commit to deadlines you can’t 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 Miro, 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.

#5 Share the roadmap with your team and stakeholders

A roadmap is useless if people behind your product can’t access it daily. To make your roadmap more accessible, you can tailor it to different audiences:

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’ll receive a ton of feedback, you might discover new opportunities, executives will come up 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 objectives will help determine when to pivot or 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 (for example, each week, sprint, month, or quarter).

You can combine roadmap revisions with existing meetings. For example, we at MindK like to update the product roadmap after each Sprint Review (a live demo for stakeholders). However, if updating your roadmap takes time away from building your product, it might be better to choose a simpler approach.

Wrapping Up

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 depending on your needs. Anything can work as long as it helps you achieve the product goals and fulfill stakeholders’ expectations.

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 world-class project managers to lead the way, MindK is here to help you. We have a proven track record and would gladly help you. Just fill the contact form and we’ll schedule a free consultation with our Agile experts.