Product ownership

The Product Owner: shortening the path from investment to impact

The role isn't about writing requirements or managing a backlog. It's about making sure the money, time and talent an organisation puts in comes back as real value, as soon and as often as possible.

1 · What the role is forFrom resources to impact

Every product turns resources (people, time, money) into activities, which produce output. Output only matters if it leads to outcomes, a change in what customers and users can do, and then to impact, the value that comes back to the organisation and the world it serves.

Output has a short feedback time and is simple to count and add up. That makes it tempting to focus on, while the less tangible, longer-term outcomes and impact get neglected. A Product Owner keeps attention on the right-hand end of the chain, and does everything they can to shorten the time between investing a resource and seeing its impact.

The shorter that cycle, the sooner value starts coming back, the sooner you learn whether you were right, and the less you've spent before finding out.

2 · Return on investmentOrdering by value over the long term

The Product Owner has the authority to decide what to deliver, and in what order, to maximise return on investment over the long term. The Product Backlog is the visible result: a list of valuable items, ordered by their expected return, that anyone can see and understand.

A few economic ideas help a Product Owner make these trade-offs openly:

• Cost of delay: what it costs, over time, not to have something yet.
• Opportunity cost: what you can't do because you're doing this.
• Total cost of ownership: what it costs to run, support and maintain over the product's whole life, not just to build.
• Net present value: value arriving sooner is worth more than the same value arriving later.

Value also looks different to different people. Customers, users, the organisation and its partners will each see it in their own way: acquiring or keeping customers, reducing risk, revenue or cost, or simply learning what's worth building. Part of the role is holding these views together and making the trade-offs visible.

Learning is part of the return

Every item in the backlog carries assumptions: that it addresses the right problem, that this is the right solution, that it can be delivered, and that it will pay back. A Product Owner reduces those risks by learning as cheaply and as early as possible.

3 · The full cycleDone means it could go to customers

A Scrum Team is responsible for all product-related activities: working with stakeholders, research, experimentation, development, verification, release, operation and maintenance. When part of that cycle sits outside the team, work piles up waiting for someone else, and the time from resource to impact quietly gets longer.

The Definition of Done is where this shows up. A strong Done describes everything needed for an Increment to be usable by customers. A weak Done leaves activities for "later", and later always costs more.

A simple way to start: write a sticky note for every activity needed to get your product into customers' hands. Mark the ones you can do every Sprint. That's your Definition of Done today. Everything else is an opportunity to improve, and each one you bring inside the Sprint shortens the cycle.

4 · Where the Product Owner standsGo-between, or connector?

How the role is positioned makes a big difference to how quickly the product can learn. Three common pictures:

In the third picture the Product Owner doesn't step back from the product. They spend less time relaying details and more time on what only they can do: setting direction, ordering by value, saying no (or "not yet"), and keeping a wide view across the market, stakeholders and the organisation, listening for biases and weak signals.

Ways to connect developers directly with customers and users include the Sprint Review itself, customer interviews and observation, job shadowing, usability testing, and collaborative games with customers.

Authority, with collaboration

The Product Owner is one person, not a committee. That avoids design by committee, makes it clear who is accountable, and shortens the feedback cycle because decisions don't wait for a meeting. Anyone can propose changes to the Product Backlog, and Developers often refine items with stakeholders themselves, but the Product Owner decides whether and where items go. One source of truth means no conflicting priorities within the team.

Authority should match accountability. If a Product Owner is accountable for value but can't actually decide what gets built, every decision waits for someone else, and that waiting (decision latency) adds straight onto the time from investment to impact.

5 · Multiple teams as the defaultOne product, many teams

Most products worth building need more than one team. Rather than treating that as a special case, it helps to start from it: define the product broadly, then organise teams around it, all sharing one Product Owner, one Product Backlog and one Product Goal.

Why make it the default? When each team gets its own small "product", its own backlog and its own Product Owner, priorities are set locally. Teams optimise their part while the whole product waits on hand-offs between them, and someone has to spend a lot of time coordinating. One backlog keeps everyone working on what matters most to the whole product, and lets any team pick up the next most valuable item.

What makes it work:

• Prioritise, don't clarify: the Product Owner orders the backlog and sets direction. Teams clarify details with stakeholders and users themselves.
• One Definition of Done for the whole product, so there's always one simple, consistent, usable Increment. Teams with more capability help the others raise it.
• Teams that can deliver end to end, organised around customer value rather than components, so any team can take any item.
• One Sprint Review for the whole product, where stakeholders see and respond to everything together.

6 · HeuristicsRules of thumb for Product Owners

Not rules, but useful questions to steer by when the situation is unclear.

1. 1Start from the customer's view of the product.Ask your customers: what valuable product or service do you receive from us? Define the product that broadly.
2. 2One product, one owner, one backlog.However many teams, keep one Product Owner, one Product Backlog and one Product Goal.
3. 3Order by return, over the long term.Not by who asks loudest or most senior. Make the reasoning visible.
4. 4Maximise outcomes, minimise output.The best work is often the work you decide not to do. Look for low and negative value work and stop it.
5. 5Say no, or "not yet".Be ruthless about focus. You ain't gonna need it, until you've learned that you do.
6. 6Shorten the path to impact.Ask what's between this investment and its impact, and what you could remove.
7. 7Own the full cycle.Strengthen Done until each Increment could go to customers. Every activity left outside the Sprint is delay you're choosing to keep.
8. 8Learn by the cheapest route that teaches you something real.Real use of a real Increment usually beats asking people what they'd like.
9. 9Clarify just enough.Detail the next few items, not the whole backlog. The rest will change as you learn.
10. 10Connect, don't relay.Put developers in direct contact with customers and users. Your job is purpose and order, not passing messages.
11. 11Collaborate on content, keep the decision.Anyone can propose. You decide whether and where it goes, and say why.
12. 12Authority to match accountability.If you can't decide, find out who can and close the gap. Waiting for decisions is part of the cycle time.

7 · Watch forWhen the role gets diluted

Organisations often create something called a Product Owner that can't do what the role is for. Some familiar patterns:

None of these is anyone's fault. They usually reflect how the organisation is set up: how products are defined, how funding works, who holds decision authority. Changing them often means changing the organisation around the role, not just the person in it.

Quotations from The Scrum Guide (2020) by Ken Schwaber and Jeff Sutherland, used under the Creative Commons Attribution Share-Alike licence (CC BY-SA 4.0).