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.

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

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.

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.

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