Agile vs. Roadmaps — Ending the Battle [+Webinar]

Diverse Group of People Working Together in Background with Overlay of "Product Roadmaps Using Agile"

Watch our on-demand webinar, Unlocking a More Strategic Product Roadmap using Agile, to learn more in-depth about taking your product roadmap to the next level using Agile.

The Product Roadmap

Early in my career as a Product Manager, a mentor provided this advice: the primary responsibility of a Product Manager is to drive sustainable business growth. One of the tools we use to communicate how we accomplish that objective is a product roadmap — a living document that outlines what we’re doing, where we’re headed, and how we’ll get there. The roadmap is a key deliverable for the Product Manager, because if we don’t get it right, we run the risk of executing without direction and losing credibility as a Product Manager.

To drive sustainable business growth, I’ve partnered with many engineering teams to build digital products, platforms, and experiences. For the last 10 years or so, we’ve followed some version of Agile: SCRUM, Kanban, or another customized form of Agile methodology. These Agile methodologies offer many advantages, including transparency into what’s being done, and what’s standing in the way. Similarly, product roadmaps can offer transparency and clarity into where we’re going and how we want to get there.

The Challenge

The challenge of marrying Agile delivery methods with product roadmaps: product planning is often linear, and doesn’t embrace the iterative principles used to develop modern software. As a result, linear product roadmaps could lead to linear software delivery. How do we resolve this conflict?

Moving away from the linear model

Jeff Gothelf offers this insight: “Digital product development is not linear. It is iterative.” We build software to test hypotheses, to learn, and to improve customer experiences – all in an effort to drive sustainable business growth. Rarely is this a linear path. Jeff goes on to say:

“The traditional linear roadmap model, one where there is a starting point and a clear, feature-specific endpoint (almost always with a fixed date) is outdated. It reflects an output-focused mode of operating a digital business. Instead, today, successful product-led organizations focus on outcomes. Outcomes are the true measure of the efficacy of our work and how well we’re meeting the needs of our customers and users.”

As Jeff points out, PMs should make an intentional shift away from product roadmaps defined by timelines and linear outputs, and instead move toward creating product roadmaps that tell a story of how you are going to solve your customers’ biggest problems — and how you will measure the outcome of solving those problems.

Plot the Outcomes

An outcome-oriented product roadmap possesses the following characteristics or principles:

  • A roadmap is a prototype for your strategy. It’s a communication device meant to facilitate discussion with your stakeholders.
  • The roadmap should be strategic in nature, and define the what and the why. The use of OKRs helps here, because when done right, the roadmaps illustrate why things are done – what goals/objectives will they help achieve?
  • A roadmap is a dynamic, collaborative effort with your product owner and engineering manager. The engineering manager or solution architect on your team should have a say in your roadmap, as there will be enabler/technical debt features that you need to account for.
  • The roadmap will change frequently, based on how your users react to your latest features. You will need to constantly check and adjust based on their behavior. This flexibility aligns well with the Agile development methodology, rather than being in conflict with it.
  • The roadmap should be shared with all your internal and external stakeholders with some regularity. Set an expectation with your stakeholders that the roadmap isn’t set in stone and it will change with regularity. When you meet with your stakeholders, discuss and review your changes with them.
  • The roadmap should be simple to understand and easy-to-update. It’s a living document – expect it to be updated quarterly, and sometimes monthly. If you find yourself updating it more frequently than that, you may have a backlog instead of a roadmap.

Now, Next, Later Roadmap

My preferred product roadmap template uses the “Now, Next, Later” approach:

There are other variants, but let me explain why this is my preferred format:

  • The “Now, Next, Later” product roadmap is a high-level abstraction of your product vision, and an invitation to a discussion with internal and external stakeholders.
  • This view creates focus on User/Customer Value and focuses on the desired outcomes.
  • Unlike a detailed engineering plan or dump of Jira, this format doesn’t show how long you’re working on it.
  • Finally, this format doesn’t represent a contract for Sales to commit you to.

Using the “Now, Next, Later” approach, your product roadmap can better leverage Agile delivery methods that embrace change, while accounting for uncertainty and complexity. Outcome-based roadmaps ensure transparency across product, design, engineering, and various other stakeholders. These roadmaps serve as strategic communication tools that are critical for PMs to share their vision of “what could be,” and ensuring PMs maintain credibility as executors.

Stakeholders expect to be able to read roadmaps at-a-glance, so the less text the better. They should be easy to understand without having to be studied. The content should outline what’s being built and approximately when it will be delivered. It should also contain an estimate of confidence or certainty. Again, keep it simple with levels such as high, medium, low, and uncertain.

Start the Shift in Mind-Set

If you’re thinking, “My executive stakeholders expect a list of features and hard dates,” you’re not wrong. And neither are they. This shift in thinking will take time and several repetitions before it takes hold. As a Product Manager, you should be prepared to get ahead of these concerns by allotting time to have one-on-one conversations with your executive stakeholders. Explain to them the benefits of being able to more rapidly react to customer needs and market shifts, ultimately improving the product’s ability to drive sustainable business growth.

Watch our on-demand webinar, Unlocking a More Strategic Product Roadmap using Agile, to learn more in-depth about taking your product roadmap to the next level using Agile.

[su_glide_button text=”WATCH NOW” link=”https://pm.280group.com/webinar-unlocking-strategic-product-roadmaps-using-agile/” style=”default”]

About the Author


Jake Yingling is the Director of Client Services at 280 Group.
Jake leads and manages the Client Services team that delivers training, optimization services, and consulting to its enterprise customers. He is a seasoned professional with over 15 years experience in product management, software development, and customer success. Jake is known for creating products and experiences that delight customers, maximize operational excellence, and deliver financial performance. Jake has spent time at companies including Capital One, E*TRADE, and Fiserv.
280 Group is the world’s leading Product Management training and consulting firm. We empower Product Professionals with the knowledge and tools to create products that matter.

3 Replies to “Agile vs. Roadmaps — Ending the Battle [+Webinar]”

  • Planning is fractile in nature. Agile is the name we give to the smallest part of the plan. We would have never got to the moon if each company had done what they thought was best in any given month. Every company plans big, breaks it down to projects with sub-projects and sub-sub-projects. Finally the software people call their part “agile” and get going. No-one builds a big “thing” in a purely agile manner. No company plans in an agile manner. They have a log term plan cos it takes a long time to implement it. Software support is no different. Planning is fractile in time and projects.

  • The 280 group OPM course and community has been the absolute best money I have ever spent on my education. I am not a product manager yet, but the format of your program, and the information contained in your emails is phenomenal. Clear, concise, easy to understand, no fluff paragraphs. It’s the education I wish I had got for my $50,000 bachelors!

    • Hi William,

      Thanks so much for the great feedback! We appreciate you being a part of our community and seeing the value in our content. Cheers to building better products!

      280 Group Team

What are your thoughts? We’d love to hear from you.

Your email address will not be published. Required fields are marked *