Product Owner, Product Manager, or Project Owner?

If you really want to get the benefit of Scrum, you have to make the mind shift to product ownership, not project management or project ownership. The product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer.

I’m always speaking to people who use Scrum as a type of project management. A product backlog is used as a list of to-do items, and when those items are done, the project is complete.

But if you really want to get the benefit of Scrum, you have to make the mind shift to product ownership, not project management or project ownership. Even with organizations that follow agile software development principles well, the product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer.

Product ownership, at the heart of Scrum, infers a large sphere of influence and responsibility. The product owner has to consider the product for its lifetime, not just for the next short win. A project owner would look at tradeoffs in time and product quality in a considerably different light, possibly sacrificing long-term gains for short-term wins. Project ownership can lead to a “let’s get it in right now and we’ll fix it later” mentality. Product ownership takes a longer-term vision of the product, and while trade-offs between time and quality can be made with good product ownership, such a trade-off is more likely not done by pushing off the consequences of short-term fixes to the next project.

Product ownership can still provide short-term gains, but it’s not as likely to sacrifice quality at the cost of time by stringing releases together to move toward a long-term goal. A product owner has a lot more involvement and a lot more authority.

Product owners are often misunderstood as people who simply specify requirements. The effectiveness of the product owner is directly related to the product owner’s authority, vision, understanding, and commitment to the product. That’s not to say that product owners will not write requirements, but that is not their primary responsibility; requirements are, after all, merely a way to communicate need. The primary responsibility is to maximize the return on investment on the product by communicating, via conversations and the product backlog, what needs to be created and in what sequence.

I once worked with a product owner, Jean, who was a very kind person. She was an expert in her field with an advanced degree in the domain. Unfortunately, she had a hard time saying no. As she was walking to the sprint planning meeting, people would stop her in the hall and say, “Hey, Jean, can you put this change into the upcoming sprint?” Did I mention Jean was nice? She would accommodate these people without having the time to develop a strategy, and the development team would get half-baked items in the backlog that we couldn’t act on. Eventually Jean was removed from the product owner role.

The most effective type of product owner goes well beyond what Scrum requires and into the realm of product management. Product management is about the entire lifecycle product, not only from an IT side, but also marketing, product conceptualization, customer satisfaction—the big picture. The product manager focuses on the product’s concept, feasibility, definition, creation, launch, growth, decline, and, ultimately, retirement. Scrum narrows the focus to product definition, creation, launch, and particularly growth. A good product owner maximizes value by looking to squeeze the best return on investment out of the product backlog. Beyond that, a great product owner maximizes the value of the product over its lifetime and has a long-term vision.

Product Owner Continuum

Moving to product ownership is as much a cultural transition as many of the other changes in agile software development. A product owner can have multiple levels of effectiveness based on his or her behavior.

First of all, if you don’t have a named, dedicated product owner, you are simply not doing Scrum. Once you start using Scrum, the typical but least effective type of product owner is simply a business analyst who gathers requirements, puts them into a backlog, and has a minimal amount of authority. While this is better than no product whatsoever, the product owner role can be much more effective with more knowledge, buy-in, and authority.

I once worked with an insurance industry group that had three product owners for a single backlog. That was a problem. One person was a personal lines analyst, one was an auto lines analyst, and one was the VP of claims. The three worked together, but every time there was a meeting or some issue to be discussed, it required coordinating with all three and a long-term discussion. After working with the group to reduce this problem, we settled on a single product owner: the personal lines analyst. This was much more effective, even though the analyst was at a lower level than the VP. The new product owner was able to streamline decisions and meetings while still collaborating heavily with the other business people. She became a true product owner by making decisions and taking ownership.

A product owner that’s a proxy for the business—somebody intimately involved with the business itself, directly using the product every day—is more effective than a business analyst due to their knowledge, but they may run the risk of not having enough authority to shepherd the product throughout its life.

If you want to move to a new level of performance, the product owner should not only be a proxy for the business, but someone from the business. This type of person brings more in-depth knowledge of the product, and with that, more in depth knowledge more authority in making informed decisions. A person from the business may have more political power and authority with the stakeholders than an outsider and can ultimately be a more effective product owner because of their experience with the product.

Even more effective is a business person with a mandate from the executives—the authority to run with the product. Somebody with a mandate has a distinct goal of bettering the product, not just a side job to work on the product. Not only do they have authority and knowledge, but they also have the drive to build a higher-quality product and evolve that product over time.

The most effective type of product owner acts like a mini CEO, controlling the finances, guiding the direction of the product, having the authority, and caring for the product from cradle to grave.

The most effective type of product owner acts like a mini CEO

As you can see, product ownership is not a role of authority, but a role that is actively involved in the product lifecycle. It takes time and effort. Without authority, knowledge, and long-term thinking—total cost of ownership—product ownership can devolve into a series of project ownership efforts.

I once worked for a consulting company that created a tremendous bid for a government project. It included cloud hosting, hardware, software, maintenance—the whole ball of wax. The bid alone was over two months of work. Shortly before the bid was turned over, the chief sales person cut the cost of bid by 20 percent without consulting those who developed the bid or reducing any scope. The bid won the job. The salesman got a huge bonus and moved on to the next sales opportunity, and the technical people were left holding the bag before the project even started. This was short-term thinking at its worst. Fortunately, it turned out well because the government had a budget cut and the project was canceled.

Think about your product owner role. Can you become a more effective product owner and make the mind shift to product rather than project? Can you become more empowered as a product owner and take more control? With a concerted effort, it’s possible. Just keep in mind that it will take time.

User Comments

Greg Fabian's picture

Should the product owner to also be the lead for operating and maintaining the product once it goes live?  I've worked with a couple of product owners that don't have the slightest idea how to prepare an organization for transitioning to a new system, much less how to support the end users in its use.

August 27, 2015 - 10:20pm
Robert Legatie's picture

Depends on the company.  I say yes.  Once I deploy a feature I tend to work with analytics to see how it performs and depending on the results I'll consider improvements.  If I see opportunities to improve I'll do the research and pitch it to the Product Mgmt team.

August 28, 2015 - 5:01pm
Charles Suscheck's picture

"Should the product owner to also be the lead for operating and maintaining the product once it goes live?"

If the product owner doens't have the ability, skill, and/or authority to have a whole life view  of the product, you run the risk of the product owner having a short term mindset.  Of course not all product owners can own the whole life cycle, so it's a risk you'll have to be prepared for.  Ultimately it's a trade just off not a binary decision.

August 28, 2015 - 10:40am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.