In Celebration of the Product Owner

I want to talk about the most undervalued role in software development.

Not developers. Everyone values developers. Not scrum masters. They at least have a certification industry validating their existence. Not QA. Even when QA is underappreciated, everyone knows what happens when you skip it.

I’m talking about the product owner.

The person who translates business needs into developer-ready requirements. The person who decides what gets built, in what order, and with what level of detail. The person who sits between “the business wants this” and “the developer can build this” and makes sure both sides actually mean the same thing.

And the role that a shocking number of companies either skip entirely, assign as a side job to someone already doing something else, or fill with someone who has no idea what the role actually requires.

Every one of those companies pays for it. They just don’t know that’s what they’re paying for.

A Quick Self-Assessment

Before I go further, answer these honestly:

Do your developers ask more questions during development than during refinement?
Is “that’s not what I meant” a regular phrase in your sprint reviews?
Do stories routinely carry over from one sprint to the next?
Do your developers take longer than five minutes to refine a story?
Do developers make product decisions while coding because the story didn’t specify?
Has a feature ever been built, demoed, and rejected, then rebuilt?

If you said yes to more than two, you have a product owner problem. You may not have realized that’s what it is. Most teams don’t. They think they have an estimation problem, or a developer speed problem, or a communication problem. They don’t. They have a requirements problem, and the person responsible for requirements is either missing, part-time, or untrained.

What You’re Actually Paying For

When a team doesn’t have a dedicated, skilled product owner, here’s what happens. See if any of this sounds familiar.

Stories are vague. “As a user, I want to manage my profile.” Manage how? What fields? What validation? What happens on save? What does the error state look like? Nobody specified. The developer picks up the story, realizes half the details are missing, and now has a choice: interrupt the PO (if one exists), make assumptions and keep building, or let the story sit while they wait for answers. All three cost you time. The first two cost you quality.

Refinement is theater. The meeting happens. Everyone stares at stories nobody’s read. Someone asks a question nobody can answer. The PO says “I’ll follow up.” The story enters the sprint with the same gaps it had going in. The developers figure it out as they go. Or they don’t, and it carries over.

Developers become the PO by default. This is the one that hurts the most. When nobody defines the requirements, the developer defines them while coding. They make product decisions they’re not qualified to make. Not because they’re not smart, but because they don’t have the business context. They build what makes sense technically. It often doesn’t make sense to the user. And now you’ve taken your most expensive resource, a developer’s time, and spent it on work that a PO should have done before the sprint started.

Sprint completion craters. Teams without strong product ownership consistently underdeliver. Not because the developers are slow. Because the work wasn’t defined well enough to be completable. You can’t finish building something when nobody told you what “done” looks like. The sprint ends, half the stories carry over, and leadership asks “why is the team so slow?” The team isn’t slow. The inputs were broken.

Rework becomes a way of life. “That’s not what I meant” becomes the most common phrase in sprint review. Features get built, demoed, rejected, and rebuilt. The team’s velocity looks decent on paper because they’re burning points. But a third of those points are rework on stories that should have been right the first time. You’re paying for the same feature twice and calling it productivity.

Every one of these problems traces back to the same gap: nobody owned the translation from business need to developer-ready requirement. That’s the product owner’s job. And when it’s not being done, the cost shows up everywhere except the line item that would explain it.

The Translation Layer

The product owner’s core function is translation. They operate at the boundary between two groups that speak fundamentally different languages.

On one side: business stakeholders who think in terms of outcomes, revenue, customer experience, and competitive positioning. They know what they want the software to do but not how to express it in terms a developer can act on.

On the other side: developers who think in terms of data models, API contracts, state management, and edge cases. They know how to build things but often lack the context to know whether what they’re building is the right thing.

The product owner bridges that gap. They take “we need better reporting for our enterprise clients” and turn it into stories with specific screens, specific data, specific user flows, specific acceptance criteria. They ask the questions developers shouldn’t have to ask: “What does ‘better’ mean? Which clients? What metrics? What format? Who sees it? How often? What’s the export requirement?”

When this translation is done well, developers get stories they can estimate confidently, build correctly on the first pass, and deliver within a sprint. When it’s done poorly, or not done at all, developers get wishes dressed up as requirements.

Two Trios

Scrum defines a well-known trio: product owner, scrum master, and development team. That’s the core unit. The PO defines what to build, the scrum master protects the process, the dev team builds it.

But there’s another trio that’s just as important and rarely discussed: product owner, dev manager, and QA manager.

This is the trio that ensures quality at every stage:

