Agile/Scrum and Product Management (part 3a)


Chris posted the following comment to Part 3 of this series.

Look forward to pt. 4, because so far pt. 3 has done little to bring clarity to the issue. For example, in pt. 1 your Scrum definition calls the Product Owner the “voice of the customer,” but that’s exactly what the Cranky PM says the Product Manager should be. So which is it? To those of us trying to, hoping to, move to a more agile process, this type of contradictory advice is paralyzing.

One suggestion I saw that seemed to make sense is having an assoc. PM take on the product owner role. I like that, but it implies that the product owner comes from the product (business) team, not the engineering/tech team. Jennifer Fawcett, on the other hand, recommends the product owner come from engineering. Again, contradictory advice.

I know that each organization is different, and that there are no set rules, but after spending the last hour reading through your posts and replies, I’m more confused than I was before, and still not convinced that the product manager/owner aren’t one in the same.

Point taken. That’s what happens when you write a multi-part series with large lapses of time between each part. You forget that what you wrote in previous parts may not be as clear as you thought when you wrote them.

So before getting to part 4 (it’s coming soon, I promise), I want to address the comment above and make sure others are not seeing a similarly confusing message as they read the various parts one after another.

One point of confusion in the article above is the definition used for Product Owner in part 1.

The definition I gave:

The Product Owner represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, then places them in the Product Backlog.

is not my definition but the standard Scrum definition, and goes to the heart of the confusion of whether a Product Manager can/should also be the Product Owner. In this case, the definition came from the Scrum(development) page on Wikipedia. The same Wikipedia page has (at least at the time I’m writing this) another definition of Product Owner that reads:

Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders

This is a little more generic definition than the first, as it does not explicitly reference “customer”.

If I could make changes, I’d do two things:

  1. Change the name from Product Owner to Iteration Manager, Requirements Manager, Requirements Analyst (or something similar)
  2. Define the role as: “The person responsible for ensuring that iterations focus on delivering on the priorities and objectives as defined by the customer or customer advocate. The Product Owner is responsible for Scrum related artifacts such as User Stories, Epics and prioritizing the Product Backlog during each release cycle.

This does two things. By changing the name of the role, it removes any ambiguity about the scope of the role and the focus of the person in it. It also clarifies the relationship between this role and that of the “voice of the customer”, or as I call it the “customer advocate”. (i.e. the customer, the Product Manager or other similar entity).

The folks at Enthiosys have recently posted an article on this topic and use the following diagram to indicate the activities the “Product Owner” is responsible for.

(click to enlarge)

As you can see from the diagram, the scope is VERY narrow and the focus is on  inbound development planning activities. In their article, they also state:

The Product Owner addresses Agile development teams’ intense need for real-time input on user stories, user interface design, and requirements when Agile Product Managers are inevitably away from their desks.

Enthiosys, like other people I referenced in part 3, state that the two roles should be filled by different individuals. The Product Manager is the voice of the customer (I agree with Cranky here), and in a prelude to part 4, I’ll say that I agree with Jennifer Fawcett that the Product Owner should be from Engineering.

Hope that helps clarify any confusion my previous posts may have caused.

Coming soon — part 4 — where the “Product Owner” should sit, and whether there is such as thing as an “Agile Product Manager”.

Saeed

Agile/Scrum and Product Management (part 3)

Agile/Scrum and Product Management (part 2)

Agile/Scrum and Product Management (part 1)

Advertisements

8 responses to “Agile/Scrum and Product Management (part 3a)

  1. Pingback: Agile/Scrum Software Development and Product Management « On Product Management

  2. It is very very confusing. We need more roles for the Agile approach. Can I say that this is a disaventage of the Agile approach becasue the team grows bigger and it would be more difficut to communicate effectively and owners and managers. Are their indenpendent like shareholders vs executives in a trading company.

  3. The crunch is when there’s not enough money (or staff or attention) to have both a Product Manager and a Product Owner. Fine to segment roles, but having only a PO and no PM is (IMHO) a recipe for very bad outcomes, especially when a sales & marketing team is assigned to bring in revenue based on the result. PO is narrowly defined by the Dev organization…

  4. Rich

    For ISVs, not having Product Management (or at minimum someone filling in for that function) for any extended period of time is the kiss of death regardless of the development methodology. PO is a Scrum construct and should be staffed independently.

    In all but the smallest companies, there should be no excuse not to have both. People will hire developers regularly but don’t always think about the surrounding functions that need to be staffed appropriately to ensure the developers are focused on optimal tasks.

    Saeed

  5. My concern with the Product Owner being part of the Development group is that there may be too much pressure on them to make decisions that are best for the schedule/easier for the developer or more fun for the developer – and not what is best for the customer or the market. Their allegances could lie more towards Development and the person that manages them – not necessarily the product.

  6. Pingback: Agile/Scrum and Product Management (part 4) « On Product Management

  7. Pingback: The Cranky Product Manager never fails to disappoint, plus a blog you should read | The Cranky Product Manager

  8. Pingback: Happy (belated) birthday to us (again)! « On Product Management