Product Owner vs Product Manager

Last post we explored what roles fit nicely in our existing Scrum roles. We also identified a few that didn’t. We explored the role of ScrumMaster and Team and talked about which roles seemed to make sense in a Scrum context. Today we’ll take a look at the role of Product Owner (vs Product Manager) and see if we can find a home for a few of the others.

Most teams start with the assumption that the Product Owner role should be filled by the Product Manager. I think that is a reasonable starting point but let’s look at how Wikipedia defines the role of a Software Product Manager:

A Software Product Manager is responsible for researching, selecting, developing, and placing a company’s products. This role considers numerous factors such as target demographics, competition, and how well the product fits in with the company’s business model. A software product manager takes this high level understanding of market needs and translates these needs into Product Requirements Documents and Software Requirements Specifications. Product Managers ensure that the resulting product is deployed successfully and meets the initial specifications.

That captures some of what a Product Owner does, but probably not everything. Jack Milunsky posted a nice summary last week of the Top 10 Activities of the Product Owner over on Agile Software Development. I don’t want to rehash Jack’s post here so I recommend you hop over and take a look at that post if you need a refresher. I trust that many of my readers probably have this idea under control ;-)

When you look at all the things an agile Product Owner is doing for the team you see pretty quickly that the role of Product Owner is really much, much more than that of a traditional Product Manager. From the development teams perspective, the Product Owner has responsibility for everything from executive sponsorship to planning and scheduling. They are responsible for managing expectations, status reporting, requirements definition, and even quality and user acceptance. To quote the Scrum guys, they are the Single Wringable Neck.

That is quite a bit of responsibility for one person… for one role… on an agile project. Is it possible that we have found where Scrum put all our missing roles?

Product Owner as Project Manager

Much of what we think of as Project Management is actually assigned to the Product Owner in Scrum. They are responsible for assessing the needs of the project stakeholders and making sure those needs are documented, prioritized, and communicated effectively to the team. The Product Owner is responsible for identifying and managing tradeoffs to deliver the release within the time, cost, and scope expectations defined by the business. All pretty straightforward Project Manager stuff.

Product Owner as Analyst

The Product Owner role is expected to translate requirements, much like a traditional business analyst or designer, into language that a developer is going to understand and can build into the product. They work daily with the team to explain and clarify their emerging understanding of the requirements. They make sure the requirements meet acceptance criteria and get to decide ultimately if features are ready for release.

This sounds a whole lot like why we had Systems Analysts and Business Analysts in the first place? Is it possible that the user experience and user interface should be designed by the Product Owner as well? If not the Product Owner, who else?

NOTE: For a really cool treatment of this topic by a true expert, take a look at Jeff Patton’s recent post on called the Product Owner and the Product Shaped Hole. Jeff touches on a few themes I am exploring here but I have no idea if he would agree with where I am going in this post.

Product Owner as the Business

By virtue of owning the product backlog, and having authority to set priority, the Product Owner abstracts and plays proxy for quite a group of traditional project stakeholders. The Product Owner represents in Scrum all the interested Product Managers, the marketing team, the sales team, the support organization, the implementation group, and the training organization. They are the Vice Presidents and the Division Leaders… the CIO, the CFO, and the CEO

… all rolled into one nice, neat, tidy package for the development team.

Really? You might need to unpack this a bit…

In other words… and I’ll say it more explicitly this time… it is my premise that in Scrum, the Product Owner either has the responsibility for, or is an abstraction of, every other role not previously accounted for in discussing the ScrumMaster and the Team. The Product Owner is the Project Manager, the Business Analyst, the System Designer, the User Experience Architect, and every other Business Group… all rolled into one. The role is really supposed to be omnipotent and omnipresent.

What do you guys think? Have we found our missing roles? I think so. You might be thinking at this point that I have overstated my case… maybe I have. I know there are many teams out there with Project Managers and UI Designers and Analysts that probably think they are doing Scrum just fine. Maybe there are… but I bet Scrum didn’t tell them how to do it, and furthermore, I bet they are assuming additional coordination and communication costs to make it happen.

Over the next few posts we’ll explore when and why the single Product Owner approach works. We’ll also talk a bit about when and how the Product Owner abstraction breaks down. I’ll begin to share with you some of the things I have tried over the years to minimize coordination cost and a few ideas for what I might try next time. I’ll also be interested to hear about some of the things you have tried and how you think about the role of Product Onwer.

Thanks for hanging with me so far…