I’ve noticed a decent amount of discussion lately on LinkedIn and other areas regarding the difference between Product Owners and Product Managers when it comes to Agile development practices.  The confusion largely stems from the fact that textbook Scrum has a very specific definition of the Product Owner role, but has nothing at all to say about the Product Management role, which is entirely understandable, since Scrum concerns itself with the execution of product development by engineers and not with the ideation of product by the business side of the equation.  This simply means that we can’t just take textbook Scrum and expect that it provides us with a comprehensive set of guidelines for how to run our business, because it was never conceived of as such.

Let’s break this down a little bit…

First, a History Lesson

Before we even talk about the roles and the definitions, we need to understand the origins of the Scrum approach and the Product Owner role in general.  Back in the early ’90s, two software development teams independently came upon a concept of self-organizing teams who could make time-boxed commitments in line with the principles of the Agile Manifesto — holding the focus on working software to be the keystone of their approach.  By 1995, this concept had become structured enough to be presented publicly, by the representatives of these teams Ken Schwaber and Jeff Sutherland.  As they presented their concepts and ideas, they continued iterating on it and gaining traction with software development teams across the country, and in 2001 the seminal book on the subject was published by Schwaber and Mike Beedle, Agile Software Development with Scrum.  Throughout this process, three core roles grew into what we now call the Product Owner, Scrum Master, and Scrum Teams.  Schwaber and Sutherland viewed the Product Owner as the “voice of the customer” and established some key rules and expectations around the role — that they are ever-present to answer questions and clarify requirements, that they are primarily responsible for creating and curating user stories, and that they are in charge of the product backlog as a whole.

Product Owner = Internal Focus

Obviously, when we view Product Management with a lens from the Development teams outward, we’re going to focus on the things that a PM is responsible for in regard to that team.  Similarly, if there were an approach that was defined by Marketing, we’d see a list of deliverables and responsibilities expected from the Marketing team, and likely not a terribly strong focus on the needs and expectations of the other teams.  So, when we’re looking at the Scrum definition of “Product Owner” we need to be aware that this definition is from a specific point of view, one that was not created by Product Managers, but by teams of software developers looking for a role to feed into their new concept of self-organizing teams.

So, what we seen in the Product Owner role is a very strong internal focus and bias.  The Product Owner is expected to be present all of the time, so that the development team can pick their brain if there’s something unclear in the requirements that they’ve committed to deliver — something that’s expected to happen, as user stories are “the start of a conversation.”  At the same time, Scrum expects that the Product Owner is the “voice of the customer” — which indicates that while there’s some understanding of the traditional role of the Product Manager, there’s also a tension there.  How can one accurately represent the “voice of the customer” if they’re sitting at their desk waiting for developers’ questions?  Other responsibilities of the Product Owner fall into more traditional responsibilities — maintaining a prioritized backlog, creating and curating user stories (requirements), and facilitating discussions with stakeholders and customers.  But all of these are viewed through the lens of the needs of the Development team, which can lead us down a very narrow internally-focused path.

Product Manager = External Focus?

If you look at the “textbook” definitions of a Product Owner, you should immediately run into some strong questions about just how the Product Owner is supposed to “represent the  customer” if they’re so internally focused.  And the simple answer to that is that they can’t —  you can’t accurately represent the customer unless you’re also actively engaging with them.  Which means that you need to get outside the four walls of your organization and directly communicate with your market, your prospects, and your customers.  You need to work with your Sales and Marketing teams not only in explaining what the Development team is working on, but also to understand who they’re targeting and why they’ve chosen those market segments.  You need to work with your Support and Services teams so that you have an understanding of the pain points of your customers and what costly manual efforts your company is exerting to meet those customers’ needs.  You need to ensure that you have a clear, 360-degree view of the health and ecology of your product.

Many people make the immediate leap that if a Product Owner is internally-focused, then their Product Manager must be externally-focused.  But this is a false dichotomy that actually hurts both roles, assuming they’re separate people.  You can’t just push your Product Manager into the market without any context for what’s feasible or what’s being worked on, and you can’t just point your Product Owner back into the Development pit to manage the deliverables that are being foisted upon them by some external stareholders.

Product Ownership is a Subset of Product Management

All of this is really intended to point out that what Scrum refers to as the Product Owner is generally just a subset of the responsibilities of a traditional Product Manager.  Traditional Product Managers bridge the gap between the customer and the solution, between the business and the technology, and the best Product Managers straddle that line, pushing and pulling where needed to ensure that the right things are being done for the right reasons at the right time.  Now, this means that a Product Manager in a Scrum organization still needs to figure out how to balance their external-facing needs to get out with their market and their internal-facing needs to be available to the teams for questions and clarifications.  But in the modern era of email, smartphones, Slack, and other solutions, the Product Manager/Product Owner doesn’t have to be constantly co-located with their Development teams in order to meet the needs and expectations that a Scrum Product Owner has.  And, when it becomes too much or for specific needs, the Product Manager can always delegate the Product Owner role to someone else in the organization — someone who has a better or more complete view of the customer needs (Services teams are often a great source of delegates for a Product Owner need).  But the Product Manager doesn’t cede the necessity of their involvement when this happens — rather, they’re handing the reins to someone to act in their place, while still holding ultimate responsibility for the outcome that the delegate is pushing for.  Having open and clear lines of communication when delegating Product Owner duties is essential to the success of that choice.