Skip to main content

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.


Scott Sehlhorst said…
Great article - and I think your "imagine you disagree with the designer" example really crystallizes the ownership labeling issue.

Either you "own" the product or you don't.

I do, personally, like the notion of personal accountability - I personally feel accountable for the success of my products, even if I don't "own" all of the decisions. Everyone on the team can feel this way - and you're right, wow does it make a difference when they do.

Really great points here. I think I'm done using the "president of the product" phrase too.
Larry said…
Thanks for this timely post Roger. Many points in here struck a chord with me and my new PM gig at a new company. I have found that each member of the team has strengths and plays roles that contribute to the team effort, and ultimately to market acceptance and product profits. They all feel visibly accountable for the success of the product and the team. As such, each is continuously looking for ways to improve both the product and the process surrounding its development. To this end, the company has a great vibe and is doing reasonably well.

The other nice part of team effort is the coverage that occurs. There isn't the finger pointing and saying it's not my job. Someone realizes the need and picks up the slack. It is team ownership.
Samantha said…
Great article!
I just want to clarify for myself what exactly you mean by "marketing principles" in "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".
Roger L. Cauvin said…
Thanks for the question, Samantha.

I use the term "marketing principle" to refer to a universal principle that guides strategy for any product or brand. These marketing principles are often counter-intuitive.

The best reference I've seen for these principles is The 22 Immutable Laws of Marketing, by Al Ries and Jack Trout.
Teresa Torres said…
The design example is a great one. One person, whether it's a product manager or a CEO, shouldn't "own" the product. The team owns the product.

I've found the more I let go of the "decider" mental model of product management and let the rest of the team into the decision making process, the better and better our product gets.
Roger L. Cauvin said…
Thanks for stating things so clearly and concisely, Teresa. I like the "decider" label. Definitely something a product manager should strive not to be.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Is Customer Development Pseudoscience?

The “Science” of Lean Startup Lean startup practitioners embrace the scientific method, seeking the "truth" about what business model and strategy will lead to product success. We do so by: Formulating hypotheses Crafting and running experiments to test them Learning from the experiments Iteratively feeding our learnings back into revised hypotheses Sounds pretty scientific, at least in spirit, doesn't it? Yet this process actually neglects a key ingredient in the scientists' mode of operation. To identify what’s missing, let’s examine “customer development”. Customer Development Steve Blank is one of the pioneers of the lean startup movement. He introduced into the lean startup lexicon the term “customer development”. Customer development consists of sessions and interactions with customers to test hypotheses. For example, a product manager might interview a prospect, asking if she agrees with the product manager’s hypotheses about the problem