The Product Owner Role in Practice: Owning the Product
Product Owner in Practice series · Article 1 of 7
Throughout my career as a Scrum Master, Agile Master and Agile Coach, one of the most important — and most needed — parts of my work was helping Product Owners gain room and maturity in their role. Very often, people take on the role in a context where product decisions still arrive already made, and their day-to-day revolves around detailing what others have decided. The Product Owner role is broad, and there isn’t always someone around to show, in practice, how to perform it fully.
This series is an attempt to do that. It has seven articles, from the basics to the more advanced: the role, the first 90 days, discovery with customers, the path from backlog to delivery, what to monitor and what to expect from the team, how to grow as a product leader and, finally, how to use AI professionally across all of it. Each article ends with an optional section showing how AI can speed up that work.
This first article covers the foundation: what owning the product means, which decisions are yours, how to say no without creating conflict, and which concepts you need to master to prioritize with confidence.
By the end, you will be able to:
- agree with leadership on what is your decision and what is not;
- respond to difficult requests with reasoning instead of an automatic yes;
- be accountable for what changed, not just for what was delivered;
- organize work along the chain objective → KR → initiative → epic → story, and spot what moves no outcome at all.
What owning the product means
The Product Owner is accountable for the value of the product. Not for the number of stories written, and not for the deadline of a list someone else defined.
The Scrum Guide is clear: the Product Owner is accountable for maximizing the value of the product resulting from the work of the team. That includes developing and communicating the Product Goal, creating and ordering the backlog, and making sure it is transparent and understood. The Product Owner is one person, not a committee, and the organization must respect their decisions (Scrum Guide 2020).
In scaling frameworks such as SAFe, Product Management owns the features and the vision of the train (ART), and the Product Owner owns the team backlog. This splits the work, but it does not hollow out the role: the Product Owner remains the content authority for the team (SAFe).
Almost every Product Owner starts closer to the left-hand column, often because the organization still works that way. Changing that does not require asking permission for everything at once; it requires starting with the right conversation.
Agree on decision rights
Many of a Product Owner’s conflicts come from a question nobody has answered: who decides what? Take this matrix to the conversation with whoever leads the product and fill it in together. D = decides, C = consulted beforehand, I = informed afterwards. The format is inspired by responsibility matrices such as RACI.
The “which initiatives” row is left open on purpose: it depends on the company. The “backlog order” row is the one that cannot stay open. If the Product Owner does not hold the D there, it is worth reopening the conversation: without that decision, it is very hard to be accountable for the value of the product.
An illustrative case
A team at a large financial institution was responsible for the account-opening journey. The Product Owner wrote stories well, but the backlog order was set in a weekly meeting between the PM and three business managers. In practice, each one pushed their own item, and about a third of every sprint’s work came in outside the plan as an “urgency”. The team was always busy, and the conversion KR had not moved for two quarters.
The conversation that changed this was about outcomes, not authority. The Product Owner did not go alone: they prepared it with the Scrum Master, rehearsed the most likely objections, and brought the PM the decision-rights matrix, already filled in with how things actually worked, alongside the numbers: how much work came in from outside and what that cost in weeks of delay on the KR. The question was simple: “if the commitment is to move conversion, who decides the order of what the team does?”. The PM, who was also accountable for that KR, became an ally.
The agreement fit in three lines: the PM and the managers set the quarter’s KRs; the Product Owner decides the backlog order within them; urgent requests go to a 30-minute weekly conversation, always with an explicit trade-off — for something to come in, something goes out. On top of that, a fixed share of capacity was reserved for regulatory demands, which do not compete with the rest.
The agreement was tested in the second week, when one of the managers brought an urgent request straight to the team. It was not comfortable. But the Product Owner did not have to defend their own position: they took the request to the weekly conversation, with the PM present, and showed what would have to come out for it to come in. What held the decision was the agreement, not one person’s courage. The manager chose to wait. Within about two months, the work coming in from outside dropped to almost nothing, and the conversation with leadership shifted from “when will it be ready?” to “what is worth more right now?”.
Composite case built from situations common in this kind of context; details have been combined and changed.
Saying no, in practice
Saying “no” is not refusing. It is making the cost of “yes” visible. Three rules help: ask about the problem behind the request, show what has to come out for something to come in, and offer a way forward. These are the situations that come up most:
Whoever brings the best evidence earns authority over the backlog order. That is why discovery with customers, the topic of article 3, is the foundation of any negotiation. Article 5 shows how to build the probability-based forecast mentioned in the table.
Be accountable for outcomes
Reporting often stops at what was delivered. The next step is reporting what changed. A one-page monthly product review with five blocks is enough to change the conversation with leadership:
- KRs: starting value, current value and target, with the trend.
- What we delivered and what we learned: each relevant delivery with its hypothesis and what the data showed.
- Decisions made: what we prioritized, what we postponed and why, with the assumptions.
- Risks and requests for help: what depends on other areas or on a leadership decision.
- Next month: the two or three bets and what we expect to see.
The grammar of product
Without telling an objective apart from a KR, or an initiative from an epic, it is hard to prioritize, to know what to ask and to judge an answer. It is one of the most common confusions I find in teams, and it comes before any discussion about tools.
The point few people explain: these are two different hierarchies, joined at a single point. OKRs say what must change. The backlog says what we will do to make it change. The initiative is the weld between the two.
Read it from the bottom up: every task answers “which story does this complete?”, every story answers “which epic does this move forward?”, and so on up to the objective. This continuous thread from task to outcome is often called the golden thread, or line of sight. Where it breaks, there is work without direction.
The KR is the level closest to action
OKRs originated with Andy Grove at Intel and were popularized by John Doerr in Measure What Matters. In teams, the objective usually gets all the attention: it is the sentence on the slide. But an objective cannot be measured and does not decide anything on its own. The KR does: it is what the Product Owner uses to say “this comes in, that does not”, and what the team tracks every week.
A good KR has four parts: what is measured, from what value, to what value and by when. “Increase conversion” is not a KR. “Account-opening completion rate from 35% to 55% by March” is.
Get Bruno Novaes’s stories in your inbox
Join Medium for free to get updates from this writer.
Two traps when choosing KRs:
- A KR too far from the team’s actions. Annual revenue matters, but the team cannot see the effect of its work on it within weeks. Prefer the indicator that anticipates the outcome and that the team can move: conversion at one step, activation, use of a feature. Revenue stays on the leadership dashboard.
- A KR that is a health metric. “Keep availability above 99.9%” is a condition, not a change. Track it on the dashboard, not as a KR.
Names change, the logic does not
There is no universal naming standard. By default, Jira goes from epic to sub-task, and levels above the epic, such as Initiative, are only available on the Premium and Enterprise plans (Atlassian). Azure DevOps, in its Agile process, uses Epic → Feature → User Story → Task (Microsoft). SAFe has portfolio epics, capabilities and features. Spotify, in the model Henrik Kniberg called Spotify Rhythm, worked with company beliefs, measurable goals and bets at three levels (Crisp).
Use your company’s names. What cannot vary is the rule: each level exists to move the one above it, and any item must be able to answer “which KR does this move?”.
What to look for
Signs that the role is taking shape:
- You can say, without checking anything, what the product’s KRs are and where they stand today.
- Requests reach you before they reach the team.
- Every initiative on the board has a KR attached, in a field, not just in your head.
- You have said “no” or “not now” to someone more senior, with reasoning, and the decision was respected.
- Your monthly review talks more about outcomes than about deliveries.
With AI (optional)
Before you start. Always work in the AI tool approved by your company, never in a personal account with company data. Keep a context kit of up to two pages — product, OKRs, personas, glossary, story format and business rules — and use it at the start of every conversation. Before pasting anything, classify the data: public text or internal text without names can go into the approved tool; customer data, financial figures or undisclosed strategy only in aggregated, anonymized form. The last article in the series covers all of this in depth.
Negotiation rehearsal. Before a difficult conversation, ask the AI to play the stakeholder. It does not replace the real conversation, but it shows where your arguments are weak. Ask it to be tough: AI tends to be more reasonable than people under pressure.
I'm going to talk to a senior stakeholder [PM, VSM/VSO, manager] who wants
the feature below in the next sprint.
Product context, goal and KRs: [context kit].
Request: [description]. My evidence: [data I have].Play this stakeholder: experienced, under deadline pressure, convinced the feature is obvious.
Be tough and realistic. One objection at a time; wait for my answer.
After 6 exchanges, step out of the role and tell me where my arguments were weak,
what evidence I was missing, and a proposed agreement that protects the product goal.Backlog diagnosis. In your first week on a product, and every quarter, ask the AI to classify the items at the top of the backlog and point out where the chain breaks. The result is not meant to be applied as is: it is something to bring to the conversation with whoever sets the OKRs, and with the team.
Our company's definitions: [objective, KR, initiative, epic, story,
one line each].
This quarter's OKRs: [list]. Top backlog items: [title, description,
type on the board].1. Classify each item as initiative, epic, story or technical task, and say why.
2. Point out items registered at the wrong level on the board.
3. For each item, state which KR it moves. List the ones that move none.
4. Point out KRs that are deliverables or effort, and suggest how to rewrite them as outcomes.
Do not rewrite the items. Only diagnose.AI as interviewer. When you do not yet know what to ask, flip the roles: the AI asks, you answer. Instead of polished text that hides gaps, it exposes what you do not know yet — and the questions you could not answer become your agenda for the week.
I want to turn the initiative below into epics, but I don't know enough yet.
Before proposing anything, act as an experienced Product Owner who is going
to interview me.
One question at a time; wait for my answer. Start with the customer problem
and the KR;
only then move to scope, risks and dependencies. When I can't answer,
tell me who to talk to or what data to look for. After at most 10 questions,
summarize what we know and what is missing. Only then propose the epics.
Initiative: [text]Over time, the questions that come up most often become your own script, and you start asking them without AI. They are almost always these: what problem does this solve, and how do we know it exists; which KR does it move, and by how much; who is affected, and how many; what happens if we do nothing; what is the smallest version that tests the bet; how will we know it worked; what is out of scope; who or what do we depend on.
Closing
Owning the product starts with two things that are simple to say and hard to do: agreeing on which decisions are yours, and linking everything the team does to an outcome that can be measured. The rest of the series builds on this foundation.
If you are going to start with just one thing next Monday: take the decision-rights matrix to the conversation with whoever leads the product.
In the next article: the first 90 days as the Product Owner of a new team — what to do in the first week, the diagnosis in the first month, and how to reach the third month with direction and cadence.
And in your context: is the backlog order decided by the Product Owner or by someone else? Share in the comments.
References
- Ken Schwaber and Jeff Sutherland — The Scrum Guide (2020)
- Scaled Agile, Inc. — Scaled Agile Framework (SAFe)
- John Doerr — Measure What Matters (2018)
- Andy Grove — High Output Management (1983), the origin of OKRs at Intel
- Donald Reinertsen — The Principles of Product Development Flow (2009), on cost of delay
- Henrik Kniberg — Spotify Rhythm: how we get aligned (2016)
- Atlassian — hierarchy above the epic in Jira
- Microsoft — Agile process in Azure Boards
Product Owner in Practice series
- The Product Owner Role in Practice: Owning the Product
- The First 90 Days as a Product Owner on a New Team
- Continuous Discovery: Talking to Customers the Right Way
- From Backlog to Delivery: Slice, Refine, Prioritize, and Learn
- Monitoring, Expectations, and Forecasting
- Growing as a Product Leader
- Using AI Professionally
