← All essays

Product Development

The Three Product Owner Accountabilities, Through the Lens of Thinking in Product

Knowing what you own is only part of the job. You also need a way to think while you own it. That is where the six shifts in Thinking in Product help.

By Ewan O’Leary4 min read

What does a great Product Owner actually pay attention to?

I think of the role as a balance of three accountabilities:

The Team. Stakeholders and Customers. The Product Backlog.

Each matters. None stands alone.

Knowing what you own is only part of the job. You also need a way to think while you own it. That is where the six shifts in Thinking in Product help.

Product Owner Areas of Focus connects the Product Owner with Stakeholders / Customers, the Product Backlog, and the Team.
  • Stakeholders / Customers: Understand needs, align on value, communicate and influence.
  • Product Backlog: Own and evolve backlog, prioritize, ensure transparency, manage external vendor relationships.
  • Team: Collaborate, clarify work, make decisions, unblock.

Diagram: TealShift, LLC. Adapted visually for Thinking in Product; original wording and Creative Commons attribution retained. View full-size diagram.

The Team: Lead the Product

Your team needs the why and the what so it can own the how.

That does not mean the Product Owner disappears once the work starts. It means creating enough clarity for the team to think, decide, and contribute.

Start with problems, not solutions.
Bring the customer, the problem, and the context into the conversation. Do not arrive with the answer already decided. Teams handed a solution wait for instructions. Teams given a worthwhile problem bring their expertise.

Define outcomes, not outputs.
Help the team understand what success looks like. “Ship the feature” is an output. What changes for the customer because you shipped it? That is the outcome.

The Product Owner leads the product. The team helps work out how to move it forward.

Stakeholders and Customers: Learn What Matters

The Product Owner sits between the people with the need and the people building the product.

That does not make the PO an order taker.

It makes the PO responsible for listening, learning, bringing different perspectives together, and helping people make sense of what matters.

Treat plans as bets, not certainties.
Make assumptions visible. Invite stakeholders to help test them. Confidence should grow from evidence, not from how firmly we made the original promise.

See systems, not silos.
Sales sees one part. Service sees another. Customers, suppliers, finance, operations, and engineering all see something different. The Product Owner helps connect those views.

Review completed work together.
Do not wait until the end to find out whether you were right. Put working product in front of people. Ask what changed. Ask what you learned. Ask what should happen next.

The Product Owner does not simply collect stakeholder input. The Product Owner helps stakeholders and customers make sense of it together.

The Product Backlog: Deliver and Adapt

The backlog is your current best view of what is worth doing next.

It is not a list of promises.

It should change as you learn.

Make trade-offs. You cannot do everything.
Every yes creates a not now somewhere else. Make that visible. Good prioritization is not about squeezing more into the backlog. It is about making choices.

Iterate rather than launch.
An MVP is not the end of the work. It is the beginning of learning. Release something useful, learn from it, and improve it.

Keep the big rocks visible.
Longer-range work can belong in the backlog before every detail is known. Early items will be fuzzy. That is normal. As you learn, uncertainty narrows and the work becomes clearer.

The backlog should reflect what you know now, not what you once promised.

Holding the Tension

These are not three separate jobs.

They pull on one another.

The team may want clarity before the market gives it to you. Stakeholders may want certainty when you still have assumptions to test. The backlog may contain more worthwhile work than the team can possibly deliver.

That tension is part of the role.

The six Thinking in Product shifts help you work through it:

  • Problems, not solutions
  • Outcomes, not outputs
  • Bets, not certainties
  • Trade-offs, not everything
  • Systems, not silos
  • Iterations, not launches

A strong Product Owner does not apply one shift at a time. The role is about using them together while balancing the needs of the team, the market, and the product.

Where you spend your time will change as the product changes.

That choice matters.

Questions to Ask Yourself

  • Which of the three accountabilities gets most of your time today?
  • Is that where your attention is most needed?
  • Which Thinking in Product shift is hardest to hold onto when pressure rises?
  • What assumption in your backlog could you test now instead of debating for another month?