The product owner defines what “done” looks like. The acceptance criteria, the edge cases, the business rules. They own the input quality: the specificity and completeness of the requirements that enter the sprint.

The dev manager ensures the team can deliver. Capacity planning, technical guidance, impediment removal, code quality. They own the throughput: making sure the team has what it needs to build the right thing at the right pace.

The QA manager validates that what was built matches what was defined. Test strategy, regression coverage, edge case verification. They own the output quality: confirming the delivered software meets the acceptance criteria the PO wrote.

When all three are working together, you get a pipeline: well-defined requirements go in, quality software comes out, and QA can verify it objectively because the acceptance criteria were specific enough to test against. When any one of them is missing or weak, the pipeline breaks. And most often, the one that’s missing is the PO.

Why Companies Skip It

The product owner is the easiest role to cut because the damage is diffuse.

When you don’t have enough developers, things don’t get built. That’s visible. When you don’t have QA, bugs hit production. That’s visible. When you don’t have a scrum master, meetings get chaotic. That’s at least noticeable.

When you don’t have a product owner, the symptoms are everywhere but the cause is nowhere. Sprint completion is low, but that could be an estimation problem. Rework is high, but that could be a quality problem. Developers seem slow, but that could be a skill problem. Stakeholders are frustrated, but that could be a communication problem.

All of those are actually a requirements problem. And requirements are the product owner’s job.

The other reason companies skip it: the PO doesn’t write code. In organizations that measure value by output (features shipped, lines written, tickets closed), the person who makes sure the right things get built doesn’t show up in the metrics. They’re overhead. They’re “process.” They’re the role that gets absorbed into a dev manager’s already-full plate or assigned to a business analyst who does it part-time between other responsibilities.

And then everyone wonders why the team can’t seem to ship the right thing.

What Good Product Ownership Looks Like

I’ve seen this done well. I’ve also built the systems to make it repeatable.

When I was at PlanetDDS, the CTO asked me to build a presentation for their product owners on how to write stories that developers could actually use. I called the concept “prefinement”: the work a PO does before a story is ever seen in a refinement session.

The depth of that work is what most people outside the role don’t appreciate. A good PO isn’t just writing a sentence in a Jira ticket. They’re thinking through CRUD-alignment: does this story center on a single verb, or has scope creep given it two? They’re identifying every form element and input type on the screen. They’re defining validation rules for every field: what’s invalid, what message appears, does it block the action? They’re mapping screen flow: is this a collection view or a detail view, and how do they connect? They’re considering multi-state behavior: when a user’s action leads to different controls appearing, should that be one story or three?

And that’s just the prefinement. Then they’re structuring the story itself: titles that speak to the deliverable rather than the task steps, descriptions that describe the user journey rather than database changes, acceptance criteria that are numbered, grouped, and categorized by type: screen events, UI definitions, user actions, user feedback, and validation rules.

That level of detail is what separates a story a developer can build from a story a developer has to interrogate. It’s the difference between refining a story in ten minutes or having an hour of back-and-forth questions that should have been answered before the meeting started.

The refinement standard I use: a story is fully refined when:

The purpose of the story is clearly understood and documented.
The acceptance criteria are clearly understood and documented.
The story could be parked in the backlog for six months, pulled during planning, and developers would still know exactly what needs to be done.

That’s a high bar. But every team I’ve worked with that hits it sees the payoff immediately: in sprint completion, in reduced rework, and in developer confidence.

I believe in this enough that I’ve turned the entire methodology into a pipeline of open-source AI skills that my product management team uses every day: feature writing, story splitting, story writing, and story prefinement, all chained together. A product owner can go from “I have an idea” to fully refined, developer-ready stories in under an hour. Solo. No meetings.

But the tools aren’t the point. The point is that this level of craft exists in the PO role. It’s real, it’s deep, and most organizations have no idea how much skill it takes to do well, or how much it costs them when it’s not being done.

The Planning Multiplier

Here’s the math that every executive skipping the PO role should see.

A well-written story with clear acceptance criteria takes a developer half a sprint to build and passes QA on the first review. Total cost: one story’s worth of effort.

A vague story with missing details takes the same developer half a sprint to build something that turns out to be wrong. Rework takes another quarter sprint. QA finds issues that send it back. Another round of fixes. Total cost: two to three times the original effort. And it still might not be right.

Now multiply that across every story in every sprint. A team running twenty stories per sprint with a 30% rework rate is burning six stories’ worth of capacity on work that should have been right the first time. That’s nearly a third of the team’s output lost to a gap that one dedicated product owner would fill.

