An examination of key roles in an Agile environment
Agile frameworks have created a demand for new roles including the rise of the “product owner.”
This inevitably leads to additional misunderstanding and misapplication of the product owner and product manager roles, which creates unnecessary stress on the team.
Confusion over roles introduces noise and friction that diminishes the team’s focus on value, quality, speed and satisfaction. This confusion also prevents the pursuit of more valuable work, damages morale and, most importantly, prevents the team from fulfilling its Agile destiny.
That’s where this article comes in. Below, we’re going to explore these issues and offer suggestions on how to separate the roles of product owner and product manager on Agile teams.
But first, you might be thinking …” agile?” What’s that and how does it apply to product? Fear not, we’ve attempted to create a fast synopsis explaining the explosion of agile.
However, you might be deeply familiar with all things agile and you just want to know how to create a clear distinction in your organization between product managers and product owners. If so, jump down to the section “roles.”
In the Beginning…
The time: 2001.
The place: Snowbird, Utah.
Seventeen leaders in software development meet to discuss their frustrations in building working software and how their teams should evolve to face the future.
During these discussions, they agreed that the focus of their organizations was too tilted toward planning and documentation and not enough towards the ability to pivot based on market feedback.
At the end of the weekend, the “Snowbird 17” produced what we call the Agile Manifesto: a 68-word treatise on building software a better way:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work, we have come to value:
-
- Individuals and interactions over processes and tools
-
- Working software over comprehensive documentation
-
- Customer collaboration over contract negotiation
-
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
This simple and concise manifesto inspired the “Agile Revolution,” and over the past two decades, we’ve seen Agile thinking permeate far beyond the world of software engineering. Agile thinking has been a positive improvement for most teams, as they’re more responsive to the needs of their markets.
This way of thinking focuses on:
- Faster time-to-value
- Better collaboration with customers
- Quicker iterations with market feedback
- Consistency in methodology and release cadence
- Less rigidity
For those product team members who have only been working in Agile environments, it can be hard to understand that in the late 1990s and early 2000s, the “Market Requirements Document” reigned supreme. Product managers worked on MRDs for weeks—even months—before handing it off to designers, architects and engineers.
Back then, changes to requirements mid-project were frowned upon, and demonstrable versions of the product often weren’t available until a few weeks before launch—if at all.
Today, the MRD has been largely (although not completely) abandoned by most teams.
The business justifications from the MRD are now a business proposal or business canvas. Product positioning is now a positioning document. The requirements are now user stories, or—as Pragmatic teaches—problem-oriented requirements containing key context about the market’s problems.
These problem-oriented requirements can be delivered iteratively when working with design teams to kick off problem reframing and exploring ideation or with engineering teams to feed their iterative work.
Engineering teams now largely work in sprints or iterations instead of monolithic six- or twelve-month waterfall development cycles. At the end of each sprint, the team’s focus is on demonstrable work toward the Minimum Viable Product (MVP), or perhaps a higher bar like what we teach at Pragmatic Institute—the Potentially Sellable Product.
As great as Agile has been for many teams in many industries, the transition to this newer, faster and more efficient model of creating products isn’t perfect.
Now, let’s talk about some of those imperfections. Specifically role confusion for product managers and product owners.
Role Definitions
“A lack of clarity could put the brakes on any journey to success.” – Steve Maraboli
Over the past twenty years, there has been a lack of title and role clarity on product teams. There is no industry-wide accepted standard (aside from Pragmatic Institute) for clearly defining the titles and roles of product manager and product owner.
In fact, to get a better understanding on just how many different roles and titles there are in the product world, Pragmatic Institute performs one of the largest annual surveys of product professionals. In 2021, we gathered information from respondents all over the world and asked them to identify their titles, which resulted in 327 unique titles.
Clearly, titles are not the most informative of a product professional’s role.
And while we could spend page upon page looking at all the different product roles that contribute to the product team success, we’re going to focus on just two roles: product manager and product owner.
Product Manager
We teach product managers that their primary job is to be the “messenger of the market” to their team, meaning they must spend significant time in the market, interviewing and observing customers and non-customers, buyers and users of their products.
The data gathered through extensive qualitative and quantitative research is used to inform decisions for many aspects of the business.
It also informs the types of interactions with partners in design and development.
While a healthy product manager spends time and energy in the market, they have a broad focus. We use the Pragmatic Framework as a tool to teach the full scope of the tasks needed to be completed by the product team:
The activities on the Pragmatic Framework are aligned left-to-right, with the left side being more strategic in nature and the right being more execution-focused.
The Framework also defines activities top-to-bottom, where the activities on the top are more business-oriented, and those on the bottom are more product and technology-focused.
In some organizations, a product manager might take on all of these activities. In others, the activities on the Framework are divided across several team members based on their specialization and expertise.
The more important lesson that product managers learn at Pragmatic is that their role requires complex, long-term planning and prioritization.
By gathering the voice of the market and understanding the market’s problems, product managers are empowered to make decisions for their products and business that resonate with the buyers and users—leading to long-term product success.
Product Owner
The product owner role came about through the evolution of Agile software development.
As Agile matured from a concept to specific implementations, several dominant flavors of Agile prevailed, the largest of these being Scrum.
The product owner was created to address a specific problem on Scrum teams: They had to change their normal pace when they transitioned to Agile.
So instead of receiving a large set of requirements in an MRD, they moved to sprints that were shorter than a month in length. During each sprint, they would prioritize some user stories and then design and build those stories. Then, they would test and hopefully demo their work to a “representative user” who would give them feedback on their work to inform subsequent sprints.
However, representative users can be hard to find. They’re busy, and they don’t always have the patience to sit down and offer feedback every two weeks.
When you can find the rare user who is willing to take on this task, they often get burned out or realize they have the ability to highly influence a product, which could lead to them seeing the product team as a custom development shop for their own needs.
None of this is ideal, and none of this helps the team progress their implementation of Agile.
That’s where the product owner comes into play. The product owner is a development-facing role designed as the “key stakeholder” on the requirements for development.
The product owner spends a significant amount of time with the development team. They often attend daily standups, sprint and release planning meetings, retrospectives and are expected to attend all scrum ceremonies.
The development team wants the product owner to be fully available to collaborate and able to answer questions like “Do we understand this user story correctly?” or “Can you review our work and tell us if we built this feature the way the market wants it?”
The product owner’s main focus is maximizing the value of the product. They help scrum teams by making quick decisions. They have their eyes on the big picture and allow other departments to move efficiently in the right direction.
This means that the product owner plays a key role in making Agile (and specifically Scrum) teams effective. Product owners help teams assess risk and implications as they relate to time constraints and budget. They also facilitate conversation to ensure that everyone stays on the same page. Product owners are masters at prioritizing short-term objectives and daily tasks.
While Agile teams are primed by their training to move faster and iterate quickly, product owners help provide knowledge of users’ needs at key points in the process with market context to enable speed and time-to-value.
The Combination of Product Manager and Product Owner
“It is better to change an opinion than to persist in a wrong one.” – Socrates
It’s clear to see that both the product manager and the product owner roles have value in modern product teams. The critical issue is when executive teams attempt to combine these roles, which puts an employee into a situation where success lives on a knife’s edge.
When the development team transitions to Agile and asks the company for a product owner, most executives want to say yes. Everyone wants to enable their team to move faster, to iterate and build more successfully.
Unfortunately, the reality of business runs headfirst into the resource needs of the team:
Hiring is expensive and hard.
Since product owners are most effective with a few teams rather than several teams, larger organizations might have to hire several product owners, and each new hire comes with additional investments like benefits, training, retention costs and more.
So it’s no surprise that executive teams start searching for alternative approaches, including utilizing the team, talent and resources they already have in-house.
Many executive teams aren’t familiar with the different focuses of the product manager and product owner roles, and will combine them in an attempt to be good stewards of resources—but this is a critical error.
The product manager pays attention to the market and focuses on long-term planning. The product owner focuses on the internal teams and is an expert at prioritization and short-term planning.
In our experience, the product owner side tends to dominate since it’s natural to want to manage the most pressing issues first. Looming deadlines are louder than tasks due at a later date.
But that later date always comes around. It’s a recipe for breakdown in effectiveness as long-term planning is a complex task that requires space and time to complete, which you won’t have if you’re always focused on the short-term.
After a long enough period of time, product professionals trying to balance both roles look up and say, “I’ve been spending so much time talking to my internal development team, I can’t remember the last time I was in the market, understanding the needs of my buyers and users.”
The consequence of this role-combining is that the team becomes “inside-out,” focusing on the voices inside the organization or dated market knowledge instead of current buyers and users outside the business.
To achieve outside-in focus, executive teams must recognize that the roles of product manager and product owner are separate for a reason. It’s essential to keep these roles separate because:
- The product owner’s focus should be on helping the Agile team run faster by providing context about the users’ needs.
- The product manager’s focus should be on helping the business run in the right direction by providing the voice of the market.
Addressing the Issue of a Combined Product Manager/Product Owner Role
“There is always an easy solution to every problem—neat, plausible and wrong.” – H.L. Mencken
Questions to ask yourself, your peers and your manager
If you’re a product manager or product marketer, and you’re being asked by your executive team to perform both roles simultaneously, you must start a conversation with your executives about the tradeoffs they’re asking you to make.
Help them understand the expectations of each role and the challenges you’ll face trying to manage both.
You can approach this issue tactfully by asking the right questions:
- How will success be measured for the product manager side of my role?
- How will success be measured for the product owner side of the role?
- What are my metrics or OKRs?
- How much time do you expect me to spend in the market interviewing and observing users and buyers each week or month?
- How much time do you expect me to be in meetings with the Agile team?
- Which activities on the Pragmatic Framework do you consider to be part of my role?
Most importantly, ask what work they want you not to perform. There are only 8 hours in a workday, and you’ll quickly fill those up by spending time supporting the Agile team while simultaneously trying to be in the market.
If this is a promotional offer or a job interview, remember that when you’re interviewing for a role, you’re interviewing them as well. Make sure that your understanding and the company’s understanding of the role are in alignment before you accept the role.
Three Solutions for Executives When the Business has a Combined Role
As an executive, if you want the product manager and product owner to reach their full potential, you should consider separating the role. While this might require new hires, it’s not your only option.
- Hire Additional Employees
The most obvious solution is to hire someone new. So if you’re launching a new Agile team, hire a new product owner to go with the team.
Of all the solutions we offer, this is arguably the most effective for long-term success as it allows your product owner to focus their full attention on the Agile team and your product manager on the market and long-term planning.
- Divide the Labor Differently
If you don’t have the ability to hire a new employee, another solution is to divide the labor within your team in a new way.
For example, if you have five combined product manager/product owner roles, you could turn three of them into full-time product owners and two into full-time product managers. This allows your product managers to be fully market-focused and outside-in, and the product owners to work closely with their development counterparts.
In addition, some people are more comfortable doing the inside-the-building work of the product owner (or vice versa) and this will allow you to align the work of the team to their interests and skills.
The Pragmatic Framework is an essential tool to help clarify the division of labor within a team—perform a Gap Analysis (as taught in our Foundations course) with your team to identify and map roles and titles to activities.
- Choose What Not to Do
If you can’t hire new employees and you can’t divide labor differently, then as an executive, you must work with your team to ruthlessly prioritize their time and establish the right metrics for success.
For example, you might timebox your employees to certain types of work on certain days, or establish a metric for the number of market visits they’re expected to complete each quarter to ensure an outside-in focus.
If you choose this option, you must be prepared to provide significant support and defense to your team member in the combo role because not everyone will see the value in these clear time boundaries.
In the past, I’ve had to put a product manager in this situation. We didn’t have the ability to hire new staff for at least a year, and I didn’t have any additional resources to divide the work across multiple employees. The solution we came up with was that the employee would only be the product owner on Mondays and Fridays; Tuesdays through Thursdays they were exclusively the product manager.
I set the expectation that they were not expected at standups, backlog grooming or any other internally-facing meetings during those times, because that time was reserved for outside-facing work with the market.
The development team didn’t like the solution and felt frustrated because they lacked consistent access to their product owner.
They explained that the situation created roadblocks, causing them to move slower, so they missed the efficiencies that the Agile process afforded them.
In retrospect, although this solution worked, as the product executive I provided air cover for this decision but could have sold and communicated it even more internally with my peers to ensure that the rationale behind this decision was well understood across our organizational structure.
But we stuck with it, because it was more important we run in the right direction than to run fast in the wrong direction.
If you opt out of these solutions and continue to combine your product manager and product owner roles—and expect them to succeed—be prepared because your team will start to pursue a fourth option: They’ll find different jobs.
As more and more teams become Agile, and we continue to create new versions of Agile workflows, it becomes increasingly important to understand and embrace the two different and separate roles of product manager and product owner.
Both of these roles are essential to the success of a product team, and when separated and performed effectively, can have an outstanding impact on your organization.
