In a recent post, Saeed Khan wrote that the Scrum role of “Product Owner” should be redefined to describe a more accurate set of responsibilities: “Backlog Manager.”

Saeed’s argument is that the Product Owner role is really a project-specific role implemented within the Agile movement as a solution to inaccessible product management.  Saeed observes that more and more product management responsibility is bleeding into the Product Owner role, which is intended to be the funnel of business input to the development team.  This conflicts with the primary responsibility of the role, which is to provide a set of fully groomed user stories representing the next most important features that should be built, and to be available throughout the sprint to answer questions.

After considering this since Saeed’s post, and based on my own experiences on four scrum projects, I’ve come here to propose that there is a “best case” condition under which this arrangement makes sense, and several others under which it doesn’t quite work.

 

The Case where a Backlog Manager makes sense

The first thing to remember is that Scrum has infiltrated software development from the custom software world.  When building custom software, there is a single customer whose wants and needs are primary — and time has shown that having a representative of the customer in the war room at all times can help the development team deliver something meeting the customer’s needs in an efficient manner.  In this context, because the Product Owner is often an employee of the client who has broad and wide domain knowledge, it makes sense that a single person bears all the responsibility of the product–and it makes sense that a single person can deliver it!  This set of conditions does not demand that we separate the tactical “product owner” responsibilities from the business “product management” responsibilities because they are so intricately tied together–and the product is being built for one customer!

When we look at independent software vendors, however, we encounter the difficulties with balancing the strategic and tactical that many Product Managers express.   A product manager must synthesize the needs of a market segment to deliver a compelling offering, and successfully prepare it to be marketed to that segment.  If the Product Manager (title) occupies the role of Product Owner, spending much of his/her time on tactical items for upcoming sprints, the pattern seems to be that access to the market is less common.

It is at this point that the notion of “Time” becomes important.  I believe the tactial responsibilities of backlog management can be offloaded by a Product Manager to someone filling the role of Product Owner (a Technical Product Manager, a Business Analyst, etc) under one condition: After a product’s initial release to the market.

In my ideal process, before starting construction of a new product, the Product Manager will spend significant time in the market understanding the problem space, developing business case and initial requirements, to the degree that he/she is prepared to spend a number of months focusing on development.  It is only with this focus that a clear vision of the product can be brought to the team and shepherded to completion.

Backlog management will take a great deal of time, but the product manager’s command of the entire product is essential to having it built correctly.  With a competent team, the Product Manager serving as Product Owner can still find time to make periodic visits to customers to get feedback on early builds and gain the input needed to “inspect and adapt.”  But if this feedback only reaches the team second hand, the risk to the cohesiveness of the product is too high.

After version 1.0 of a new product, when the product is in customers’ hands and is being considered by prospects, the vision, business case and purpose of the product is already established.  Now that the product is built, the product manager is looking for additional market segments and business opportunities, finding the problems which adding solutions into the product would open up new markets.  Additional important and complex features may be added, but the basic nature of the product is already set.  Given this stability, the profitability of this product can be managed by one individual, while the tactical implementation of new features can be efficiently offloaded to another.   This is the case where separating responsibility between a Product Manager and a Product Owner makes sense.

These three statements summarize my position:

  • For custom software vendors, there really is a single “product owner” that fits with Scrum orthodoxy.  This “Product Owner” is a representative of the customer.
  • For ISVs developing version 1 of an off the shelf product, a single person should own the business and technical sides of the product.  That single person learns the market and helps build the right solution.
  • For ISVs developing later releases of an off the shelf product, the backlog management responsibilities can be split from P&L / business responsibilities.  The boundaries are set, and a “backlog manager” or “technical product manager” can work with the Product Manager to understand the goals of the next release and execute, while the product manager coordinates sales, channels, support, and other arms of the company.

Special Note: During the development of a Version 1.0 release, because it makes sense to have the single person with best understanding of the business case overseeing the development effort, in most cases it does NOT make sense to have one person overseeing the buildout of more than one product!  The workload to understand business needs, positioning, usability needs, requirements and user stories, and implementation details is too great to split that person’s time into multiple threads.  I can confirm this from personal experience!