A friend of mine found herself in a position where she, as a Developer, was asked to also become the Product Owner of her Scrum Team’s product.
On the one hand, the product was inherently technical in its nature and required a Product Owner with enough knowledge of the customer needs and implementation specifics. On the other, becoming accountable for maximizing the value of the product—and for delivering the Increments that create it—was not an easy choice for her to make.
Somewhere in-between, we had a good conversation (Lyn, if you’re reading this, I hope it helped). And I thought to share the key takeaways in this blog post.
Can the Product Owner be a Developer?
The Product Owner of a Scrum Team can also be a Developer on that team. In such a case, the Product Owner is accountable for maximizing the value of the product that results from the team’s work—but they also contribute to the creation of Product Increments as a Developer on the team.
You don’t need to know how to code to become a Product Owner. Programming experience can, however, help you to set better Product and Sprint Goals, as well as make better choices about the order and contents of the work items on the Product and Sprint Backlogs.
Most Product Owners are non-technical. They usually come from customer-facing departments like Marketing, Sales, Support, and Public Relations (PR). Or, for products aimed at employees, employee-facing departments like Human Resources (HR), Finance, and Procurement.
The subset of Product Owners who do know how to code are also called “Coding Product Owners.” In some areas like artificial intelligence and machine learning or media codecs and compression algorithms—where the products and work are inherently technical—Coding Product Owners are in relatively short supply and particularly high demand.
What Does the Scrum Guide Say?
“The fundamental unit of Scrum is a small team of people, a Scrum Team,” the official Scrum Guide says.
“The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”
The official Scrum Guide (scrumguides.org)
As you can see, the Scrum Guide doesn’t explicitly state that a Product Owner cannot be a Developer (and vise-versa). It doesn’t really endorse that as a recommended practice either.
Just like with most things agile and Scrum, it’s best to take the Scrum Guide (and this post) as a compass—and use it to find your own way in your unique context.
The Challenges of Being a Product Owner and a Developer
There are two key challenges of having both a Product Owner’s and a Developer’s accountabilities:
- It can create conflict of interest
- It can lead to unhealthy competition
- Each accountability will take time from the other
The first and most obvious challenge of being both a Product Owner and a Developer on the team is that it can create conflict of interest.
It Can Create Conflict of Interest
Like I recently wrote in “Can the Product Owner Also Be the Scrum Master?”, the way Scrum divides the accountabilities between the Product Owner, Scrum Master, and Developers resembles the concept of the separation of powers in a democratic government.
Democratic governments separate their three branches of power—legislative, judicial, and executive—to prevent abuse of power and conflict of interest from any single person in rule or branch in question.
Similarly, Scrum separates the three accountabilities—Product Owner, Scrum Master, and Developers—to create a balance between the roles and responsibilities in a Scrum Team.
The Product Owner sets the goals and orders the backlog, the Developers determine how the backlog is turned into increments, and the Scrum Master ensures that the team establishes, practices, and masters the Scrum framework as described in the Scrum Guide.
If the Product Owner is also a Developer, he/she can drive or influence the “Why,” “What,” and “How” behind the work. This creates the risk of the Scrum Team becoming a dictatorship where the all-knowing Product Owner determines all aspects of the work that’s being done.
If there’s one thing that history can teach us, it’s that dictators sooner or later develop blind spots so big, they make decisions that end up dethroning them and, in the worst examples, leaving their countries in ruins. The situation is not that different with Product Owners and the products that they’ve committed to evolve.
It Can Lead to Unhealthy Competition
Of course, not every Product Owner aims to establish a dictatorship over their product and Scrum Team.
Some Product Owners are highly self-aware and emotionally-intelligent individuals who can navigate the complexities of wearing two hats in the same Scrum Team. Even if you are one of them, be aware that double-hatting can nevertheless lead to unhealthy competition and toxic relationships if you don’t do it right.
Coding Product Owners are not typical Product Owners. They’re usually multi-skilled individuals with Business and IT experience who can understand user needs and negotiate with customers just as well as they can write clean code and evolve CI/CD pipelines.
As a Coding Product Owner, you risk to leave your fellow Developers on the Scrum Team feeling overshadowed if you end up misusing one of your two accountabilities.
The challenge here is context. Since you’re talking to the customer(s) as much as you’re building the product, you end up having more context about the requirements and the implementation than anyone else on the Scrum Team.
To prevent this from turning into a source of unhealthy competition, make it your obsession to share the context that you have with all of your teammates.
Ensure that your user stories, acceptance criteria, tasks, sub-tasks, code comments, and implementation are just as clear to everyone else as they are to you—even if they haven’t spent as much time thinking through the requirements or the implementation for a specific work item.
Each Accountability Will Take Time Away From the Other
As a Product Owner on the Scrum Team, you are accountable for maximizing the value of the product resulting from the work of the team. You do this by setting Product and Sprint Goals, adhering to the Definition of Ready (DoR), and creating and ordering backlog items on the Product and Sprint Backlogs.
As a Developer on the Scrum Team, you are accountable for creating any aspect of a usable Product Increment each Sprint. You do this by committing to the Sprint Backlog, adhering to the Definition of Done (DoD), and holding yourself—and your teammates—accountable as software development professionals.
The Product Owner accountability is facing the stakeholders, like the Scrum Team’s sponsors, leaders, customers, users, and/or peer teams (for example, if your product is a product that other teams in the organization are using or integrating to in order to use).
The Developer accountability is facing the team and its focus is on delivering value—while achieving technical excellence and process discipline that make the sustainable delivery of value with as less waste, rework, and technical debt possible.
As a Coding Product Owner, be aware that your Product Owner accountability and your Developer accountability will often fight for your time. Each accountability will take time and focus away from the other—and keeping a balance is critical for your success.
Achieving a 50/50 balance is ultimately impossible. So you’ll have to choose which accountability to focus mostly on. My 2¢ is to focus on the accountability of the Product Owner—it’s highly likely that all of your fellow Developers will do a fine job picking up most of your coding work.
The impact will be bigger if the team ends up focusing on the wrong items, ends up without backlog items, or can’t reach out to you when they need you to elaborate on the value of a user story or what the team intends to find out using a spike.
Make it your focus to not turn into the bottleneck for your Scrum Team. Have honest conversations with your teammates in the Retrospectives and use them to collaborate on balancing your double-hatting out in a way that best-meets the goals and interests of the entire Scrum Team.
The Bottom Line
Yes, the Product Owner can also be a Developer on the team. But it’s going to be challenging for them and their teammates.
The Product Owner is customer-facing. He/she is focused on identifying what creates value and elaborating it in the form of user stories and acceptance criteria that enable the team to commit to turning them into Increments.
The Developer is team-facing. He/she is focused on delivering value by creating and contributing to the creation of Increments. As well as achieving technical excellence and process discipline over time, allowing him/her and his/her fellow Developers to achieve a sustainable pace from an architecture, code base, and CI/CD point of view.
If you are a Coding Product Owner, remember that your double-hatting can create conflict of interest, unhealthy competition, and bottlenecks for the Scrum Team. Then focus on minimizing the risk.
As long as you stay aware of that risk, understand how your attitudes and behaviours can increase it, and collaborate with your teammates to keep it to a minimum, you’ll do just fine.
In the grand scheme of things, one accountability ultimately needs to prevail over the other.
Consider which accountability you’d like to keep for yourself in the long run. Then take all the actions that you can to be able to hand over your other accountability to other members of the Scrum Team (in a way that best-meets the Scrum Team’s goals and interests).
