Agile, Product Management

The Scrum Product Owner as Backlog Manager

The Case where a Backlog Manager makes sense

The Case where a Backlog Manager makes sense

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.” This would be a role that teams up with a market facing Product Manager to lead the team.

This post is one in a series on B2B Agile Product Management. When you’re done with this post, read about the B2B Agile Product Owner.

Saeed has a point.  In agile product companies, the Product Owner role is really a development-focused role implemented within the Agile movement as a solution to inaccessible product management.

Saeed observes that more and more product management responsibility is being absorbed by the Product Owner role. This overloads the responsibility of the Product Owner, which exists primarily to provide a set of fully groomed user stories representing the next most important features that should be built.

The Product Owner, in the Scrum orthodoxy, is expected 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’m firmer in my belief that there is a “best case” condition under which the product manager / product owner pair makes sense, and several others under which it doesn’t quite work.

The Case where a separate Product Owner (“backlog manager”) fits best

When does a Product Owner and Product Manager pair make sense?

The first thing to remember is that Scrum is a construct borrowed from the custom software world. When building custom software, there is a single actual customer whose needs are driving the development effort. Time has shown that having a representative of the customer working with the team at all times increases the team’s odds of success.

This scenario involves a single customer, not a market of customers; therefore, one person really does know best.

In the world of independent software vendors, however, product managers synthesize the needs of an entire market segment (or segments) to deliver a compelling offering, and market the product that segment.

That’s a lot of customers to talk to and to undrestand.

When the Product Manager occupies the role of Product Owner on the development team, splitting time between strategic marketing and tactical development items, both parts of the job suffer.

The tactical 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.

A Single Product Owner is Essential Prior to Market Release

Before starting development 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 some amount of time focusing on development of the first release.

If approached with lean principles, the Product Manager has to stay closely in tune with development and with customers to drive successful experiments via the MVP.

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 consumes significant attention, but the product manager’s command of the “whole product” and the market is essential to having it built correctly.

With a competent team, the Product Manager serving as Product Owner can still find time to make regular visits and calls to customers to get feedback on early builds, and gain the input needed to “inspect and adapt.” If this feedback only reaches the team second hand, the risk to the cohesiveness of the product and product/market fit is too high.

But then, the world changes.

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 there are customer requests and production bugs to balance, not to mention implementation and support needs to address. There are RFPs to respond to, and deals to sign.

RELATED:  Peltier's Product Digest #1

In my experience, having paying customers can add 50% or more to the workload of a Product Manager.

Meanwhile, the product manager is looking for additional market segments and business opportunities. The product manager’s focus turns to which new problems can be solved by the product to better satisfy current clients, and to open up new markets.

But wait–what are the acceptance criteria for the story in development? That feature was designed six months ago and the Product Manager has long moved on. Context shift!

With a product in the wild, others in the organization grok it. Sales knows the basic value proposition. Marketing knows how to talk about it. Success knows how to implement and support it.

With this knowledge as a starting point, once the Product Manager identifies the most important problems to be solved, implementation of those solutions are better offloaded to another person.

This allows the Product Manager to focus on the business success of the product. The Product Owner can focus on driving successful implementation of the current “most important” problem.

This is the scenario in which separating responsibility between a Product Manager and a Product Owner makes sense.

These statements summarize the position:

  • For custom software vendors developing the first (or subsequent) versions of a product, there really is a single “Product Owner” that fits with Scrum orthodoxy. There is no “Product Manager” in this scenario representing a market of customers. This “Product Owner” is a representative of the single 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, and is the true Product Manager serving as an agile Product Owner with engineering.
  • 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. That backlog manager is most commonly known as a “Product Owner.”

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!

5 Comments

  1. Could not agree more. As coming from the Product Management world in an ISV I see the problem and with your post I got a greater understanding of why some people dont get what I mean. With a customer development world we just dont have the regular product management and all my views are no longer applicable. I never thought of that difference

  2. Jon White

    One more point on the above (no comment edits?):

    A good BM can handle more than one product consecutively.

  3. Jon White

    I think you have hit the nail on the head here. For v1, market research and development are consecutive activities, where as once a product is in market, they become parallel. It is a risk for any business to expect one person to be able to do both well. Add in the operational side of product management and you have a very strong case for delegating one of those 3 tasks.

    We have just created the concept of a Release Manager which is analogous to a BM in your post. This provides some nice thinking on when the BM role applies.

  4. theprodmgr

    Very interesting post. I would argue that the concept of Product Manager really doesn’t exist in the Custom Software environment. As you stated, you really just need someone who can effectively communicate what the ONE customer wants. They aren’t out listening to the market etc.

    In an ISV, my personal experience is that the Product Owner role can be filled by a qualified Business Analyst both for V1 and subsequent releases. This person has to work closely with the Product Manager, but once the initial set of “deliverables” have been defined, the BA (as the PO) can take over and work closely with the Development team. This means though that they have to know what the vision is for the product, understand the market it serves and the problems it solves.

    I think regardless of V1 or future releases, the Product Manager does need to be involved and check in to make sure that things progress as they expect. They are also the escalation point for when the PO can’t resolve a question.

  5. David Locke

    Your conception of the PM vs PO vs BM works wonderfully in the technology adoption lifecycle where a vendor does custom development, and then moves the product to the vertical market of which the B2B early adopter, the client, is a part. Once you start crossing the chasm, you shift from the BM to the PO. Thanks.

Leave a Reply

Theme by Anders Norén

GET MY B2B PRODUCT NEWSLETTER TO CRUSH PRODUCT.
x

Get the B2B Product Newsletter to Master Your Craft

Join over 300 product managers sharpening the saw.

%d bloggers like this:
Read previous post:
Lessons from ‘Crossing the Chasm’

Crossing the Chasm by Geoffrey Moore is a classic reference book for marketers of technology products.  As a review, there...

Close