Scrum is the most popular framework for product development out there. In the most recent The State of Agile report, 75% of the respondents said their team practiced Scrum, or a hybrid of Scrum and another methodology like Kanban or Extreme Programming (XP).
According to the Scrum Guide, there are three roles (accountabilities) in a Scrum Team: the Developers, the Scrum Master, and the Product Owner. The Developers build the product, the Scrum Master helps the team practice Scrum as described in the guide, and the Product Owner maximizes the value of the work done by the team.
This causes many organizations and teams that practice agile to look at the Product Owner as first and foremost a Business role. And causes many people to ask…
Is the Product Owner the customer of a Scrum Team?
The Product Owner is a member of the Scrum Team, accountable for maximizing the value of the product resulting from the team’s work. The Product Owner achieves that by setting the product and sprint goals and by ordering the product and sprint backlog items, so that the items of highest value get delivered first.
In a way, the Product Owner of a Scrum Team has a dualistic role.
The Product Owner thinks and acts as a “proxy customer” when communicating and collaborating with the team. But they also think and act as a member of the team when interacting and negotiating with the customer.
High-performing Product Owners make decisions that, to the best of their abilities and knowledge, balance between the customer’s needs, the product’s evolution, and the team’s learning curve. These decisions are made in collaboration with the team and based on the customer’s feedback.
For example, imagine that a customer of a Scrum Team needs a feature.
From the perspective of the customer, the feature looks simple. Very often in software, simple features are complicated to implement.
To deliver the feature, the Developers need to make improvements to the product. Otherwise, they risk that the feature will stop working under high load and at the moments when the customer is likely to need it the most.
To make these improvements, they need to research and experiment with their options, allowing them to learn new lessons and select the optimal approach. Without this, the Developers have no way of knowing if their implementation will be “good enough” to make the feature usable for the customer and maintainable for the team.
As the member of the Scrum Team who is ultimately accountable for maximizing the value of the work done, the Product Owner needs to take each of these three factors into consideration when refining and ordering the product and sprint backlogs.
Doing so ensures that, when the delivery of the feature is complete, the whole will come out greater than the sum of its parts—allowing the team to focus on delivering other features that create more value and minimizing the risk of waste, rework, and technical debt.
Three Ways Product Owners Often Go Rogue
Scrum is a framework for product development that’s intentionally lightweight and purposefully incomplete. The most recent edition of the Scrum Guide fits on 14 pages. Scrum provides you with a set of roles, events, artifacts—and the rules for how to use them—but it doesn’t really tell you how to build the product at hand.
Give Scrum to a team whose members know how to make the most of it, and it will help them to work on the right items in a better way.
But give the framework to a team of people who don’t know much about agile, and it often results in complexity and chaos where no one knows what’s happening and everyone tells everyone else, “We don’t know because we’re agile!”
Each role in Scrum comes with its unique set of challenges. Contrary to popular belief, I’m not going to tell you that the Product Owner’s role is more or less challenging than the ones of the Scrum Master or Developers on the Scrum Team.
But there are ways in which, even with the best intentions, Product Owners can (and often do) go wrong—harming the team’s morale, slowing down the evolution of the product, and impeding delivery of value to the customer as an outcome. Let’s take a deep dive into some of them, so that we can learn from others’ mistakes.
The Oblivious Non-Technical Product Owner
In large organizations, it’s common to see the Product Owner employed by the Business and the Developers employed by IT.
At first glance, they seem to be part of the same team, just like the official Scrum Guide prescribes. But look closer and observe their interactions long enough, and you’ll see that there’s an invisible divide between the Product Owner and the Developers. It’s what I call “the line of technicality.”
The Product Owner, typically a person from a front-office department like Marketing, Sales, or Support, perceives themselves as “non-technical.” As a result, they refuse to take part in any conversation that requires them to think beyond “business” topics like the definition of a user story.
Spike? CI/CD pipeline? Refactoring? Technical debt? Non-functional requirements? Choice of technology? Trade-offs? “Sorry, I’m not technical.” Or, even worse, “Sorry, I don’t understand and I don’t care.”
One way in which Product Owners can go rogue is to forget that just ⅓ of their role is to write user stories, acceptance criteria, and order items on the product and sprint backlogs. The rest is making decisions that lead to the evolution of the product and not preventing the Scrum Team from having their learning curve.
The success of an agile leader and of a service or product owner is not in how many features they delivered in the short term, but how well they, their agile team, and their stakeholders achieved a sustainable pace over time.
The Product Owner who “doesn’t care” because he or she is “non-technical” is someone who doesn’t want to acknowledge that their decisions need to incorporate as much feedback from the team as they do from the customer. The outcome is a buggy product that’s slow to extend, hard to maintain, and expensive to scale.
You don’t need to be a Developer to be the Product Owner. Though it could help, you don’t need to know how to code, build, test, deploy, and operate software.
What you need is a genuine desire to have an open conversation with the Developers on your team, which gives you “just enough” understanding of the implications of your decisions.
The next time the Developers on your team engage you in a technical topic, don’t rush to cut them off. Instead, reply with “Help me understand this, so that I can make the right call.”
Don’t be the oblivious non-technical Product Owner.
The Overcommitting Product Owner
Every now and then, a Product Owner who likes to make unreasonable commitments and make big bets a little more than they should becomes part of a Scrum Team.
Soon after, the early signs of their overcommitment appear. “It will take some overtime and we will need to push our own limits, but winning this customer over is a really strategic thing.”
Then the next excuse comes in. “Sure, we’ll ship with a couple of bugs and it will probably add some tech debt, but let’s do it just this once—and we’ll set aside the time to fix it later.”
The problem is that “just this once” ends up happening again, and again, and again. For one reason or another, each seemingly reasonable on its own, there never seems to be a good moment to break the cycle of overcommitment and overwork.
The root cause is the Product Owner’s inability to manage expectations. Instead of addressing their weakness and learning how to make plans grounded in reality and set expectations well, the Product Owner ends up making bigger promises than the Developers can deliver.
Over the course of time, the stakeholders become frustrated because the Scrum Team seems to be systematically underdelivering. And the Developers become demoralized because the Product Owner is systematically overcommitting.
The balance is gone and there is no sustainable pace. Just big swings, in short cycles, between fighting fires on production and patching features up just enough to make them seemingly work, without ever taking the time to truly evolve the product.
Sooner or later, the product is deemed a failure and the individuals on the Scrum Team are labeled as underperformers. Customers never got what was promised them. Developers were never given the chances to do things right that they were told they’d get.
Learn how to listen to the Developers on your team and make good decisions that incorporate all aspects of the product’s development before you make a commitment to your stakeholders.
Don’t be the overcommitting Product Owner.
The Ambiguous and Undecisive Product Owner
Some Product Owners don’t think through the requirements of their customers and mechanics of their product enough to give a clear and understandable definition (a.k.a. user story with acceptance criteria) of what needs to be built by the Developers in their Scrum Team.
You’ll recognize this kind of Product Owner by two behaviors (that they may be conscious or not about):
- They delegate decisions they should be taking upwards (to their leaders, sponsors, stakeholders, customers, and users) and downwards (to the Developers in their team);
- They formulate their user stories and acceptance criteria in a way that’s ambiguous and uncertain.
As an outcome, the Scrum Team becomes ineffective because the Developers in the team often work to enable the wrong things, and inefficient because the people to whom the Product Owner tries to delegate decisions are unable to take them quickly and well.
Work on better understanding the accountabilities of the Product Owner role. If you don’t feel confident in yourself as a Product Owner and lack the know-how about making good decisions, check out my recommendation for the best book on Product Owners in “The 8 Best Books on Agile (Our Favorite Picks).”
If you recognize yourself as the ambiguous and indecisive Product Owner, don’t forget that acknowledging behaviors that are yielding negative outcomes is the first step toward being able to change them.
The Bottom Line
One common misconception about the role of the Product Owner in Scrum is that they are the customer.
The Product Owner isn’t the customer. They are a member of the Scrum Team who is responsible for maximizing the value of the work done by the team. In doing so, the Product Owner should consider the needs of the customer, the evolution of the product, and the learning curve of the Developers in his or her team.
When the Product Owner thinks that they are the customer, they often fall into three product ownership anti-patterns. Now that you know what they are, learn from others mistakes and don’t fall into them yourself.
Ultimately, product ownership is about balancing between short-term customer needs and long-term product development and, as an outcome, achieving a sustainable pace of delivery.