What’s an Agile Product Roadmap?

The simplest definition of an Agile product roadmap might be, “something that shows people what we’re building now, and what we might build later.” They’re often brought up as a response when Agilists hear complaints like, “No schedules?! How does anybody ever know when things will be done?” But a product roadmap isn’t just a new term for a schedule. Schedules are mostly about expectation setting and status. They answer questions like, “What’s supposed to be happening today (based on guesses we made a year ago)?” Product roadmaps are a fundamentally different thing. While they may include some notion of time, they more focused on answering questions like, “Why are we building these particular things now, and not those other ones?”

What a Good Product Roadmap Is Not

If you search for the phrase, “Agile product roadmap,” typically the first several hundred image results are going to be from people proudly posting images of Gantt-type project schedules. These typically map task-level activities on a minute-by-minute basis and extend several months (or years!) into the future. It’s unfortunate because that type of artifact doesn’t solve any of the problems that we use product roadmaps for, and at the same time it creates a bunch of new problems:

• It takes a lot of time to set up. Even a seasoned scheduling professional is going to need hours to build the initial version. They’re also going to need to constantly consult team members and others about start/stop dependencies, skill blends, and so on.
• It gets interpreted as a promise, instead of our current guess. You may know that every item is listed is based on a guess that a prior condition will work out, but organizations are used to viewing schedules as commitments. Someone’s going to expect all of those ‘promises’ to come true.
• It takes a ton of time to maintain. The shelf life on those highly detailed schedules is very short. This means you’re going to be spending a lot of hours adjusting the document every time you have a conversation that makes the last version untrue.
• It doesn’t make sense to anyone except the person who built it. The detail is so granular that typically only the author can understand the broad strokes of what’s being said. To explain it to someone else, requires booking an hour-plus meeting to walk them through it, and then you have do it all over again every time you make an update.

What a Good Product Roadmap Is

What does a good product roadmap look like? There are lots of great answers, and they range from extremely basic to intricate. A few of my favorite examples include:

• Now/Next/Later Roadmap. This is a very simplistic depiction that separates feature-level goals into three time horizons. Either something is in the release we’re building right now (now), we think it’ll be in the next one (next), or it’s sometime in the future after that (later).

• Goal Oriented Product Roadmap. This takes the idea of separating features across time horizons and adds the overall learning goal or business milestone that is the focus of that effort. We also state the measures, or metrics, we’ll use to assess whether we’ve met that goal.

• Trainyard Map. This approach is useful for showing how capabilities expand or build upon each other over time, often with some nod to timeline estimates. This is useful for when we’re trying to assess longer term impacts of near-term tradeoffs.

• Impact Map. Strictly speaking, this is not a roadmap. Yet I’m including it here because I use them in all the same contexts that I use the other approaches listed here. Impact maps trace an objective goal: typically an agreed-on definition for the value that we’re trying to deliver. This goal is traced through the specific types of persons whom we need to influence to reach that goal. Then, we must articulate individual impacts in order to help each of the persons to realize value. Impact maps are great for talking to everyone, from teams to stakeholders to executives, because they help connect the dots between nitty-gritty tactical actions and slow changing strategic aims.

There are tons of additional good options, so don’t feel limited to those for approaches. What all of them have in common is that they’re low effort to build and maintain, but high-value as communication and consensus building tools. They help a Product Owner explain to stakeholders or developers not just what is being built right now, but why we’re building those things now. The more clarity we can create around the ‘why,’ the better everything seems to go.

Because good roadmaps are lightweight, we don’t have to choose a single model. You might decide you need a Trainyard roadmap for things to make sense to your CTO, and a goal oriented roadmap to negotiate with stakeholders. Both models are supported by an impact map that links outcome objectives through specific actors all the way to individual backlog-level ideas. None of them take much time to set up or update, so it’s not a huge hit on a Product Owner’s time. Though, be careful that they’re all saying the same things in the broad strokes.

Effort aside, what any good roadmap format does is help a Product Owner have conversations about choices that are rooted in a value delivery. Individual features are not the point. Backlog items are a means to some end – whether it’s increased revenue, expanded market share, or reduced technical risk. A good roadmap is a tool for showing how technical context may impact business decisions, how business context may impact technical decisions, and keeps everyone involved focused on outcomes.

Need Some Help with Agile Product Roadmaps?

There’s a couple of immediate steps organizations and leaders can take to help Product Owners create roadmaps that facilitate, better clarify a vision, and support healthier Scrum.

Up Your Product Owner’s game.

Scrum is often described as ‘easy to learn, hard to master.” That’s absolutely true! Many of the problems discussed here are easy traps for a new and inexperienced Product Owner. If you’re new to the role and looking for a good foundation, our Certified Scrum Product Owner (CSPO) course is a great place to start. For those who’ve already been serving as Product Owner for a bit, now might be a good time to add more skills to your toolbox in an Advanced Certified Scrum Product Owner (A-CSPO) workshop.

Check out NextUp Solutions’ Upcoming Courses

Bring in an Agile Coach.

One of the most valuable services provided by a seasoned Agile coach is mentoring Product Owners and creating a path for organizations to grow and develop Agile product management as a career. Great Agile coaches can model key behaviors and teach core skills without undermining the position of your Scrum Masters. This is done in a way that supports your teams’ ownership of their improvement.

Check out NextUp Solutions’ Coaching Services