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