One of the sometimes-confusing aspects of the Scrum approach to Agile development is how a Product Manager fits into the system. It’s important to understand that Scrum was designed originally as set of development practices, and as such from the textbook perspective views everything through that lens. The crux of the confusion comes primarily because Scrum has a role called a “Product Owner” which is intended to be the teams “contact point” with the outside world. All too often it is just assumed that this is a role that melds entirely with that of a Product Manager, without critically assessing what that role really is, how it needs to be managed, and what other duties a Product Manager needs to engage in that aren’t comprehended by Scrum as a development practice.
What is a Product Owner?
The Scrum Alliance defines the role of Product Owner as:
[A] single person must have final authority representing the customer’s interest in backlog prioritization and requirements questions. This person must be available to the team at any time, but especially during the sprint planning meeting and the sprint review meeting.
Thus, it’s clear that the primary purpose of a Product Owner within a Scrum system is the “voice of the customer” and the deciding vote on questions of priority, scope, design, and pretty much anything that is reflected in the overall goals of the team.
There are a few other things that Product Owners are typically in charge of, which are not reflected in the above definition:
- Writing and refining User Stories, Themes, and Epics;
- Facilitating estimation sessions and backlog grooming efforts;
- Coordinating user acceptance testing and other external validation efforts;
- Actually “accepting” stories after they are deemed “complete” by the development team; and
- Representing the team and their efforts to others within the organization.
It’s also clear that the intent of the Product Owner role is primarily defined by its relationship as a supporting role for the Scrum team. The Product Owner exists to serve the needs of that team — providing them with the information needed to product valuable products and improvements based on the Product Owner’s knowledge of the market and the customers.
Additional Needs of Product Management
As anyone who has worked as a Product Manager can tell you, the interface with the development team is just one aspect of the daily duties of a Product Manager. It’s an important and necessary aspect of the job, but it’s certainly not the only one. The Product Manager has a wide variety of additional duties related to maintaining and managing the strategic direction of their product and the company as a whole. This side of the Product Manager role requires constant communication with the customers, prospects, and the market as a whole. It also requires travel to customer sites; marketing and sales meetings, trainings, and events; and account reviews — among other trips. The Product Manager needs to have their pulse on the internal and external pulse of the entire organization; they need to know what’s troubling the support teams, what onboarding issues the clients are facing, what the marketing messages are that are being distributed, and the details of many other aspects of the product that do not directly impact the efforts of the development teams.
Tensions Between Internal and External PM Duties
Obviously, there’s a very strong tension between “being available all of the time” as a Product Owner and “being in touch with the market” as a Product Manager. The traditional perspective on this is the “inbound” versus “outbound” focused Product Manager, sometimes also split between the “Marketing Product Manager” and the “Technical Product Manager” (as with anything in the Product Management world, these names and their specific organizational roles vary wildly from organization to organization). When these two directions are combined into a single role, there are naturally going to be patterns of behavior that result in the Product Manager tending more strongly in one direction or the other — either focusing more on the development side, or more on the market side. And when that happens, the other suffers to some degree.
Balancing, Delegating, and Succeeding
The important thing to remember is that you don’t have to be everything to everyone, even if you’re the sole Product Manager in the organization and you’re tasked with playing both Product Manager and Product Owner. In fact, one of the ways that you can manage both sides of the coin and continue in your efforts to build trust and respect in those on other teams in your organization is to identify others in the company who can act on your behalf within the organization when you’re outside engaging with the market. Provide them the opportunity to act as the Product Owner in your place, when the development teams are working on something that’s squarely within their areas of knowledge and expertise. For example, when working on an internal tool used by some service teams at one company, I designated the service team lead as the Product Owner for the project and had her take point on dealing with questions of scope, definition and prioritization for the teams. It made little sense for me to act as a mouthpiece for her, nor as a middle-man passing notes in class. Rather, I enabled her to demonstrate her knowledge and expertise, and the dev team had someone in-house that they could engage directly with when questions arose. All I asked was that she keep me in the loop on any major decisions she thought needed to be made, which she was more than happy to do. In the end, we had a better product that was delivered faster than expected, and we now had a major stakeholder in the organization who had more insight into how the development teams actually do their work. Everyone won, and I didn’t have to worry about traveling to trade shows and making my customer and market contacts while the dev teams moved forward.
