Monday, December 05, 2011

Who "Owns" the Product?

Recently, I've noticed a number of product managers on social channels claim that product managers "own" the products they manage.  On the surface, this claim seems rather innocuous and uncontroversial.  But the claim bothers me, for several reasons.

Let's examine why anyone would make such a claim.  I can think of a few reasons.  (I'll get to the notion of "product owner" in agile development later.)

First, a single point of accountability simplifies how we conceptualize the product management role.  It's understandable that product managers are tempted to find a simple definition of product management.  The responsibilities of the role vary greatly across different companies, and few people can articulate concisely what a product manager is or does.  So it's nice to boil it down to ownership of the product.  But what does it really mean to own the product?

Second, many folks in the product management community are familiar with the debate about product management "authority".  Product managers typically lack formal authority but assume much of the responsibility for the output of the product team and for the ultimate success of the product.  Perhaps some product managers believe that, if we convince executives and team members that we "own" the products we manage, they will grant us the authority to make product decisions that stick.

For example, if the product manager disagrees with a user experience (UX) designer on the team about a design decision, the product manager can "overrule" the UX designer's recommended approach, since somehow the product manager's ownership of the product trumps the UX designer's design expertise.  I don't subscribe to this authority-based model, and I doubt product "ownership" does much to support it in practice.

Third, the other side of the product management "authority" debate believes in the romantic notion of leadership as unilateral self-empowerment with little or no enablement from others.  Under this view, product "ownership" implies that the product manager steps up to take full responsibility and accountability for the success of the product despite the lack of formal authority.  It's a statement of confidence and sometimes derision towards those who complain about the lack of formal authority.  Yet this view rests on a naive and overly simplistic view of leadership, as I have argued before.

But the practical reason you should reject the notion of product management "owning" the product is that it undermines one of the key determinants of product success.  The most successful product teams possess a culture in which the team owns the product.  Each member of the team - whether a developer, sales person, marketer, support specialist, or tester - has strengths and plays roles that contribute to the team effort, and ultimately to market acceptance and product profits.  They all feel accountable for the success of the product and the team, and there is no need for a "single throat to choke".  This form of accountability is a highly effective motivator and yields impressive productivity and outcomes.

A product manager's unique role on a team is informing the strategy that drives all the team's product decisions.  She does so by leading the process of eliciting and sharing market knowledge and applying marketing principles to form the basis for sound product decisions.

Finally, no discussion of "product ownership" would be complete without a note about the use of the term "product owner" in agile development.  The original use of the term referred to a person on the team who could serve as a proxy to the customer or market.  It wasn't someone who was solely responsible or accountable for the success of the product or project.  Originally, it wasn't even someone who necessarily had tactical "backlog management" responsibilities.  No, it was mostly a role that helped inform the team's requirements decisions from a customer and user perspective.

A product manager's role is a bit broader than agile's original notion of product owner, in that a product manager's insights and perspectives drive not just requirements, but positioning and messaging as well.