Behind every effective agile product roadmap is a well-thought out plan. As true (and cheesy) as that statement is, it’s also a bit of a weird statement since a product roadmap is meant to be a (flexible and transparent) plan that aligns stakeholders across your organization.
So what we’re saying is you need to plan for your roadmap plan. A truly effective agile roadmap (i.e. plan) is one that people will have confidence executing. And without proper thought put into that roadmap plan, you’ll be hard-pressed to find individuals willing to stake their time, money and energy on your product roadmap.
You might be asking: what’s the point in planning for an agile product roadmap when it will ultimately change? You’re not wrong — your roadmap should be a statement of intent that you update frequently. But you should be updating your agile roadmap to reflect changes brought on by your agile environment, organization and market — NOT because you poorly planned your roadmap. Prep work for your agile product roadmap can prevent unnecessary changes and even complete overhauls of your plan.
For all the PMs we’ve spoken to, putting together a roadmap plan is a key step in their workflow — particularly in agile. So before you open up your roadmapping tool (or app or whiteboard or spreadsheet... shudder) to create your agile roadmap, here are five steps you should take for effective agile product roadmap planning.
Real-world ways to build agile roadmaps. Get the helpful, non-boring guide. Download it here.
Step 1: Set the goals for your agile product roadmap plan
Your agile roadmap communicates with and aligns stakeholders, but what are you addressing? Even if you have a list of impressive features to release, the big picture must be considered. Your objective might be achieving product-market fit, or launching “sticky” features. Whatever the goal, your roadmap should convey the plan for achieving your high-level strategy.
Without established objectives, expect stakeholders to walk away from your roadmap with different priorities (the TOTAL opposite of what you want). Your roadmap should always tie directly back to your primary goals so that stakeholders are clear about your product strategy.
Ask yourself if the document speaks to your company and product vision
Bonus question: If you want to get reallyyy specific, also ask yourself what key performance indicators you want to focus on. Planning your main KPIs will allow you to create a roadmap that explains how you’ll hit those targets.
Step 2: Evaluate your resources for the roadmap plan
If you have ten developers, but two are on vacation and one is shared by marketing, how much can you ship in your next sprint? The answer: probably not as much as you could with a fully available team of ten developers. Planning for your agile roadmap should address your available resources and their constraints.
Another thing to plan against: the speed at which resources operate. You’re going to get pushback on how fast (or slow) your team is delivering on your plan—even in agile. Plan a cycle length that works best for your team — especially if you’re representing time on your roadmap.
Determining your team’s speed will let you develop a plan grounded in reality.
Step 3: Check-in with your users
It boggles our minds when organizations build roadmaps based solely on quantitative market data. User needs go much deeper than statistical research. Speaking first-hand to customers during your planning provides insights into disregarded investments. Before committing to anything on your roadmap, it makes sense to understand if your users, you know, actually want these things.
Additionally, user research makes a really, really strong case when getting buy-in.
User research shows stakeholders that your agile roadmap isn’t just a random, aimless plan you pulled out of thin air, but one developed from authentic user needs.
It’s pretty hard to refute real user needs.
No matter your agile style, check out our free agile roadmap template and make it your own.
Step 4: Determine your agile product roadmap plan's building blocks
Next up: establish your major themes, and the features that fall under each of them. Then break it down into epics and user stories. From there develop high-confidence estimates on your features, epics and stories, and identify any dependencies that could hold you back.
Hack away until you have all the building blocks you need before assembling your roadmap.
If this seems like a lot of work before creating an agile roadmap, we say: planning for these elements will prepare you to address (and defend) your choices when changes do pop up. And if changes are needed, you can speak to impacts and trade-offs that must be made.
Step 5: Hold planning sessions
This step isn’t so much isolated, but more ongoing and works in conjunction with the previous steps. Make agile roadmap planning a team effort by putting your whole product team in one room. This is your opportunity to really understand together your use cases, discovery work and objectives before making any roadmap investments.
Think of it as a way to get buy-in for the plan for your plan (again—strange, we know).
Early buy-in during your planning stage will be beneficial when getting official buy-in and public affirmations from your stakeholders.
Want to see real-world examples of well thought-out agile product roadmaps? Check out our ebook (and also get a handy checklist to add structure to your planning process).