In the search for a Product Management role, many people become confused by the deceptively similar descriptions, expectations, and requirements that they find for Product Owner and Product Manager roles in various organizations. I’m sorry to say, this is another reflection of the inability of our Product Management culture and discipline to adopt a clear standard for what a Product Manager is and what a Product Manager does.  The roles are similar enough that there’s an easy and excusable amount of confusion, but they are also different enough that it’s important to discuss these differences, why they exist, and what they really mean for a person seeking a “true” Product Management (or Product Owner) role.

To be honest, I could have chosen any number of seeming homonyms for Product Management — there’s Business Analyst, Program Manager, Product Leader, Product Designer, and many, many more.  But the problem with picking any of those other terms is that they’re just as amorphous and nebulous as “Product Management” is.  Thankfully, that’s not the case with the term “Product Owner” which has some clear definitions and expectations thanks to its close relationship with Scrum/Agile development practices.

First, let’s look at the history of the Product Owner role as it relates to Scrum.  In Scrum, the development teams are self-organizing teams of 5-9 resources, all of whom work together to meet the commitments that the team makes.  Now, since the teams are expected to be working 100% of the time on meeting their commitments, Scrum allows for a resource known as a “Scrum Master” to facilitate the daily stand-up meetings, and to act as a battering ram to knock down any of the blocking issues that the team identifies as impediments to meeting their commitments.  But, how does the Scrum team determine what commitments to make, or what problems to solve?  And how does the Scrum team determine whether or not they really solve the problem or closed the user story?  Therein lies the role of the Product Owner, a resource with sufficient user and market knowledge to (1) identify problems to solve, (2) elaborate those problems into user stories, (3) prioritize those user stories into a backlog, and (4) remain in constant communication with the development team, so questions or issues related to the stories can be resolved as quickly as possible.

The role of Product Owner is defined entirely by their relationship to the Scrum team.

Sounds a lot like Product Management, doesn’t it?  And it is — with some major caveats.

First, note that the role of Product Owner is defined entirely by his or her relation to the development team, and to how they contribute to the success of that team in meeting their commitments.  There is nothing in the traditional definition of a Product Owner that involves stakeholders, strategy, customer communications, marketing, support, or any of the myriad other concerns that a Product Manager must have on a daily basis in order to ensure that their product is perceived by the market as a valuable solution to customer problems.  Product Management is defined by the role’s relationship to the market; Product Ownership is defined by the role’s relationship to the development team.

Second, there are some inherent tensions between the classic definitions of Product Ownership and Product Management.  Product Owners, as noted above, are expected by their Scrum teams to be available to any member of the team, at any time, to answer any question in relation to that team’s current commitments.  The Product Owner could be the largest blocker of success, as they are not only the one who defines what is to be done, but they are also the ultimate arbiter of whether or not the story is “complete” and “accepted” as done.  Contrast this with the traditional responsibility of a Product Manager as an external and internal resource, with equal footing in the market and in the building.  A traditional Product Manager should be spending as much time actively engaging with the market as they are sitting in the four walls of their organization.  While certainly the Product Manager needs to answer questions posed by developers, stakeholders, and management — it’s the immediacy of that available that can vary greatly between a “real” Product Management role and a true Product Owner role.

It’s the immediacy of availability that differentiates Product Managers and Product Owners.

Now, that’s not to say that the two roles can’t be merged effectively, in the right circumstances and with the right culture.  Just as Project and Product Management can (and all too often, are) merged, there are risks to doing so that can affect the overall performance of the product and the company.  In fact, many of the issues that come up with a conflation of Project and Product Management come up when we look at conflating Product Ownership and Product Management:

• Trees Over Forests — One of the key things that a good Product Manager brings to the table is a thorough understanding of the market and the users, buyers, and decision-makers who are out there in the big, open world of the market.  If a PM instead winds up becoming beholden to the wants and needs of the development team, it’s nearly inevitable that they will start to focus on those “trees” associated with the execution of the plan, and start to neglect the strategic direction and definition that’s required to modify the plan when market conditions change.
• Isolation — Product Owners are expected to be as available to the developers as possible, and in organizations who adopt a very strict definition of Scrum or related Agile practices, this runs exactly counter to the Product Manager’s need to get out into the market and engage, evangelize, and research the “real world”.  This can sometimes result in isolated thinking and a reliance on internal resources who almost always have a skewed (though well-intentioned) view of the market.
• Disconnects — Whenever we conflate two roles or terms that really do mean different things, we are going to run into situations where there is a disconnect between (1) what the role “appears” to mean, (2) what others think the role means, and (3) what we’re actually doing in our role to move things forward.  This is particularly troublesome when different members of the management or executive teams have different unspoken definitions or expectations for what the role is, what it does, and how it should do those things.  This results in frustration on all sides, because someone is disappointed, and someone else feels cheated or misled because another person was “hiding the ball.”  The more clearly we define our roles, responsibilities, and duties, the better everyone is at understanding the whens, wheres, hows, and whys of our day-to-day job.

But even those issues are entirely manageable, and there’s one tool that works exceedingly well for Product Managers who find themselves unexpectedly or unwittingly thrust into a traditional role as a Product Owner — delegation!  There have been several times in my career as a Product Manager where I felt that the need for me to be a “true” Product Manager overrode the need for me to be a “good” Product Owner — the product was getting stale, or the market was making some major shifts, or we were trying to define a future state that needed heads-down focus and customer validation.  And, when those things happened, I turned to other people in the company to step in and play “Product Owner” for me on the projects that were already underway and being executed.  I found a stakeholder who knew the specific goal as well (or better) than I did, and asked them to be a resource to the developers, to answer questions on my behalf, and to engage directly toward the successful completion of the task at hand.  And it worked.  Every single time, the team was happier, more effective, and more driven when they had a stakeholder working as Product Owner.

Every single time, the team was happier, more effective, and more driven with a stakeholder working as Product Owner.

Now, I remained in close contact with the delegated Product Owner, and asked that they copy me on any decisions or documented questions that happened to come their way.  But for the most part, I let them use their expertise to guide the teams, and checked in on a regular basis to ensure the trains weren’t going off the track.  Not only did I help the team succeed, and not only did I get the strategic work done that I really needed to, but I also built an extra deposit of social capital with the delegated Product Owner — whom I’d given a huge amount of trust and respect to, and who got to see their own ideas come to life.

Never underestimate the power of delegation, and of trusting someone with experience and knowledge to make the right decisions.