I’ve had some recent questions on product and program management at scale, so to address some of them, I’ve decided to push this early draft Chapter out for review and comments. It’s available at the book resource tab, too.
Category Archives: Agile Product Manager
Agile Product Owner Chapter
Since the agile product manager/product owner topics get a lot of interest on the blog, I thought I’d push this Chapter out for review. It’s available at the book resource tab, too.
A Contemporary Framework for Agile Product Management in the Enterprise
The following article was posted on InformIT yesterday: A Contemporary Framework for Agile Product Management in the Enterprise.
Pieces of it have been spread around this blog before, but this is a fairly standalone piece describing my view of the changing role of the product manager in the agile enteprise.
Agile Product Manager in the Enterprise (6): Responsibility 4- Build an Effective Product Manager/Product Owner Team
Note: this is the sixth (and probably last) in a series of posts (agile product manager category) 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, and in earlier works, I described a framework for product management along with 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, Responsibility 2 – Manage Release Content, and Responsibility 3 – Maintain the Product Roadmap. In this post, I’ll describe the specifics of Responsibility 4: Build an Effective Product Manager/Product Owner Team.
————–
Building an Effective Product Manager/Product Owner Team
The Big Picture of Enterprise Agility
In the agile enterprise Big Picture, the “steering wheel” that guides the enterprise to its product outcomes is the relationship between the agile Product Owner and Agile Project Manager.
From a reporting standpoint, I’ve often described the most typical relationship between the individuals in these roles as a “fat dotted line”.
Fat Dotted Line Reporting Structure
Product Managers typically (but not always) report into marketing or business; Product Owners typically (but not always) report into development. However, to make the enterprise steering wheel actually work correctly, Product Owners are also honorary members of the Product Management organization from whence they receive overall product direction. In this role, they may also:
- Attend most relevant PM meetings, functions, and planning sessions.
- Receive input with respect to career growth and performance.
Of course, there is a natural tension in this relationship as the needs of the key constituents (development team vs. customers/market) are quite different.
- The Product Managers naturally want more features-more quickly and from a market perspective, there is no upper limit to their demands.
- Product Owners and development teams naturally want that too, but are sensitized to the inevitable technological, architectural and quality constraints endemic to every large scale software application. They will tend to naturally focus on technology, architecture, and refactoring priorities. From an engineering perspective, there may be no upper limit to their demands!
Needed – A Sense of Balance
This natural tension is a direct delegation of the larger business-versus-technology enterprise balancing act:
- If the business (Product Management) solely has its way, it’s likely that expediency of value delivery will rule and technology/product infrastructure investment will get the short stick. After all, what business owner would not want to accelerate value delivery for current customers at every opportunity? When this happens, the product becomes brittle over time, and eventually it is impossible to implement major new features without major refactoring (or worse).
- If technology (Product Owner/team) solely has its way, there can be little doubt that the product will be built on sound (and the latest!) technology without short cuts or quality compromises. But the business value delivery may get the short stick. After all, what technologist wouldn’t want to build the most extensible and reliable platform to support future customer needs? When this happens, the current pace of value delivery may lag other competitors in the marketplace and marketshare will suffer (or worse).
So the best we can do is first recognize and balance these competing interests and occasionally let the balance tip a little this way or that (refactoring vs. new value stories) based on the current business and solution context.
Needed: A Sense of Balance
Perhaps more importantly, this friction is both a necessary and productive facet of the enterprise, for it is in the heat of this natural friction and its constant resource constraints, that the sparks of true innovation and creativity are born.
Write less code-accomplish more!
Ingredients for an Effective Relationship
In earlier posts, Jennifer Fawcett (agileproductowner.com) has commented on how important it is to build an effective relationship amongst these teams. She noted that the essential ingredients for building the ultimate Agile Product Owner/Agile Product Manager team are Collaboration, Partnership and Trust. Together, we provide a few tips for building these essential ingredients:
Collaboration – An addition to the joint, enterprise release planning functions, teams must synchronize and communicate the ever-changing corporate priorities daily. POs should invite PMs to attend daily stand-ups on occasion. Politely insist on attendance at most/all demos. Have an “open door” policy for all development and product management meetings. If one party cannot attend, summarize results in minutes or email. Communicate constantly.
Partnership – Ask each other “How can I help?” Create and participate in after hour events to eliminate any us – vs. – them thinking. Prepare for release planning together. Operate under the “never surprise each other in front of others” rule.
Trust – Trust each other to make the right decisions. When (not if!) your APM/APO partner makes a decision that is opposite of yours, support that decision. Meet your commitments to each other. Teams will recognize that you are both empowered, that you will always act as a team and “cover each other’s backside” and that you can both be trusted with business decisions and authority.
Summary
This concludes this series in the the Role of the Product Manager in the Agile Enterprise. I’m not sure what I’m going to write about next, but I’ll let you know when I figure it out.
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.
Agile Product Manager in the Enterprise (4): Responsibility 2 – Manage Release Content
Note: this is the forth 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 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 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 the last post, I described Responsibility 1- Own the Vision and Release Backlog. In this post, I’ll describe the specifics of Responsibility 2: Manage Release Content.
————–
Managing Release Content
In accordance with the Big Picture model, the Vision for the product is delivered to the market in a stream of continuous and frequent, small releases (typically, every 60-120 days) as figure 1 below shows.
Figure 1 - The Big Picture and it's Agile Release Train
Each release is defined by a fixed date, theme, planned feature set, and fixed quality requirements- scope is the variable. Product Managers deliver the vision to the development teams face-to-face in the periodic Release Planning events.
Release Planning Event
In the Big Picture, all agile teams who build cooperative subsystems operate on a synchronized Agile Release Train model. Periodic release planning is the seminal event that aligns the individual teams to the overall strategy of the enterprise. As such, the Release Planning event is to the enterprise what iteration planning is to the team‒the fixed pacemaker that drives the enterprises delivery cadence. As such, Release Planning is the focus of much preparation, communication, coordination and commitment. Teams whose software must cooperate plan together, and they do so face-to-face, at least so far as travel budgets will allow. (Note: for more on release Planning, click here).
Since the release dates are fixed in advance on the Agile Release Train, Release Planning events are routine and can be pre-scheduled as far as a year in advance. During release planning, team members attend in person if at all possible. During the event:
- Product Management owns the feature priorities
- Development team/product owner owns story planning and high-level estimates
- Architects work as intermediaries for governance, interfaces and dependencies
Preparation for the Release Planning Event
As the Release Planning event is the primary communication and coordination point for product strategy for the upcoming release period, Product Managers should be come well prepared:
- Understand the status of the current (in process) release
- Update the release backlog
- Meet with other business owners and other Product Managers to coordinate initiatives and priorities
- Meet with Product Owners and discuss the preliminary Vision for the upcoming release.
The event is typically a full day minimum, more likely two, and often follows a pattern as illustrated in the two figures below.
Figure 2 - Enterprise Release Planning Day 1
Day 1 is focused on delivery of the Vision, which the Product Managers deliver via whatever medium suits them best, followed by initial planning by the teams.
In most cases, the Vision doesn’t “fit” in the release time frame provided, (after all, what self-respecting product manager would bring less vision than the teams could likely accomplish) and some Day 2 scope management triage and out-of-box thinking is required.
Figure 3 - Enterprise Release Planning Day 2
In any case, Day 2 should bring a commitment to the release objectives for the next release. Even then, the commitment has to be flexible (otherwise you have fixed time-fixed-scope-fixed quality; in other words a short waterfall-constrained release) and many agile teams communicate the feature release priorities on a flexible basis like this:
Figure 4 - Prioritized Release Features
In this manner, the Product Managers control the release content, as well as the delivery priorities. And since teams become far more reliable on their release commitments as they master the new agile paradigm, this gives the product managers and external stakeholders a more certain planning basis on which to make key decisions.
Tracking the Release
All the hard work the enterprise has put into the agile transformation should now start paying dividends. For once a commitment is achieved, the primary responsibility for delivering the release in a series of short iterations lays with the project teams. After all, they write and test all the code, and in agile they are both empowered and accountable to achieve the agreed to objectives.
Even then, however, the agile enterprise recognizes that continuous tradeoffs of changing requirements and scope is inevitable, so the Product Manager also plays a pivotal role in helping the teams meet the release objectives. Doing so requires ongoing tracking and managing of the release and its content. Fortunately, our agile enterprise model is replete with visibility, so understanding the actual vs. planned status of a release is no longer a “crystal ball” activity. Instead, there are four primary mechanisms which help the enterprise and its key product manager stakeholders keep the agile release train on its rails.
#1 – Constant Informal Communication with the Product Owners
The product Manager has a direct liaison to the teams via the team’s Product Owners. The fan-out is not too extreme – a single PM may typically interact with some small number (3-6) of product owners– and thereby have ready status from all the project teams who must collaborate in meeting the release objectives
#2 – Participation in the Release Management Team
In the Scaling Software Agility book and blog, I’ve described a typical construct where development management, agile/ScrumMasters, Product Managers, quality assurance, release managers and other key stakeholders meet weekly to assess the status of a release. This Release Management Team (or RMT) has the primary responsibility for shepherding the release to market. This weekly forum is a key touch point through which Product Managers can assess release status, and adjust scope where necessary.
#3‒Attendance at iteration demos
The inherent visibility of agile development also provides an inherent opportunity to see the working code as it develops. This happens in the context of the iteration (Sprint) review which contains both a product demo and retrospective. The every-other-week product demo is key to the Product Managers insights into status and progress and is a not-to-be missed opportunity to see the product, interact with the teams, provide feedback and make midcourse adjustments where necessary.
#4- Status via agile project management tooling
To have even reached this point, the enterprise will assuredly have rolled out appropriate agile project management tooling which provides support for the higher level status views needed by PMs and other stakeholders. This tooling should provide some form of hierarchical, feature-level burn down so that the PM can assess, on an aggregate basis, exactly where they stand within the release as figure 5 shows:
Figure 5- Release Level Burn Down
This chart provides a sense of the probability of landing the release. However, it doesn’t give any notion of what features may or may not be delivered. For that, the tooling should also provide default reports on the status of each individual feature, perhaps something like figure 6 below.
Figure 6 - Status of Release by Feature
Together, this information should give the RMT and the Product Managers objective knowledge of where they are, and even more importantly, what changes might be necessary to “land” the release on time.
Summary
This concludes the discussion of Agile Product Manager Responsibility 2 – Manage Release Content. In the next post, I’ll describe Responsibility 3 – Maintain the Product Roadmap.
Agile Product Manager in the Enterprise (3): Responsibility 1 -Owning the Vision
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.
(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
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!
Summary
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.
Agile Product Manager in the Enterprise (2): A Contemporary Framework
Note: this is the second post in a series 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 first post, Role of the Product Manager in the Agile Enterprise (1): Phases of Disillusionment in Pre-Agile, Waterfall Development, I described some of the dysfunctional behaviors and mistrust that may be built into our system prior to the agile transition. In this post, we’ll move to a more postive and enlightened view of the changing role of product management.
———–
What’s Different about Product Management in Agile?
In prior posts, we’ve also described how the role needs to change in agile development. Much is different as the table below illustrates.
| PM Responsibility | Traditional |
Agile
|
| Understand customer need | Up front and discontinuous | Constant interaction |
| Document requirements | Fully elaborated in MRD/PRD | Coarsely documented in Vision. Constant verbal communication to team. |
| Scheduling | Plan a one time delivery, way later | Continuous near term roadmap |
| Prioritize requirements | Not at all or one time only in PRD | Reprioritize every release and iteration |
| Validate requirements | Not applicable. QA responsibility | Involved with iterations and each release. Smaller, more frequent releases |
| Manage change | Prohibit change – weekly CCB meetings | Adjust at every release and iteration boundary |
Adapting to all the behaviors in the right column is a substantial change for the newly-agile, enterprise Product Manager and that is the subject of this series of posts.
Functions of Product Management in the Agile Enterprise
In this series, we’ll be describing mostly what’s different with Product management in a pre-and post-agile environment. We won’t be attempting to describe all the behaviors which are common or providing guidance for what product managers do in the traditional software enterprise, Fortunately, many of the product management functions are the same in agile as they are in pre-agile development.
For example, the product managers are still primarily responsible for assessing market needs and creating product strategies (with input from the teams). However, the handoff to R&D highlighted in the last post is strongly mitigated, and the Product Managers take a far more active role throughout the development process.
For a more contemporary view of the comprehensive nature of an effective product management organization, I refer you to the product management framework graphic provided by Zig Zag Marketing below (reproduced with permission, see www.zigzagmarketing.com for more details).
- Figure 1 – Framework for Product Management
It can be seen in Figure 1 that the early product development lifecycle functions (Assessing Markets, Creating a Product Strategy) remain largely the same, but the product management function continues with more direct involvement in R&D throughout the launch cycle. Of course, this framework is from the perspective of professionals in product management and our approach is more nuanced.
The Nuanced, Dual Roles of Agile Product Manager and Agile Product Owner
In various posts described above, I described why, at least in the larger software enterprise, the responsibilities of the agile Product Owner (as primarily defined by Scrum) is more typically a set of responsibilities that are shared between a significant number of team-based, agile Product Owners and a smaller number of program-based, agile Product Managers. This dual role approach is also illustrated in the Big Picture Series and graphic as seen below:
Figure 2 - The Big Picture of Enterprise Agility
Within the context of that picture, the Product Manager operates primarily at the Program and Release level, as this Big Picture snippet indicates.
Figure 3 - Product Manager in the Big Picture
In these various articles and posts, I‘ve highlighted the different responsibilities for these two roles, summarized as follows:
|
Agile Product Manager |
Agile Product Owner |
| Market/customer facing | Product/technology facing |
| Collocated & reports into marketing/business. | Collocated & reports into development/ technology |
| Focuses on market segments, portfolio, ROI | Focuses on product and implementation technology |
| Owns the Vision | Owns the Implementation |
| Drives the Release | Drives the Iteration |
Mapping the Dual Roles onto the Framework
In the context of Zig Zag Marketing’s Product Management Framework, the roles fall fairly nicely into the product lifecycle as can be seen in the figure below.
Figure 4 - Mapping the Dual Roles onto the Framework
In many enterprises, adopting this dual-role model has been integral to an effective agile transition and has enhanced operational performance in both the business and technology. As John Bartleman, VP of Product management and TradeStation Technologies recently noted:
“This separation of labor and concerns (into Product Managers and Product Owners) has helped us bring additional focus to both the market and technical aspects of our solution”.
Product Manager/Business Owner/Business Analyst?
We’ll describe the agile-specific responsibilities of the Agile Product manager in the posts that follows. But first, however, we note that the name of the title of the person who plays this role may vary by industry segment as seen below.
| Industry Segment | Common Title for the Role |
| Information Systems/Information Technology (IS/IT) | Business Owner, Business Analyst, Project or Program Manager |
| Embedded Systems | Product Manager, Project or Program Manager |
| Independent Software Vendor | Product Manager |
Table 1 – Titles for the Role Vary Across Business Segments
Responsibilities of the Agile Product Manager in the Enterprise
No matter the title (we’ll continue to use Product Manager throughout) or the reporting arrangement, when an agile transition is afoot the person playing that role must fulfill the following primary, agile-specific responsibilities:
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
I’ll describe each of these responsibilities in individual posts that follow.
Agile Product Manager in the Enterprise (1): Phases of Disillusionment in Pre-Agile, Waterfall Development.
Note: this is the first post in a series on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a follow on series to the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Owner/Product Manager category as well as in a series published recently in the Agile Journal. (See the resource page for a mapping to the Agile Journal article series).
In this first post, we’ll set the context for need for the transition, and try to shed some light on the Product Manager’s likely perspective on their view of the software development organization prior to the change.
—————————————
Prior to agile, many enterprises have followed a sequential, stage-gated, waterfall development model. In these cases, it’s likely that the Product Manager’s mindset has moved through a series of increasingly foreboding attitudes, as the figure below shows.
Phases of Product Management Disillusionment in Waterfall Development
Phase 1 – Unbridled Enthusiasm
In this phase, the Product Manager spends their time with customers, interviewing, running workshops, and using whatever other tools they have at their disposal to define and document the requirements for the prospective new system. These requirements are typically captured in a MRD (Marketing Requirements Document (MRD) or PRD (Product Requirements document). After that, the development team typically response with a Software Requirements Specification, or (SDS) System Design Specification, which further refines and documents the intent of the PRD.
At the end of this phase, which may take from 3-6 months to document and gain the requisite approvals, the development effort is launched and there is a hand off to engineering.
Phase 2 – False Sense of Security
This initial, upbeat phase is followed by a period of relative calm. I call this the period of a false sense of security. During this phase, development proceeds apace. The product manager may be uninvolved, or may attend milestone reviews where models, documents and project plans are reviewed and inspected. Towards the end of this period, which lasts typically from 6-12 months, the software is declared to be 90% complete and launch plans are put into place. Customers are notified that the release is impending and external and internal commitments are solidified.
Phase 3 – Rude Awakening
Of course as we’ve discussed in the book and blog, the next phase is a painful one indeed. During system integration, many defects are discovered, some design related (think – uh oh, lots of rework…) , and the dreaded defect triage process begins.
Now it is obvious that the schedule will not be met and communication of that prospect begins. Worse, in the early period, the defect “find rate” exceeds the “fix rate” and the schedule becomes less and less certain and product delivery looks further and further out. Even worse, the customer typically now has their first opportunity to see the actual software and they discover that it is not what they currently need. This is because either a) they didn’t know what they wanted back then, or b) their needs have changed in the last year. No matter the cause, substantive, additional rework will be required before it can be deployed.
This a period of substantial pain for the Product Manager and for all key stakeholders in the process.
Phase 4 – Resetting Expectations
Fortunately, we didn’t get this far in the tech industry without most program teams eventually figuring out how to deliver software, so a period of rework and recovery begins. During this period, the scope is typically slashed dramatically, and commitments for schedule and functionality are renegotiated. Of course, credibility has now been lost throughout the enterprise – the development team to its stakeholders – as well as the product managers to their external stakeholders.
Phase 5 – Persistent Mistrust
What follows is a long, persistent period of mistrust between the development and product management organizations, which is often characterized by cross-department hostility, reduced communication and even complete dysfunction.
Worse, as the Product Mangers have learned that they only get about half what they ask for, they often resolve to ask for twice as much next time, to assure that they get something meaningful delivered. And we all know how well that works out. So the vicious cycle continues.
I describe all this, not to further belabor the pain, but simply to point out this may well be the environment when the agile transformation is initiated.
Clearly, this waterfall development model has not served the needs of the Product mangers or other stakeholders particularly well, so at some point, the lucky enterprise commits to a new, agile development paradigm. Often times, the development teams themselves sponsors the agile initiative and delivers a couple of messages to the Product Management organization:
- Message 1 “ We are heading down a new path, and this type of thing won’t happen again”
- Message 2 – “but in order for us to be successful, you’ll need to change many of your behaviors, too”.
- And finally, message 3- “with our new agile model, we are going to stop predicting what will be delivered and when and we don’t really need those Marketing Requirements Documents any more, and we also won’t be creating those software design specs either.”
And now finally, for those developers and managers leading an agile transformation, and in the context of the Phase of Persistent Mistrust, I ask you to perform the following thought experiment.
If you were a Product Manager operating in this environment, how would you react to such a message?
Clearly, we are going to have to approach this change with a more mature thought process and a credible strategy to get these key stakeholders on board with our new model.
Summary
Well, that’s a statement of the problem and that is it for this post. In the next post, I’ll move on to describing a more helpful and enlightened approached to the transition, and to the changing role of the Product Manager in the increasingly agile enterprise. But in this post, I wanted to set the context so we will at least recognize the hole we have likely dug for ourselves in the meantime.
Scaling Software Agility 
