Agile/Scrum and Product Roadmaps


By Saeed Khan

A common question that come up when discussing Agile/Scrum is how to develop and maintain a product roadmap in an Agile environment.

The confusion seems to come from the focus of Scrum on short development cycles and the ongoing prioritization and reprioritization of needed functionality in the Product Backlog.

So, is there a conflict here that would prevent or hamper the creation and maintenance of product roadmaps in an Agile environment?

The answer is absolutely not. In short, Scrum is a development methodology, and roadmaps are business planning and communication tools. The two are independent of one another and there should be little impact on maintaining a product roadmap in any company where Engineering adopts Scrum.

Not satisfied? OK, here’s a slightly more detailed answer.

First, let’s agree on what a product roadmap is NOT.

It is NOT a 100% guaranteed, take it to the bank (ok, not all banks these days) definitive and unswerving description of what will absolutely be built in the next several releases of a given product.

No, that is not what a product roadmap is. Even though, that is what a lot of salespeople will want and demand it to be.

BTW, as an aside, here’s a little trick on how to handle salespeople who demand an absolutely fixed, definitive roadmap for the future. Tell them, Product Management will commit to such a roadmap, when the sales team commits to an absolutely fixed, definitive sales number for the next 4 quarters. Watch their reaction. I doubt you’ll have any takers.

So, what is a Product Roadmap?

A roadmap is a planned future, laid out in broad strokes — i.e. planned or proposed product releases, listing high level functionality or release themes, laid out in rough timeframes — usually the target calendar or fiscal quarter — for a period usually extending for 2 or 3 significant feature releases into the future.

For startups or companies in fast moving and growing markets, those 2-3 releases might only cover the next 12 months of time. For other more mature companies in less dynamic markets, those releases might cover several years.

I emphasized the word “planned” above. Plans are simply plans. They are our intentions for the future given what we know and believe today. They are not commitments. Most roadmap presentations I’ve seen, and virtually every single one I’ve seen from a public company starts with a big disclaimer that absolves the company from committing to anything that is presented in the roadmap.


And, people listening to the roadmap take it in stride. They understand that the future is not certain. What they want to hear is a statement of intent, that is credible and potentially achievable, and that can help them make plans for their own futures.

Note that none of this has anything to do with what kind of development methodology is used to potentially implement the planned functionality. And if anyone does ask, a great answer might sound something like this:

Our development teams use a hybrid approach that leverages the best of current Agile methodologies, mixed with the more predictable and steadfast aspects of waterfall. This gives us the flexibility we need to adapt to changing market conditions and customers needs, but still maintain a rock-solid foundation in our development cycles that enables us to continue to deliver high quality releases year after year.

If nothing else, people will nod their heads in agreement and never again ask about your development methodology.

Finally,  most product roadmaps are so devoid of useful information that they are simply a set of talking points or a listing of product release codenames on a single slide. This provides a lot of wiggle room for the presenter (Sr. Executive, Product Manager, Product Marketer or someone else) to paint a rosy picture of the future but never actually commit to anything.

Here are a few REAL roadmap images I pulled down from the web. Which of these companies uses Agile in the development shop? Can you tell? Does it matter?

Click on any image to enlarge to full size.

Saeed

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

We really want to hear your thoughts...

  1. Pingback: Jordan Meyerowitz | We’re 7 years old…and a week

  2. Pingback: We’re 7 years old…and a week | On Product Management

  3. Pingback: Roadmap Discussions » Strategic Product Manager

  4. Pingback: Jason Toney


  5. Curious to know if anyone draws a distinction between the release plan and a roadmap. Agile considers a release plan a commitment, generally 60-90 days forward. And non-Agile organizations can use these too, but possibly covering as much as 6 month timeframe.

    The roadmap then covers themes/problems forward 12-15 months beyond where the release plan leaves off. It becomes much clearer what is committed (release plan) vs. what is projected (roadmap). We think this helps manage Sales, too. If it’s not in the release plan, don’t promise it!

    I bring this up because the Wicket example I would consider a release plan, not a roadmap.

  6. Pingback: Software Product Management » Blog Archive » Roadmap в Agile

  7. Pingback: Happy (belated) birthday to us (again)! « On Product Management


  8. @Saeed,

    Yup, me too. I definitely agree with “we’ll solve part of problem X in this release” message. But I set expectations that “solution A” is only the “best approach so far.” Where the further away problem X is in the roadmap, the more likely it is that solution A becomes solution B.

    @Ahmed,

    With the way your teams are staffed, where are the design skills staffed? For example, you list that product management is responsible for determining that feature Y is the right design for product X (solving problem A, I assume).

    I definitely believe that “proposed solution Y” needs to be vetted by product management as an effective way to solve problem A. I am not convinced that inventing solution Y is a product management responsibility. UX (from a user perspective) and architecture (from a software perspective) and process design (from a business perspective) should be the drivers of “invent a solution Y to problem A.” Do you staff those skills within your product management team?

    TIA


  9. Hello Saeed,

    Great post. I have been in software product management for over 14 years. I like to distinguish between the product roadmap and the sdlc process using four words: What, Why, When, How.

    Product Management is responsible for defining What should be built by software engineering (product X needs feature Y), Why the company should be investing time and resources to build feature Y (implementing feature Y will provide our customers with a significant cost savings in deploying and using product X in their company, thus providing our company with a competitive differentiator) and product management is responsible for prioritizing each feature into a product roadmap that takes into account the What and Why.

    The entire product team, collectively, is responsible for devising the most efficient process for delivering the business requirements to the market while ensuring no short cuts are made that will diminish the product’s quality and its value proposition to customers.

    I hope you find this useful.


  10. Scott,

    Thanks. I agree with defining problems. I usually present these as themes for upcoming releases and then dive down a bit deeper to describe the specific solutions or functionality that is planned. I also try to discuss the limits of what is planned. i.e. ensure the audience understands the breadth or depth of the plans or any significant constraints. People appreciate that level of detail, particularly if there is a valid reason.

    e.g. We’re addressing problem X in the next 6 months. We’ll be delivering A functionality in that area. We’d really like to do B, but that would take us a year and we understand most of you don’t want to wait that long to address X. In future releases we’ll look to expand the functionality to get us closer to B.

    Or something like that.


  11. Thanks Saeed (and Kevin – check out his article too – cool idea there).

    I like talking about roadmaps in terms of problems, specifically, saying “6 months from now, we will focus on problem X faced by users Y” not “we plan to have widget Z.” It provides “more wiggle room” for the team to invent great solutions, while still providing more information (we care about addressing this need for these people).


  12. Kevin,

    Thanks for the comment. There are many ways to present forward looking information. Most roadmaps I’ve seen (and created) are valid for about 90 days. After that time, the world has changed enough that the roadmap needs to be updated or changed as well.

    A large deal that siphons development resources from a small team can derail even the most sincere and well thought through roadmaps. So can an industry changing event such as a large company acquiring one of your competitors and entering your market segment. So can a sudden economic slowdown. :-)

    In the end, beyond the current release being developed, the future is too fuzzy to predict with any clarity or granularity. The overall known business intent is reflected in the roadmap. Anything more granular than that is very difficult to pin down.


  13. Great post Saeed. I am the product manager at a startup and this has been on ongoing discussion here as well. I blogged about my thinking on roadmaps in agile environments here. In addition more recently I have taken to working with the rest of the leadership team to develop guiding principals to help people understand why certain product decision are or will be made for the roadmap or a given release. This also helps decentralize the process to some degree of what is sometimes referred to commanders intent. This way, the roadmap not only talks about the plan but why the plan is the way it is.