20 responses

  1. Adi Furca
    July 24, 2012

    Agile/Scrum and Product Roadmaps – http://t.co/JeyLj4fG

  2. Gogo
    June 19, 2012

    An oldy but goldy… http://t.co/E4R4YEIN

  3. Mark Sedgley
    June 7, 2012

    Great blog for product managers and all other interested parties! http://t.co/OJMAZW5W #scrum

  4. rob
    May 29, 2012

    Check out: Agile/Scrum and Product Roadmaps « On Product Management http://t.co/oysp26sf and http://t.co/8rnkutne #agile

  5. rob
    May 26, 2012

    Check out: Agile/Scrum and Product Roadmaps « On Product Management http://t.co/oysp26sf and http://t.co/8rnkutne #agile

  6. Michael
    March 16, 2012

    RT @onpm: Agile/Scrum and Product Roadmaps http://t.co/SRkHUnfd

  7. Michael Robbins
    October 22, 2011

    Agile/Scrum and Product Roadmaps
    http://t.co/NyVnDb8w

  8. Linda Merrick
    August 13, 2009

    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.

  9. Scott Sehlhorst
    October 28, 2008

    @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

  10. Ahmed F. Osman
    October 28, 2008

    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.

  11. saeed
    October 28, 2008

    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.

  12. Scott Sehlhorst
    October 28, 2008

    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).

  13. saeed
    October 28, 2008

    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.

  14. Kevin Donaldson
    October 28, 2008

    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.

Leave a Reply

 

 

 

Back to top
mobile desktop