Most Product Owners come from the Business. They usually work at a customer-facing department like Marketing, Sales, and Support, or an employee-facing department like Human Resources or Finance when the product is intended for users internal to the organization.
Which is why most Product Owners have profound knowledge of the way the business operates and what customers need—but don’t know anything or much about how the work is done.
Should the Product Owner be technical? And, if yes, in which cases?
The official Scrum Guide doesn’t explicitly require the person with the Product Owner accountability to be technical. However, technical aptitude can help Product Owners to create and order backlog items in a better-informed way, and to communicate and collaborate with their teammates more clearly and easily.
As you were reading this answer, some of you probably asked yourselves, “But what do you exactly mean by technical?”
Product Owners can be “technical” in various ways depending on the industry, field of work, organization, and use case that their (and their team’s) work relates to.
For example, a Product Owner at a semiconductor company can be technical by being educated in or having practical experience with engineering and manufacturing computer chips. Whereas a Product Owner at an online retailer can be technical by having theoretical knowledge of or experience in software development for web and mobile apps.
Technical can also have multiple meanings within a single sector like cloud computing. The Product Owner of a cloud service for big data analysis will have different experience and competencies than the one for a cloud service for developing web-based Augmented and Virtual Reality apps.
If we follow this train of thought, “technical” can mean completely different things in the context of the consumer staples, communication services, defense & aerospace, healthcare industry, and so on.
What Does the Product Owner Do?
According to the Scrum Guide, the Product Owner “is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”
On a high level, the Product Owner is responsible for managing the Product Backlog effectively. In doing so, they maximize the value of the product by ensuring that the team works on Product Increments (small pieces of the product shipped at least once per Sprint) that create value for the user using it, the customer buying it, and/or organization sponsoring it.
The Product Owner usually performs the following activities:
- Setting the Product Goal and Sprint Goals;
- Creating and ordering the backlog items on the Product and Sprint Backlogs;
- Ensuring that the Product and Sprint Goals and the Product and Sprint Backlogs are transparent, visible, and understood.
To perform these activities well, the Product Owner spends a good portion of their time talking to the sponsors, customers, and users of their product, so as to capture their needs and listen to their feedback.
Product ownership is as much an art as it is a science. High-performing Product Owners spend as much time on getting insights from the adoption and usage data that they capture about their products—and coming up with ways to improve existing metrics or define and track new ones.
Once the Product Owner has thought through the needs of and feedback from customers, their next challenge is to translate their vision into work items, so that they can have conversations with the Developers on the team about the value and goals that these work items aim to create.
Product Owners spend much of their time formulating user stories, elaborating acceptance criteria, and having conversations about the Product Goals and Sprint Goals that they aim to meet with the Developers on their Scrum Teams.
What Should the Product Owner Not Do?
Ideally, the Product Owner shouldn’t also be the Scrum Master or a Developer on the Scrum Team. While the official Scrum Guide doesn’t necessarily exclude these two possibilities, it’s more than clear when it says, “The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.”
The Product Owner should focus on the “Why” (the Product and Sprint Goals) and the “What” (the Product Backlog Items), leaving the “How” to the Scrum Master and Developers on the Scrum Team. The Product Owner should not attempt to control or dictate the implementation of Product Increments by his or her team.
The Product Owner should always seek commitment from the Developers on his or her Scrum Team for the contents of the Sprint Backlogs. The Product Owner sets the Sprint Goal and has an honest conversation with the rest of the team on how to best meet it. The Product Owner should not ask his or her team to commit to more than they estimate possible.
Leaving the “How” to the Developers and trusting their commitment can be especially challenging for Technical Product Owners. When you can not only write user stories and acceptance criteria, but can also turn them into Product Increments, it can be tempting to come to premature conclusions about the implementation approach and estimation of individual work items, as well as the Product and Sprint Backlogs as a whole.
Avoid the temptation—and trust the Developers on your team instead. Your technicality allows you to better-understand their reasoning and have deeper conversations with them around estimates, design, and approach. Just don’t use it as an excuse to challenge the Developers on the team or overstep the boundaries of the Product Owner accountability.
How to Tell If a Product Owner is Successful
There are many ways to define and measure product ownership success.
Ultimately, you should find the definition and metrics that are most relevant to your industry, organization, and department. At the same time, there are ways to litmus-test whether or not the Product Owner of a Scrum Team is succeeding.
If a Scrum Team is consistently working toward Product and Sprint Goals aligned to the goals of the organization and needs of the customer—and delivering Product Increments of high value frequently—that’s usually a sign that the Product Owner is doing a good job steering the Product in a good direction.
However, if the Scrum Team is swaying between Product and Sprint Goals in a hectic and unrelated way, and/or is continuously unable to deliver Product Increments of high value for one reason or another, it may indicate that the Product Owner is experiencing challenges. In that case, they may need training and certification and can greatly benefit from agile coaching.
As the eighth principle behind the Agile Manifesto says, “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
What Metrics Will Help a Product Owner?
Internal Metrics
Here’s the rundown:
- Actionability of Product and Sprint Goals
- % of user stories that meet the Scrum Team’s Definition of Ready (DoR)
- Availability to the Developers and Scrum Master on the Scrum Team
The Product Owner steers the evolution of the product by setting Product and Sprint Goals one at a time. The best Product and Sprint Goals are ACTIONABLE. They are:
- Achievable
- Clear
- Timely
- Informative
- Objective
- Narrowed-down
- Accurate
- Bold
- Laconic
- Economical
Yes, that’s a really long acronym and it’s practically impossible for any Product or Sprint Goal to meet 100% of the criteria that it represents. But, if you are a Product Owner, use it to litmus-test your ability to set good Goals for the evolution of your product and the work of your team.
One of the accountabilities of the Product Owner is to create backlog items that translate the product goals into user stories that the Developers on the team can, in every Sprint, turn into Product Increments. A useful metric that Product Owners (and/or Scrum Masters) can measure in that area is % of user stories that meet the Scrum Team’s Definition of Ready (DoR).
Throughout the Sprint (and not just at the formal events within that Sprint), the Product Owner should be available to the Developers and Scrum Master on the Scrum Team.
Availability can be critical to the progress of the Scrum Team whenever a conversation about the Product Goal, Sprint Goal, or an individual Backlog Item is necessary.
As well as when the Developers on the team inspect and adapt their plan for the Sprint—and changes to the Sprint Backlog need to be triangulated between them, the Scrum Master, and the Product Owner.
One metric that can prove useful is availability of the Product Owner to the members of the Scrum Team. The metric itself can be tracked and measured in multiple ways (and it’s best for each Scrum Team to determine the optimal way for doing so in their unique context).
External Metrics
The metrics external to the Scrum Team, or the “external metrics,” depend heavily on the industry and use case for your product.
As a rule of thumb, most Product Owners find it useful to track four categories of metrics: Acquisition, Activation, Retention, and Financial metrics.
Here’s the rundown:
- Acquisition metrics help you understand what channels and campaigns your customers and/or users are coming from;
- Activation metrics help you understand how customers and/or users engage with your product—and where in the customer/user journey they’re dropping out;
- Retention metrics help you understand how you are retaining customers and/or users—and which segments of customers and/or users are retained the most;
- Financial metrics help you understand how your product is performing in terms of revenue, profitability, and/or other metrics relevant to its financial performance.
Different methodologies and best practices exist for each of these metrics.
The Bottom Line
In most agile organizations and agile teams, Product Owners don’t need to be technical to fulfil their accountability. In fact, they often come from customer-facing departments like Marketing, Sales, or Support, and generally don’t have technical experience or knowledge.
Every rule has its exceptions. Some products, like media codecs or AI/ML algorithms, are inherently technical—and simply cannot be managed by someone who doesn’t have a foundational understanding of the technology behind them at a minimum.
Technical Product Owners are rare. In most industries, they come in short supply and are in generally high demand. Usually, Technical Product Owners are professionals with years of experience on the Business and/or “technical” side of an industry.
Are Product Owners in your industry and organization technical? Share your thoughts with me and the rest of this post’s readers in the comments section below.
