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