Product Owner

There is always more to build than a team can build. Five engineers who can finish ten things a month, facing thirty incoming requests, is the normal state of affairs rather than a crisis.

The trouble starts because the requests come from different people. Sales wants the feature this quarter's contract depends on. Support wants the problem generating the most tickets. The CEO wants something to show at the next investor meeting. All three are real, and all three have a defensible case.

With nobody deciding, the team stalls every time to work out whose request wins. The loudest person wins, or the most recent person wins, or the team does a little of all three and finishes none of it. This is where a backlog that gets reordered twice a week comes from.

The product owner role exists to end that argument. The authority to set the order goes to one person, and the consequences of that order go to the same person. Pairing the decision with the accountability is the whole design.

Most of the job is grooming the backlog. The backlog is the list of things to build, kept in order, where higher means sooner. New requests get written up as items, existing items move up or down, and anything the team has decided against gets deleted. Since the bottom of a long list never gets read, the real work is continuously sharpening the top ten or so. Sharpening means the item at the top has a written reason, a rough size, and answers to the obvious questions, while an item forty rows down can stay as the one line someone typed in a hurry.

At the start of a cycle comes sprint planning. A sprint is a fixed-length working cycle, usually two weeks, and the planning session decides what goes into it. The split of authority shows up clearly here: the product owner decides what sits at the top, and the engineers decide how many of those items fit. This is why "just take all of them" isn't a sentence a product owner gets to say.

During the cycle, questions arrive. "What should this screen show when the value is empty?" "Do existing users get this notification too?" Several of these come up a day, because building always exposes gaps nobody thought to decide in advance, and an answer has to arrive fast enough that engineering doesn't stall. Writing acceptance criteria up front reduces them — acceptance criteria are a short list of what has to be true for an item to count as done.

When the cycle ends, the sprint review is where the product owner looks at what came out and decides whether to accept it or send it back.

Engineers, every day. The job is explaining the order and the reasoning behind it, and narrowing down the judgment calls that surface mid-build. When this relationship goes distant, the product owner degrades into a request-forwarding desk and the team builds things without knowing why.

The Scrum master role doesn't overlap. A product owner decides what gets built; a Scrum master looks after whether the team runs well. When a meeting drags or another team blocks the work, the Scrum master steps in. Whether the blocked item gets pushed down the list is the product owner's call.

Stakeholders are the people who affect the product or are affected by it — sales, support, and the executive team. With them the relationship is taking requests and explaining outcomes, and a large share of the week goes into explaining why something moved down. Skip that explanation and people start going around the product owner to ask engineers directly.

Designers sit close to this role too. Deciding what comes first is partly a question of what the thing actually is, and that gets answered faster with a designer in the room than after a spec is finished. At Pagedeck, Mia and Noa look at rough screens together before an item moves near the top of the list, which is usually where someone notices the item is really two items.

The shape of the job changes with company size. Large organizations running Scrum often have a separate product manager and product owner. In a small team, one person does both.

"That's a PO call."

Stop the debate and hand it to the person with the authority.

"If you want the backlog reordered, talk to Mia first."

Don't take it straight to an engineer; the order goes through the person who owns it.

"The PO didn't accept it, so it didn't land this sprint."

It got built but failed the acceptance check, so it doesn't count as done and rolls into the next cycle.

Pagedeck has nobody with product owner on their business card, which is normal at 45 people. Mia, the product manager, is effectively acting as product owner during the hours she spends with engineering, and switches back to product manager when she and Grace talk roadmap. When Sofia brings an urgent request tied to a contract, Mia is still the one who reorders. If Sofia starts raising it with Grace instead and Grace passes it to Mia, the backlog now has two authors, and the team is back to wondering whose request counts.

People read it as a rank. It's an English job title with decision-making power attached, so it sounds like a position above the engineers. It isn't — it's a role defined inside the Scrum framework, not a level on an org chart. Whoever has the final say over backlog order is the product owner, card or no card. Read as a rank, work starts moving because "the PO said so," and the team stops asking why.

The other common reading is that the product owner writes the full requirements and hands them over. That follows naturally enough: if you decide what gets built, surely you decide how too. Work that way and the team becomes a group of people transcribing, and the better approaches that surface mid-build never get used. What a product owner decides is the order and the reasoning. How to build it turns out best when the people building it decide.