Team & agility

How product owners get their teams out of the delivery corner

Lucian Katzbach Gamification designer & startup coach

6 June 2025Published

2 minReading time

On the whiteboard: two filled-in specification blocks on the left, an arrow to the right, and there a chain of user, target and three steps, with a happy face, a rising curve and a star underneath

Plenty of product owners know the dilemma:

They write carefully worded User Stories, often with detailed acceptance criteria, clear UI specifications and tidy processes. And the team still comes back with questions like:

"What exactly is supposed to happen when…?"
"Why does the user actually need this?"
"Can I just reuse the pattern from the last feature?"

At first glance it looks as though the team needs more context or clearer instructions. The result: even more detailed stories. Even more hand-holding. Even more responsibility on the product owner's side.

But what if the level of detail is itself the problem?

From delivering to thinking along

On the screen a chain: user, an unhappy face, a light bulb and a green tick, with a dashed feedback loop; four tiles of metrics underneath

In many teams user stories are written from one angle: what should be built?

The consequence is that the solution is already baked into the story — and the developer becomes an implementer rather than a thinking partner.

There is another way: stories that describe what the user wants to achieve — and why. Not how.

That shifts the focus:

from feature to effect
from delivery to goal
from briefing to a shared solution

Common objections — and why they dissolve

Drafts with question marks beside them on the left; on the right, past an arrow, the sequence of user, target, three steps and a tick with a rising curve

Plenty of product owners worry that this asks too much of their team.

No product understanding. Too little experience. No time to think.

The good news: it works anyway — as long as you design the transition properly.

What helps:

A clear description of what the user is trying to achieve
Concrete, checkable criteria for success (from the user's point of view!)
A gradual transition — on smaller stories, say, or in parallel with the old method
Extra context in refinement, not in the ticket

The effect:

The team asks different questions. It understands the purpose behind the story.

It develops ownership — and better solutions.

But what about teams that are not there yet?

Two team members are at the board drawing themselves while he stands beside them with his hands in his pockets; above them the chain of user, warning sign, speech bubble with a feedback loop, and a star

It takes time, of course. Especially with developers who are new to the product or have little insight into its users. But this is precisely the approach that builds that understanding — through genuinely engaging with the "why" behind a story.

Instead of implementing requirements blindly, developers start to spot patterns, make suggestions and raise risks early.

In the long run that is not only more efficient — it also makes the work more meaningful.

In closing: the perspective is what counts

A chain on the whiteboard: a group under a magnifying glass, a puzzle piece with a question mark, a rising curve with a tick, and at the end a group in a circle of light — underneath, a dashed path leads from idea through design and delivery to feedback and back

If you want your team to take responsibility, you have to create the room for it.

Not through better specifications, but through better orientation:

Who are we trying to help here?
Which problem are we solving?
How will we know it worked?

When product owners dare to put those questions at the centre, something starts to shift:

Away from working through a list. Towards actual product development.