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.
The Symptoms
Before I go further, answer these honestly:
Do developers ask more questions during development than during refinement? Do stories routinely carry over because the details were not settled? Do sprint reviews include some version of “that’s not what I meant”? Do developers make product decisions while coding because the story did not specify the answer?
If those patterns are familiar, you probably 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, a developer speed problem, or a communication problem. Very often, they have a requirements problem, and the person responsible for requirements is either missing, part-time, or untrained.
What Bad Requirements Cost
When a team doesn’t have a dedicated, skilled product owner, here’s what happens. See if any of this sounds familiar.
Stories become 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 becomes theater. The meeting happens. Everyone stares at stories nobody has 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, and 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 without the business context to make those decisions well. They build what makes sense technically. It often does not make sense to the user. Now you have taken your most expensive resource, a developer’s time, and spent it on work that should have happened before the sprint started.
The sprint pays the bill. Work carries over, rework becomes normal, stakeholders get frustrated, and leadership starts asking why the team is slow. The team may not be slow. The inputs may be broken.
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.
The Delivery Partnership
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.
At a healthcare SaaS provider, 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 Delivery Multiplier
At the healthcare SaaS provider, software delivery was slow when I arrived because stories were oversized and under-specified. Refinement reflected that problem. The team could get through about three stories in an hour. That was not because people were lazy or because the developers were being difficult. The stories were not ready for the conversation they were being brought into.
I initially took over the product owner role myself because the function had to exist before the team could stabilize. Once we tightened the prefinement work, refinement changed. The team could refine 13 to 15 stories in the same hour because the open questions had already been forced to the surface. The stories had clearer verbs, cleaner boundaries, better acceptance criteria, and fewer hidden decisions.
Later, we hired an excellent product owner who was aligned with the patterns and practices I had already put in place. He kept the team supplied with quality features and stories throughout our shared tenure there.
That mattered downstream. Under my direction, that team shipped 63 releases in 52 weeks and incrementally delivered a major reporting dashboard feature instead of waiting for one giant release to be perfect. Product ownership did not magically make the developers faster. It gave them better-shaped work, better sequencing, and fewer hidden decisions. It made the whole system more shippable.
That is the multiplier executives usually miss. The PO does not show up in velocity metrics, but the quality of product ownership absolutely does. It shows up in refinement speed, sprint completion, release frequency, rework, stakeholder confidence, and developer morale.
Small Stories Change Everything
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, and reviewing acceptance criteria for completeness is a lot. For a single PO supporting one or two dev teams, the story pipeline can become a full-time job.
AI changes the labor profile of that work.
A product owner equipped with the right tools can now do the detailed, repetitive parts of story preparation in a fraction of the time. A guided interview can capture the feature’s requirements. A story splitter can decompose the work into properly sized stories. A story writer can generate acceptance criteria, validation rules, error messages, and user feedback from the interview. The PO still reviews, corrects, and applies judgment.
The parts 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, and the formatting. The parts 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, and the ability to hear what someone means even when it is not what they said.
An AI-enabled PO is not a cheaper PO. It is a PO who can support more work at higher quality. A PO who spends more time on strategy and stakeholder alignment instead of typing acceptance criteria. A PO who can produce stories with CRUD alignment, validation rules, screen flow, and multi-state behavior without making that level of detail 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. Developers still had to write good code. QA still had to verify the work. Managers still had to protect the system. But the team finally had better inputs.
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.
Receipts
- Healthcare SaaS provider: Refinement improved from about three stories per hour to 13 to 15 stories per hour after stronger prefinement practices were introduced.
- Release cadence: Under my direction, the same team shipped 63 releases in 52 weeks while incrementally delivering a major reporting dashboard feature.
- Open-source tooling: The prefinement methodology has been turned into a pipeline of AI skills for feature writing, story splitting, story writing, and story prefinement.