Product Roadmaps

People often think that Agile is all about shooting from the hip and that planning is shunned. In fact, even though Agile rejects the Waterfall approach of defining system requirements for months and years before development even begins, a successful project will always be well planned and have a clear path forward. The product roadmap is one tool that helps with strategic project planning and communication of that plan.

Here is a link to a sample product roadmap that you can reference as an example. If you can’t access this link or would like a soft copy, contact me at aaronhsmith@gmail.com and I’d be happy to email it.

Once you have identified most of the user stories and the business priories, you can knock out the product roadmap rather quickly. I usually take one from a previous project and blank it out, then start filling in the top-level Milestone deliverables. This indicates the major components that will be delivered for that milestone. Once the Milestones accurately reflect the customer’s priority order, I start filling in the boxes with brief user stories descriptions.

Reviewing and revising a draft of the product roadmap with the customer can have some nice benefits:

• Refined priorities – Seeing the proposed order of development from an overall product level can lead to refined prioritization, e.g. “I know I put Finance and Reports as priority ones, but we really need Finance first; Reports can come later.”
• Planned dependencies – Reviewing the roadmap prompts people to consider and adjust for dependencies, e.g. “Actually, Payments are dependent on the Finance Admin piece, so swap the order of the two.”
• Confirmed next steps – Once you have this high level agreement, you now know the basic scope of Milestone 1. You can then move forward with confidence as you dive into more detailed story definitions for the upcoming iterations.

Now for a related topic: Are Product Roadmaps Dangerous?