Agile Product Manager in the Enterprise (5): Responsibility 3 – Maintain the Product Roadmap

Note: this is the fifth in a series of posts on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a continuation of the series on the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Manager/Product Owner series on this blog as well as a series in the Agile Journal. (See the resource page for a mapping to the Agile Journal Article Series).

In an earlier post, Agile Product Manager in the Enterprise (2): A Contemporary Framework, I described a framework for product management and a separation of roles for the Agile Product Owner and Agile Product Manager in the enterprise context. I concluded with a suggested set of agile-specific responsibilities that are different than the activities in a pre-agile world. To reiterate: they are:

1. Own the Vision and Release Backlog

2. Manage Release Content

3. Maintain the Product Roadmap

4. Build an Effective Product Manager/Product Owner Team

In prior posts, I’ve described Responsibility 1- Own the Vision and Release Backlog and Responsibility 2 – Manage Release Content.  In this post, I’ll describe the specifics of Responsibility 3: Maintain the Product Roadmap.

————–

As we have described the Vision so far, it has been presented as time-independent. This is appropriate as the objective is to communicate the gestalt of “what this thing is we are about to build” and overloading the Vision with prospective timelines will likely quickly derail the discussion of the “what”.

However, in order to set priorities and plan for implementation, we need an additional perspective, a product Roadmap that provides a view we can use to communicate future objectives to our outside stakeholders. An agile Roadmap is not a particularly complicated thing, nor is the mechanical maintenance of it difficult. For example, a typical Roadmap might be communicated in a single graphic as follows:

Sample Graphic Representing a Product Roadmap

The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set. While it is a simple thing mechanically to represent the Roadmap, figuring out the content for anything beyond the next release is another matter entirely. The topic of what else the team plans to ship and when can be a fascinating and contentious topic in agile. However, the easiest way to think about the Roadmap is that it is an output, rather than an input to the Release Planning process.

• The dates and themes for the next release are fixed. The features are prioritized and variable.
• The teams can commit only to the features in the next upcoming release. Releases beyond the next, represent only a best estimate.

The Roadmap, then, is a “plan of intent” and is subject to change as development facts, business context and customer needs change. With respect to the upcoming release, perhaps the most important guidance is this:

Even though the team has committed to the objectives and we have agreed that the feature set cannot be guaranteed, it is a reasonable expectation that the agile teams will:

1) meet the date

2) accomplish the theme

3) deliver most of the features, and certainly the highest priority ones, with the requisite quality.

Anything less would be unprofessional and belie the power, discipline and accountability of our agile enterprise model. Moreover, it will eventually threaten our own empowerment, as failure to deliver will inevitably cause the implementation of various controls to “help us”!

On Confidence and Commitments for Release Next, Next +1 and More

With the enterprise release planning function, the objectives and prioritized feature set for “Release Next”  should be a high confidence plan of intent, at least for those agile enterprises who have some initial degree of maturity. And to be flippant for a second, it’s often true that release Next +1 has a pretty clear definition as well, if for no other reason than it usually “must” contain all the stuff that didn’t fit in release Next! After that however, most bets are off and the enterprise must rely on its portfolio level agile estimating and planning, assuming that such a degree of maturity exists in the enterprise. (click here for more on Portfolio estimating).

In any case whoever, it is important to keep any such future commitments abstract so that the intent can be met under most normal circumstances. After all, if long term commitments are fixed, then you have essentially re-entered a waterfall model of fixed resources, fixed time and fixed scope. Even worse, in so doing, the enterprise will lose its ability to adapt to change, which was the purpose of agile to begin with!

Summary

This concludes Agile Product Manager Responsibility 3 – Maintain the Roadmap. In the next post, I’ll describe Responsibility 4 – Build and Effective Product Manager/Product Owner Team.