Over a million developers have joined DZone.

Agile Product Manager in the Enterprise (3): Responsibility-Owning the Vision

DZone's Guide to

Agile Product Manager in the Enterprise (3): Responsibility-Owning the Vision

· Agile Zone ·
Free Resource

Whatever new awaits you, begin it here. In an entirely reimagined Jira. 

Note: this is the third 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 the last post, Agile Product Manger 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 on 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 this post, I’ll describe the specifics of Responsibility 1: Owning the Vision and Release Backlog.


Owning the Vision and Release Backlog

The Agile Vision

Though the instantiation and delivery models for the Vision (Vision/roadmap/feature set vs. product requirements document) are different, this responsibility is not new to the role. After all, if the Product Manager:

  • Has  a continuous, in-depth understanding of the current solution
  • Stays abreast of the latest industry trends
  • Understands the changing needs of the market and the customer base
  • Articulates a clear direction for addressing gaps and opportunities

Then having a Vision , which articulates a clear direction for addressing gaps and opportunities, is a logical outcome.

Communicating the Vision

As we have noted, in agile the traditional product requirements documents (PRD), system specification, software requirements specifications (SRS) and the like are typically eliminated. In their place, agile enterprises take a leaner approach better suited to the last-responsible-moment, delayed decision making and artifact-light development practices of the agile enterprise.

However, since the PRD and SRS documents no longer exist to specify system behavior, communicating the Vision to the agile development teams becomes even more critical. Doing so is Product Management’s responsibility, because no matter how empowered and energized the agile teams may have become, it is PM’s responsibility to set strategic direction. The Vision answers the big questions for the system, application or product under development, including

  • Where are we headed with this thing?
  • What problem does it solve?
  • What features and benefits does it provide?
  • For whom does it provide it?
  • What performance, reliability, etc. does it deliver?
  • What platforms, standards, applications, etc. will it support?


An Agile Vision Can Take Many Forms

I’ve seen agile teams take a variety of approaches to communicating the Vision. (Note: I covered many of these in more detail in Chapter 17 of SSA- Lean Requirements at Scale: Vision, Roadmap and Just-in-Time Elaboration).These include:

  • Draft Press Release – highlighting the new features and benefits of the solution
  • A “Very Preliminary Data Sheet” which accomplishes the same thing in a concise form
  • Jim Highsmith’s “Product Vision Box“ which uses the product packaging box metaphor to capture similar elements
  • RUP-like Vision Document which is a standardized template which defines users, features, system qualities and the like.  (One very agile team once told me, somewhat defensively, about why they still loved their RUP-derived Vision template: “We write to make sure management understands what we are about to build”)


It doesn’t even have to be that structured

Each of these forms has proven their worth in a variety of agile projects, but it doesn’t even have to be that well structured. In one release planning session I facilitated, there wasn’t an opportunity for the four product mangers to collaborate prior to the release planning session. Even if there were, it’s doubtful that they could have necessarily come up with a harmonized, force-ranked feature set anyway. (Question: what self-respecting product manager wanted their number one feature to be placed fourth on the release backlog?) Instead, we allowed each product manager approximately 45 minutes on stage. Each presented a briefing deck, including a list with descriptions of the top ten new  features proposed  for their solution component. Based on this context, the teams then went into the more detailed planning session.

Clearly, this was not the ideal forced-rank prioritization we like to see in agile and it was left up to the teams to decide what to do about the fact that four product managers had separate priorities. But software, like life, can be a little messy. Most importantly, this model seemed to work really well, in part because the Product Managers were part of the process and by the end of the session they had visibility into what the teams could and could not achieve in the time box.

The Primary Content of the Vision is a Set of Features

No matter the form, the main content of the vision document is a prioritized set of features. In my earlier book Managing Software Requirements , (perhaps attaining agile wisdom means we don’t have to throw out everything we learned prior) we described features as “services provided by the system that fulfill a user need”. Features are “Big Picture” system behaviors that can be described in a sentence or two and which are written so that customers can actually understand, debate and prioritize them.

Of course, in so doing we didn’t invent either the word “Feature” or the usage of the word in that text. Rather, we simply fell back on industry standard norms to describe products in terms of, for example, a Features and Benefits Matrix which has been used traditionally by product marketing to describe the capabilities and benefits provided by our new system. By applying this familiar construct in agile, we also bridge the language gap from the agile project team/product owner to the system/program/product manager level and give those who operate outside our agile teams a traditional label (Feature) to use to do their traditional work (i.e. describe the thing they’d like us to build).

In that text, I also posited that by managing the level of abstraction, a system of arbitrary complexity (from the space shuttle to the spellchecker on this soso editor) can be described in a list of 25 or so features. That still works for agile teams describing a Vision today and features can still be used as the primary placeholder for user value.

Undelivered Features Fill the Release Backlog

In the Big Picture graphic  and series and in the Product Owner blog posts, we noted the primary currency of requirements expressions for the agile teams is the user story, which are contained in the Iteration (story) Backlog. (see graphic)


The Agile Team and their Iteration (Story) Backlog.

The Agile Team and their Iteration (Story) Backlog.

(Note: click here for more on User Stories. Click here for more on the Agile Team.)

In a like manner, the Release Backlog contains the prioritized set of features that have not yet been implemented.

Product Owners and the Release (Feature) Backlog

Product Owners and the Release (Feature) Backlog

Like stories, features can be scheduled (in a release) or unscheduled (waiting for future attention). They are prioritized and estimated. Estimates at this scale are coarse grained and imprecise, which prevents any temptation to over-invest in feature elaboration and estimating. If and when a feature reaches a priority such that it hits a release planning boundary, it will be broken into user stories prior to implementation.

The Vision Must Include any Critical Non-Functional Requirements

In addition, the enterprise is too large to assume that all the global development teams will naturally understand the various system qualities, i.e. those constraints and “ilities”, such as reliability, accuracy, performance, quality, etc, that are imposed on the system as a whole. Therefore, these non-functional requirements must also be known and communicated via a central repository where all teams can readily access them. (Click here for more on non-functional requirements).

These requirements are an adjunct to the Vision and Feature Backlog and are every bit as critical as the functional requirements. As such, Product managers have a major role in defining them. Your enterprise development practices may now be more lightweight and agile, but the system still has to work when you ship it!


That’s it for the first responsibility: Owning the Vision and release Backlog. We’ll move on to Responsibility 2: Managing Release Content, in the next post.

New roadmaps, more flexible boards, and dozens of new integrations. And that's just the beginning.  


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}