Agile/Scrum and Product Management (part 4)


So, here it is, finally, part 4 of this series. Sorry for the gap since part 3 (and 3a), but work and life have a habit of keeping me busy.

In this post, I’ll discuss where I think the Product Owner should reside in the organization, and some of the issues to consider when making that decision.

As discussed in part 3, and so well illustrated by Dean Leffingwell, the table below lays out the differences between a Product Manager and a Product Owner.

Product Manager vs. Product Owner

So where does the Product Owner role belong. Well, the answer is…. “it depends”.

The Product Owner is part of the Scrum team, and as I’ve said many times, Scrum is a DEVELOPMENT methodology, and thus, in general, the role should be part of the Development organization.

This does NOT mean that Product Management does not communicate with the Scrum team at all. What it does mean is that the Product Owner must be customer-centric enough and have enough understanding of the requirements to help the development team efficiently work through day to day issues when implementing well defined stories.

The Product Owner lives with the Development team. The Product Manager works with the Development team, but also with other teams such as sales, marketing, support, finance etc. Thus it is really not practical to make the PM also the PO, given the nature of the role.

Earlier I said, “in general” the role should be part of the Development organization. In a healthy and mature development culture, it should reside there. But as we know 🙂 , many development organizations are neither healthy nor mature.  If that is the case, you or the management team in your company need to decide how best to accomodate that role. Perhaps Product Management needs to take charge of the Product Owner role. Maybe some Development teams need someone from outside the org and others don’t. Does Product Management have the bandwidth or the skillset to take on that role?

There are a number of questions that need to be thought through. The end goal needs to be how best to keep the development teams effectively aligned with requirements and customer/market needs. Find the right people for the role(s) of Product Owner and ensure they clearly understand the objectives, and put them in the right place in the organization to maximize their potential for success.

Rich Mirinov stated in a comment on a previous post:

The crunch is when there’s not enough money (or staff or attention) to have both a Product Manager and a Product Owner.

If the company decides to adopt Scrum, then the company must acknowledge the requirements it puts on the development team and staff accordingly. If the company is not willing to do that, then they should wait until they can staff it properly, or understand the trade-off that they will need to make.

If the PM takes on the role of PO as well, the company MUST acknowledge the dual role, and not be surprised when the next set of product requirements doesn’t come out in time, or is deficient.

Steve wrote:

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 allegiances could lie more towards Development and the person that manages them – not necessarily the product.

The ROLE of the Product Owner in Scrum, is to be the “voice of the customer”. That is fundamental to the methodology. If the PO does what is in the developers’ best interests and NOT the customers’ interests, then the PO is not doing their job, plain and simple. It then becomes a management issue to resolve. The VP of Engineering or whomever is in charge, needs to be mature enough to ensure that people in the Engineering org do their job. If that’s not the case, the problems have nothing to do with Scrum or the Product Owner. As mentioned in a previous post:

Scrum is not a panacea for organizational issues

Finally, here’s what I find strange. Before Scrum, Development Managers, UI and Interaction Designers, Developers, Architects etc. were empowered to make tactical implementation decisions.  They were also tasked with the responsibility to escalate issues that could result in not meeting requirements. There was regular dialogue (at least in the companies I worked in) between Development and Product Management via status meetings, functional and design spec reviews, UI reviews, feature complete reviews etc.

Now with Scrum, people seem to have suddenly forgotten all that, and feel that the Product Manager needs to be involved in all decisions and that the various touch points that existed previously are no longer needed.

Spec review? Who writes specs in Agile? Remember that line from the manifesto? Working software over comprehensive documentation.

Reality check folks. Hate to tell you this, but Engineering is NOT the center of the universe, and just because they’ve adopted Agile/Scrum, it doesn’t mean the rest of the company should suddenly bend itself to accommodate. Engineering needs to work within the context of the business, and not the other way around.

And Product Management needs to have a backbone and stand up for what is right and best for the products and the business.  Wanna really be the CEO of the product? Then ask yourself, what CEO would define his or her business based on the current methodology used by any functional team?

Saeed

Advertisements

9 responses to “Agile/Scrum and Product Management (part 4)

  1. Saeed,

    This has been a great series of blogs. Thank you very much. Very timely for our organization as we struggle with the move to Agile. I am definately going to point my Development team and my management to these blog posts.

    It is very true in our organization where Development appears to want everyone else to adapt to Agile.

  2. Steve,

    Thanks, and I’m glad you found the info helpful.

    Saeed

  3. Saeed,

    There’s much to agree with in here, so I’ll focus my comments on where I see things a little differently:

    – Scrum’s key value is most definitely NOT in its definition of roles to support a development methodology. Its genius is giving all of us business veterans a lighter, more realistic project management framework that recognizes results improve when you break large, long projects into short iterations that inspect and adapt along the way. This adaptive approach works equally well for planning a tradeshow, writing a whitepaper or burning down your backlog of sales tools.

    Dean Leffingwell says it best in his “CIO Playbook:”

    Know where you are every day with Scrum
    – or –
    Think you know where you are on your well-formed plan
    and discover that you are very wrong, very much later

    – Given adaptive management approaches are better than predictive methods whenever you have unknowns, the rest of the business absolutely needs to “bend and accommodate.” If development is finally able to deliver customer value faster, what is preventing your company from experiencing the revenue gains? Is it because Marketing can’t adapt to the new pace? Support? Sales? A lame install & update process?

    Put it another way, if your #1 competitor is consistently delivering new features in half the time you are, how long do you think that is tenable?

    Agile may have started out as being about development, but it’s quickly becoming about the whole enterprise.

  4. Loved this series and have been pointing folks to it quite a bit over the past couple of weeks. Thanks for sharing!
    April

  5. Thanks April.

    Keep up the posting frequency on your blog as well. Lots of good content related to Marketing.

    Saeed

  6. Pingback: The value of Scrum « On Product Management

  7. Hi Saeed,
    Wonderful series, and like Richard’s comment, there is much to agree with. One imporant thing that I didn’t see mentioned is the context in which Agile was created, which was *internal* IT focus. Not commercial software development. Thus, the Product Owner was a very good title and role to add to the team – a subject matter expert on the problem to be solved.

    In commercial software, *sometimes* the product manager is the subject matter expert, and sometimes they’re really great business people, Marketers (in the 4-Ps sense) and “voice of the customerS” (capital ‘S’ intentional).

    For internal IT application development, the Product Owner represents an internal “customer” with a consistent process and infrastructure as a target.

    For commercial software, the Product Manager represents THE MARKET – both current customers and potential new customers – and the variety of business processes, preferences, and infrastructures that implies.

    As Rich says at Enthiosys, sometimes you can have a PM that is also a PO, but sometimes you can’t. Educating our Engineering teams on product management is an ongoing process, and one that takes on additional importance now. We have to help them, and the rest of our organization, understand how to apply Agile methods to commercial software development.

    -Linda

  8. Hi Linda,

    My primary focus is on ISVs. I’ve not worked within internal IT organizations. In that context, before Scrum, a Business Analyst or similar role would be responsible for defining requirements and working with Dev to get the application or product completed. Scrum calls that role Product Owner. Now who is the Product Manager in an internal IT org? Does that role equate to the old Business Analyst? Possibly. It seems to me that the role definitions would be simpler in the internal IT world.

    In the end, what will work best is to use some common sense and ensure that the end goals are kept in mind and decisions are made that align to those end goals.

    Saeed

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