Agile Zone is brought to you in partnership with:

Roman Pichler is an agile product management and Scrum expert. He is the author of the book "Agile Product Management with Scrum" and writes a popular blog for product owners and product managers. Roman is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

The GO Product Roadmap – a New Agile Product Management Tool

12.03.2013
| 5081 views |
  • submit to reddit

A product roadmap is a high-level, strategic plan, which provides a longer-term outlook on the product. This creates a continuity of purpose, and it helps product managers and owners acquire funding for their product; it sets expectations, aligns stakeholders, and facilitates prioritization; it makes it easier to coordinate the development and launch of different products, and it provides reassurance to the customers (if the product roadmap is made public).

Unfortunately, I find that many product managers and product owners struggle with their roadmaps, as they are dominated by features: There are too many features, and the features are often too detailed. This turns a roadmap into a tactical planning tool that competes with the Product Canvas or product backlog. What’s more, the features are sometimes regarded as a commitment by senior management than part of a high-level plan that is likely to change.

The GO Product Roadmap Explained

Faced with this situation, I have developed a new goal-oriented agile roadmap — the GO product roadmap, or “GO” for short. GO is based on my experience of teaching and coaching product managers and product owners, as well as using product roadmaps in my own business.

The following pictures shows what the GO product roadmap looks like. You can download a PDF and Excel template by simply clicking on the picture.

GOProductRoadmapExplained

The first row of the GO roadmap depicted above contains the date or timeframe for the upcoming releases. You can work with a specific date such as  1st of March, or a period such as the first or second quarter.

The second row states the name or version of the releases, for instance, iOS 7 or Windows 8.1.

The third row provides the goal of each release, the reason why it is worthwhile to develop and launch it. Sample goals are to acquire or to activate users, to retain users by enhancing the user experience, or to accelerate development by removing technical debt. Working with goals shifts the conversation from debating individual features to agreeing on desired benefits making strategic product decisions. The development team, the stakeholders, and the management sponsor should all buy into the goals.

The fourth row provides the features necessary to reach the goal. The features are means to an end, but not an end in themselves: They serve to create value and to reach the goal. Try to limit the number of features for each release to three, but do not state more than five. Refrain from detailing the features, and focus on the product capabilities that are necessary to meet the goal. Your product roadmap should be a high-level plan. The details should be covered in the Product Canvas or product backlog, and commitments should be limited to individual sprints.

The last row states the metrics, the measurements or key performance indicators (KPIs) that help determine if the goal has been met, and if the release was successful. Make sure that the metrics you select allow you to measure if and to which extent you have met the goal.

A Sample GO Product Roadmap

To illustrate how the GO template can be applied, imagine we are about to develop a new dance game for girls aged eight to 12 years. The app should be fun and educational allowing the players to modify the characters, change the music, dance with remote players, and choreograph new dances. Here is what the corresponding GO roadmap could look like:

SampleGOProductRoadmap

While the roadmap above will have to be updated and refined at a later stage (particularly the metrics), I find it good enough to show how the product may evolve and make an investment decision.

When creating your GO roadmap make sure you determine the goal of each release before you identify the features. This ensures that the features do serve the goal. Filling in the roadmap template from top to bottom and from left to right works well for me.

Wrap-up

The GO product roadmap provides a new, powerful way to do product roadmapping. Rather than focussing on features, GO emphasizes the importance of shared goals. This makes it easier to communicate the roadmap, create alignment, and use it as a strategic planning tool that provides an umbrella for the Product Canvas and the product backlog. The metrics provided by the tool ensure that the goals are measurable rather than lofty and fuzzy ideas. Download the template now, and try it out!

You can learn more about creating effective product roadmap and working with the GO product roadmap by attending my Agile Product Planning training course.

I would love to hear your questions about the roadmap and your experiences of creating product roadmaps. Please leave a comment below, or contact me.



Published at DZone with permission of Roman Pichler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ian Mitchell replied on Tue, 2013/12/03 - 8:57am

Hi Roman

According to Scrum rules, sprints can never be more than a month. Each sprint must result in an increment that is potentially releasable at the discretion of the Product Owner. Yet roadmaps such as this are typically used for less frequent releases (you mention quarterly).

So how can these roadmaps, and the large batch sizes they represent, support agile delivery and incremental funding based on timely evaluation? How can they support (for example) a Lean Startup approach using CI/CD?

Jacek Furmankiewicz replied on Tue, 2013/12/03 - 11:06am

 Roman, have you ever heard of the Go programming language?

Probably not a great idea for you to use the same name for a product.

Roman Pichler replied on Tue, 2013/12/03 - 11:27am in response to: Ian Mitchell

Hi Ian, Thanks for your comment. I am not sure I fully understand your concerns. My roadmap tool suggests dates and goals for each major release / product update. You can use Scrum to iterate towards each release. For instance, it would take several sprints to get from Version 1 to 2 in my example. 
With regards to Lean Startup, you may want to use the roadmap to show how the contents of a Vision Board, Business Model Canvas or Lean Canvas can be realised over time, similarly to what I have tried to show in my roadmap example. CI/CD serves as a feedback mechanism which can be happily employed to get from one version to the next. Hope this helps.

Roman Pichler replied on Tue, 2013/12/03 - 11:32am in response to: Jacek Furmankiewicz

Hi Jacek, Thanks for your comment. I was not aware of the Go programming language, but I don't see an issue as my product roadmap is a product management and not a software development tool. 

Jacek Furmankiewicz replied on Tue, 2013/12/03 - 1:50pm in response to: Roman Pichler

 true, but searching for it will become more difficult. Imagine you call your product "Oracle". I am pretty sure the first 1000 searches for "Oracle" would never show your product. :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.