The PO doesn’t show up in velocity metrics. But the absence of a PO absolutely does. It just shows up as low completion rates, high rework, missed commitments, and stakeholder frustration. The cost is real. It’s just attributed to the wrong causes.

The Decomposition Dividend

There’s one more thing a good PO does that ripples through the entire delivery pipeline: they make stories small.

Not artificially small. Properly small. Stories scoped to a single CRUD verb, a single user action, a single deliverable. The kind of story a developer can pick up in the morning and have in code review by lunch.

When stories are small, everything downstream gets better:

Development is faster. A small, well-scoped story has fewer unknowns. The developer isn’t discovering requirements while coding. They’re building to a clear spec. Less context to hold in their head. Less ambiguity to resolve. Less time staring at a ticket wondering where to start.

Pull requests are smaller. A story scoped to one user action produces a PR that touches a handful of files, not fifty. Code reviewers can actually read it. They can understand the intent, catch real issues, and approve with confidence. Review goes from a bottleneck to a ten-minute task.

Releases happen more often. Small stories finish faster. Finished stories can ship. When your team is completing and shipping multiple stories per sprint instead of dragging one massive story across the finish line at the last minute, you’re releasing continuously, not batching. Stakeholders see progress. Users get value. The feedback loop tightens.

Risk shrinks. A small release that breaks something is easy to diagnose and easy to roll back. A giant release that breaks something could be anything. Small stories, small PRs, small releases. The blast radius of any single mistake stays manageable.

This is the compounding effect of good product ownership. The PO’s decision to properly decompose a feature into right-sized stories doesn’t just help planning. It makes development faster, code review easier, releases more frequent, and production safer. One role, upstream of everything, multiplying the effectiveness of every role downstream.

The AI-Enabled PO

Here’s what makes this moment in time so exciting for product owners: AI just removed the excuse.

The most common objection I hear from organizations that skip the PO role is that the work takes too long. Gathering requirements, writing detailed stories, specifying every input and validation rule, checking CRUD alignment, reviewing acceptance criteria for completeness. It’s a lot. For a single PO supporting one or two dev teams, the story pipeline becomes a full-time job. For organizations that expect a PO to also be a project manager, a stakeholder liaison, and attend every meeting on the calendar, there simply aren’t enough hours.

AI changes that math completely.

A product owner equipped with the right tools can now do the detailed, repetitive parts of story preparation in a fraction of the time. The guided interview to capture a feature’s requirements? Twenty minutes instead of three meetings. The decomposition into properly sized stories? Minutes instead of hours. The detailed acceptance criteria with validation rules, error messages, and user feedback? Generated from the interview, reviewed by the PO, refined in real time.

The parts that AI handles well are exactly the parts that used to make PO work feel unsustainable at scale: the volume of writing, the consistency checking, the gap analysis, the formatting. The parts that AI can’t handle are exactly the parts that make a PO valuable: the business context, the stakeholder relationships, the judgment calls about what matters, the ability to sit in a room and hear what someone means even when it’s not what they said.

An AI-enabled PO isn’t a cheaper PO. It’s a PO who can support more teams at higher quality. A PO who spends their time on strategy and stakeholder alignment instead of typing acceptance criteria. A PO who can produce stories with the level of detail I described in the prefinement section (CRUD alignment, validation rules, screen flow, multi-state behavior) for every story, every sprint, without it being a heroic effort.

The role didn’t get less important. It got more scalable. And for organizations that have been telling themselves they can’t afford a dedicated PO, that objection just evaporated.

A Celebration, Not a Complaint

I’ve written a lot of posts about what goes wrong in software teams. This one is different.

This is a celebration of the people who do this work well. The product owners who spend hours defining requirements so developers can spend minutes clarifying them. The ones who push back on vague requests from stakeholders and translate them into something buildable. The ones who treat acceptance criteria like a contract, not an afterthought.

The teams I’ve turned around all have one thing in common: the moment someone started owning the product owner role with discipline and dedication, the team’s output changed. Not because the developers got better. Because the developers finally knew what to build.

If you’re a product owner reading this: your work matters more than your organization probably tells you. The sprint completion rates, the low rework, the developer confidence, the stakeholder satisfaction. That’s all downstream of what you do. You are the reason the right thing gets built.

If you’re a leader reading this: invest in this role. Hire for it. Train for it. Protect it. Don’t make it someone’s side job. Don’t assume developers can self-organize their way to good requirements. Give them a product owner who knows how to translate, decompose, and specify, and watch what happens to your team’s delivery.

The product owner is the most leveraged role on any software team. It’s time we started treating it that way.