In this hands-on guide, we will show you how to go from a surface-level roadmap that no one looks at (don’t lie, we have all been there) to an Agile product roadmap your team and stakeholders can’t live without. Best of all, this guide will inform your product’s strategy and execution.
These are the techniques we use at HatchWorks to help Agile software development teams deliver products both your users and business will love.
In this in-depth guide, you’ll learn:
- What is an Agile Product roadmap is
- Why you need a roadmap – even as an Agile team
- Where to start (spoiler alert: it is not creating the roadmap)
- How to identify, prioritize, and estimate your roadmap items.
- What to include in your Agile product roadmap
- Frequently Asked Questions
- Best practices and common mistakes to avoid
PS. Don’t miss the free templates throughout the guide!
What is an Agile product roadmap?
An Agile product roadmap is a plan of action for how your solution will evolve over time.
It helps you plan, organize, prioritize, and align your ideas and initiatives across your organization. This way, the most important features and functionality, those that best serve the users of your product, the business, and the technical evolution of your solution, are delivered first.
Your Agile product roadmap acts as a shared source of truth for your team and stakeholders that outlines the vision, direction, priorities, and progress of your product as it evolves.
Think of it like Google Maps guiding you to your destination.
And just like in Google Maps, there is a good chance a better route may be presented after your start your journey, and that is okay!
Your Product Owner is ultimately responsible for the product roadmap, but they by no means define it alone.
Why you need an Agile product roadmap – even as an Agile team
“But we are Agile… We don’t need a roadmap.”
Yes… Yes, you do.
Like death and taxes, change is the one constant in product development. It not only is constant – it is required if you want to build a solution that meets the needs of your users, business, and keeps up with market changes.
At HatchWorks, our approach enables change, hence our motto:
Don’t fear change. Embrace it.”
Change is ever-present… but you still need a plan!
An Agile product roadmap establishes the strategy of your product which provides continuity across the disparate features your teams are working on. It acts as connective tissue for those teams, helping them understand how what they are working on plays into the bigger picture. It also sheds light on dependencies and competing priorities.
While your sprint is sacred, and your sprint backlog should not be changed after the sprint has started, your roadmap is not. It is human nature to want predictability and certainty. But there is a difference between predictability and being a psychic. Not even one of us is the latter, so stop trying to be.
This however doesn’t mean you should go without a plan, especially in a larger organization or for a more mature product where dependencies and complexity are high. At the end of the day, you still have to deliver, and, more importantly, build confidence in your team and stakeholders that you will deliver on-time and on-budget.
The better approach to a rigid roadmap
Align on the level of certainty and depth of your projections and estimates based on how far in the future they are planned. You should be highly certain of your ability to hit items on your roadmap in the current and next few sprints.
- 3 to 6 months out
There should be a shared understanding that the prediction of scope and time has a wider certainty range. - 6 months to 1 year
The accuracy range becomes even wider and the depth of detail is more shallow. - 1 to 2 years
Your Agile product roadmap should still be in the strategic conceptual arena having the widest accuracy range. Again for good reason.
P.S. Don’t feel forced to have a roadmap that predicts further than a year out. It is not always needed.
A roadmap is also a great way to build excitement about where you are going with your team and get buy-in from key stakeholders. It is a rallying cry for the team to achieve something great.
Where to start your Agile product roadmap (spoiler alert: it is not creating the roadmap)
So many people fail at building a roadmap because they start with the roadmap.
Think of a roadmap as the vehicle. You still have to know where you are going and actually drive the car.
You must first start with your product’s strategy, the “why” behind your product.
Without going too deep, the core of strategy is defining 2 specific things:
- What market category you will play in?
- How you will win in that market category?
April Dunford’s positioning framework is a great starting point.
She defines 5 core interrelated areas you must have defined to have a real strategy:
- Competitive Alternatives: If you didn’t exist, what would your customers use?
- Key Unique Attributes: What features or capabilities do you have that alternatives do not?
- Enabling Value: What value do the attributes enable for customers?
- Customers That Care: Who cares a lot about the value?
- Market You Win: What context makes the value obvious to your target segment?
Bonus: What seismic shift has happened in the market impacting your ideal customer? Then build a strategic narrative around that.
Now that you have a defined strategy, time to build your roadmap, right?
Wrong.
First, you must validate your strategy so you can test your hypothesis with actual customers or people representative of your target customer. At the end of the day, that is all an untested strategy is – a hypothesis.
Now that you have a sound strategy, the fun part begins.
How to identify, prioritize, and estimate your roadmap items
First, you must identify the key themes and items you want to include on your roadmap. To do this, start with research. Note, this research should be rooted in the strategy (your hypothesis) you defined above.
Without a defined strategy, it is very easy to go down research rabbit holes, never to be heard from again.
The 4 main types you need to cover are:
- Customer/user research:
Segment your users, perform qualitative customer interviews, and review quantitative data about how users use your product. - Stakeholder research:
A great product that doesn’t provide value to the business is not a great product. It is a hobby. Value typically comes in the form of profitable revenue, but not always. Identify your key stakeholders and meet with them. Understand the broader goals of the business, and identify how your product can help achieve those objectives. Understand how your product fits within the broader portfolio of solutions at your company. - Competitive/Market research:
You have to know what you are up against and what changes are taking place in the market. These changes can either create a huge untapped opportunity or put your product at risk of going the way of the dodo bird. Either way, you need to stay up to speed on both.
Note on competitive research: Do not do competitive research with the purpose of copying the competition. Instead, look for what the competition is not doing and who they are not serving. Act on those areas of opportunity to stand out in the market. - Solution Architecture Research:
No product is perfect, all have some form of technical debt. A certain amount of technical debt is maintainable until it is not, it has a funny way of snowballing on you. Be sure to meet with your technical team to identify what technical and architectural priorities exist. That will help enable future functionality for your product. These may not be sexy, but they are what keep the lights on and enable you to keep building.
One note on research: Research should never stop. This practice of continuous discovery should be part of your process acting as a consistent feedback loop into your product’s evolution.
Now that you have done the hard and arguably most important—work, it is time to define the strategic objective you want to accomplish and the key results that will allow you to measure whether or not you are successful. The OKR (Objectives and Key Results) framework is a great approach for this.
Now, you should be able to identify the key themes and items you want to include on your roadmap that help achieve your OKRs and tie back to your broader product strategy.
This process is best done collaboratively across your product trio, but let’s assume you have defined the key themes and items you want to include.
Now it is time to prioritize and estimate them.
A great starting point we leverage at HatchWorks is the HatchWorks’ Prioritization Matrix.
This framework is great for facilitating an initial discussion comparing your features value and effort establishing some initial critical buckets of what should be prioritized first.
Added bonus: It helps you avoid building a Frankenstein’s monster of a product.
Check out specific details about the framework here.
And here is a Miro template when you are ready to give it a whirl.
A more detailed go-to framework we use at HatchWorks to estimate and prioritize roadmap items is the WSJF (Weighted Shortest Job First) Framework provided by Scaled Agile.
WSJF is great at providing a quantitative relative metric to make prioritization of features objective instead of subjective. Putting items through this framework will help put competing priorities in perspective and give you ammunition to combat the dreaded CEO feature request.
Here’s how it works…
The basic formula is:
WSJF = Cost of Delay / Job Duration (Job size)
Cost Delay is calculated as:
Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement
Similar to story estimating, the Fibonacci sequence is a great way to relatively measure both the inputs for Cost of Delay and the Job Duration (Job Size).
Start by estimating what you perceive as the smallest item first and then work from there to create an initial baseline.
Once you have this data for all the items in your roadmap, you can simply sort by the highest score and do that first.
Simple.
Here is a WSJF Template to get started prioritizing and estimating your roadmap items.
What to include in your Agile product roadmap
Great! You have all the inputs for your Agile product roadmap. Now what…?
Time to finally build your roadmap!
The first step is to categorize your items into a couple of buckets.
For each item define what category it falls in. A few typical categories are as follows:
- Feature Category: This is dependent on your type of solution, but some examples could include Billing, Account Management, Reporting, Task Management, etc)
- Business Driver: ie. Improve user experience, cross-sell, improve security
- Feature Type: ie. new feature, feature enhancement, reduce technical debt
- User Persona: define the user persona the feature is serving if applicable
- Priority: ie. you can use your WSJF score here, or simply start with high, medium, or low but either way there should be a consideration for both value and effort of the feature
Start by doing this in Excel. Here’s a Roadmap Feature Categorization Template to get you started.
Once complete, begin placing items on your product roadmap in a Gantt-style format so you can visualize the timeline of activities. The duration of a feature and how many items you can work on simultaneously will be dependent on the scope of the feature and your team’s velocity.
If you don’t typically release to production every sprint (2 weeks) or shorter, a nice addition is to add planned product release milestones based on when the functionality will be delivered. If taking this approach, it is important to be considerate of the dependencies of the new functionality being released.
Here is a Miro template to build your Gannt-style Agile product roadmap.
Better yet, if you are using Jira, they have built-in functionality that automates the building of your product roadmap.
Pro Tip: If you are struggling to determine how your solution should evolve, try the Product Evolution Canvas.
Note: This is especially effective for new product development and replacement of existing products because as they say, Rome wasn’t built in a day, and your product won’t be either.
In principle, it is the same as a product roadmap, but instead of a Gantt-style view, you instead bucket functionality into 3 specific waves or evolutions of your product to start.
Let’s use an MVP as an example.
- The intent of an MVP, your first wave, is to be functional. You should be focused on delivering the minimum viable collection of functionality that allows the end user to complete what your solution is intended to do in an end-to-end manner.
In the example above, the goal is to get from point A to point B, and a fully functioning skateboard does that.
It may not be pretty, but it should work with the main focus being that the solution actually provides value in a very specific manner. Overloading features in this wave is bad practice. Focus on your core.
- The second wave is typically focused on the core product. In this phase, you’re getting into more specific core key user scenarios that are of the highest priority for your users.
Now we are on a bike and have a seat, yay!
- The third wave is focused on your full-scale product. At this point, you are focused on the core set of features that show off your product’s full potential.
Too many folks try to start with the 3rd wave before focusing on accomplishing one high-value, end-to-end user flow in a focused way.
The Product Evolution Canvas helps avoid this trap.
Use our Miro template to align your team on the evolution of your product.
Frequently Asked Questions
The Product Owner is ultimately accountable for the roadmap, but by no means does it alone. It requires input from customers, the strategy, and all areas of the organization. They act as the ultimate synthesizer of that information.
- Leadership
Understand your strategy behind the product and understand how it fits in the broader product portfolio and company strategy. - Marketing
Develop the go-to-market plan, educate customers, and generally help create demand and excitement for the new things you are building. - Customer Support
Become aware of new functionality they will need to be skilled in when questions about it come in, and they will. Especially when a big product release is taking place, and they may need more hands on deck. - Engineering
This one is fairly obvious, engineers need to know what to build, but, more importantly, they need to understand the why behind it. Don’t be surprised when your engineers provide you with a better solution for a problem when you give them the why. - Sales
The sales team will need to be aware of new functionality so they can work it into the value they talk about when pitching to customers. They will also want to know if a new product release will impact any of their existing accounts.
| Startup | Large Company | |
| Duration | Shorter: Most startups don’t know if they will be alive in 6 months let alone what they will be building. The focus is generally on the short-term. | Longer: Planning is sometimes focused years in the future (not to say they always get it right) |
| Frequency of Updates | Frequent: Startups are focused on shipping, testing, validating, and shipping again. This drives more frequent change to reach product market fit. | Infrequent: Large companies tend to have more established user bases and, as a result, have less volatility in their roadmap. |
| Goals | Short-Term Focus: The focus is on validating their business idea and shipping a viable product. | Long-Term Focus: Roadmaps are typically more nuanced and have different strategic elements at play. |
| Dependencies | Few: The product and the team are typically smaller allowing teams to be more nimble and step on each other’s toes less. | Many: A large company typically has entire teams dedicated to specific functional areas and also tend to have legacy products and integration to consider. |
Best practices and mistakes to avoid when building your Agile product roadmap
Best Practices:It is no surprise story is an effective mechanism (Look at Disney). Use it to your advantage. Your roadmap is essentially a storyboard of where your solution is going and how it is going to help your end users win the day. Use it to get buy-in, rally the troops, and, in general, get folks aligned behind your products why.
The ability to say “No” is a true skill. As a product owner, you have to become skilled in this. Otherwise, you will end up with a product trying to serve everyone but your target customer.
Jira’s roadmapping functionality is a great tool if you’re already managing your product backlog in Jira. Just ensure you are keeping things at the epic level on your roadmap.
Let your team know that your roadmap is a plan and, like any good plan, it is likely to change. Get your team comfortable with change up front, and use it to your advantage to best serve your customer and the market as you continue to learn as you build.
Roadmaps are intended to tell a story about the evolution of your product. Stay at the epic and feature level and don’t get down to user stories. Those are best reserved for your product backlog.
Forecasting and estimating is hard. Be aware of that going in and be careful of always being overly aggressive with your roadmap. If you are always missing your targets, people will begin to take notice, and stop relying on your roadmap
Yes, these are easy, and yes they show you are being productive… But they are an illusion. If you end up building a ton of features no one truly wants, you will end up with a feature rich mess that is extremely hard to sell and has low usage. Go back to your strategy and focus on high value features, even if they are complex and hard to build.
The features on your roadmap are not your kids. Say it again… Sometimes you just have to let certain features go, especially when they end up not tying in with the overall strategy of your product.
Yes, the CEO has a great perspective and is a critical stakeholder when building your product, but you must be careful not to give them a blank check to request anything they want built and have it automatically go to the front of your roadmap. The best way to combat this? A well-structured roadmap. CEOs are logical creatures. Show them why something should not be a high priority with data and logic, and they will typically listen.
This sounds obvious but so many teams fall into this trap. It is the easy way out to just copy what someone else has, but it may not fit into your strategy and plus, someone else is already doing it. That is no way to stand out.
What you communicate to customers and your product roadmap you are executing against are two different things. There is typically higher volititilty in your roadmap which can upset customers if you don’t deliver on time. This is not to say you don’t provide customers an idea of where your product is going, but you should be fairly certain you will be able to deliver and keep it at a much higher level than the one you use internally.
HatchWorks’ Proven Approach to Iterative Software Development
Building a great Agile product roadmap is not easy, but it is critical if you want to build a product your customers and business will love.
This is a core component of our iterative approach of making sure what we build adapts to the needs of your end-user, your business, and the market.
Need help building and delivering against your product roadmap?
Let us help with our integrated US and Nearshore Agile software development teams.
