From Stakeholder Request to Sprint Backlog: How I Run Requirements Engineering as a Product Owner
There's a version of the Product Owner role that is essentially a ticket factory. Stakeholders request things, the PO writes them up, the sprint starts, the sprint ends, the cycle repeats. The backlog grows. Nobody is quite sure why certain things are at the top.
I've worked in that version of the role. It doesn't work — not because the process is wrong, but because the process is operating without the step that makes it meaningful: the translation layer between what stakeholders want and what goes into the sprint.
That translation layer is requirements engineering. And in my experience, it's the difference between a PO who is a backlog administrator and one who is a product thinker.
The PO's Core Problem
The Product Owner sits at the intersection of three competing forces: business stakeholders who want outcomes, engineering teams who need specificity, and a backlog that has to reconcile both into a prioritized, executable sequence.
The tension is structural. Stakeholders think in outcomes ("we need better conversion") and often arrive with solutions already formed ("we need a new checkout flow"). Engineers think in systems and constraints ("the payment gateway integration will take three weeks regardless of what the flow looks like"). Neither representation is wrong — they're just operating at different levels of abstraction.
The PO's job is to hold both representations simultaneously and translate between them. Not to pick a side, and not to simply relay messages. To convert.
My Process: From Request to Ready
Here's how I move a stakeholder request from initial conversation to sprint-ready backlog item. This is the process I've run across MoveUp Media, consulting engagements, and projects at Griaule — adapted to context but consistent in structure.
Stage 1: Outcome extraction
When a stakeholder brings a request, my first move is always backward — away from the solution they've described and toward the problem they're trying to solve.
The question I use: "If this works exactly as you're imagining it, what's different about your week six months from now?"
This is not a stalling tactic. It's the most important question in the process. A stakeholder who says "we need a new dashboard" is describing a solution. The actual problem might be "I keep getting blindsided in steering committee meetings" — which is a latency and visibility problem, not a UI problem. The dashboard might be the right solution. It might not be. You can't know until you've asked the question.
I do this in a structured conversation, not a formal meeting. The goal is to come away with a clear statement of the desired outcome in business terms — specific enough to evaluate solutions against, but not so specific that it pre-selects the implementation.
Stage 2: Backlog translation
Once I have the outcome, I translate it into a backlog item. My format:
User story: "As a [role], I want [capability], so that [outcome]." Written from the perspective of the person who will use the thing, not the person who requested it — these are sometimes the same person, often not.
Acceptance criteria: Three to five testable conditions in "Given / When / Then" format. If I can't write testable acceptance criteria, the story isn't ready.
Constraints and dependencies: What this story depends on, what it blocks, and any technical constraints that engineering flagged during refinement.
Size indicator: A rough complexity signal (not hours — relative size compared to other stories the team has shipped).
The acceptance criteria step is where most backlog items fall apart. "The dashboard loads quickly" is not an acceptance criterion. "Given a user on a standard connection, when they open the dashboard, then it renders in under 2 seconds" is. The difference matters enormously in sprint review — you either met the criterion or you didn't. There's no ambiguity.
Stage 3: Refinement
Before a story enters a sprint, it goes through backlog refinement with the engineering team. This is not a status update — it's a collaborative review. I'm looking for three things:
Does the engineering team understand the story well enough to estimate it?
Are there technical constraints or dependencies that the acceptance criteria don't account for?
Is the scope right, or does this story need to be split?
Stories that come out of refinement unchanged are usually stories where not enough real conversation happened. The value of refinement is in the edits — the acceptance criterion that needed rewording, the dependency that wasn't visible until an engineer asked a specific question, the story that was actually three stories in a trench coat.
Stage 4: Prioritization
Prioritization is where PO work gets political. Everyone has a theory of what belongs at the top of the backlog, and most of those theories are correlated with whose work it would be.
My approach: I prioritize based on explicit criteria, applied consistently, visible to all stakeholders. The criteria I use most often:
Business impact — which items directly move the metrics that matter to the business right now?
User impact — which items affect the most users, or affect a small number of users most severely?
Strategic fit — which items advance a stated product or company direction?
Cost of delay — what gets worse if this waits another sprint?
Dependencies — what is blocking other high-value work?
These criteria don't eliminate prioritization debates — they redirect them. Instead of "I think X is more important than Y," the conversation becomes "X scores higher on cost of delay but lower on business impact; here's my reasoning for the trade-off." That's a conversation with a resolution. The first version isn't.
What This Looks Like at MoveUp
At MoveUp Media, I own the delivery backlog for a portfolio of 30+ websites across 20+ international markets. The stakeholder landscape is complex: commercial teams in multiple countries with different product needs, engineering constraints that vary by platform, and a team that grew from 2 to 8 people during my tenure — each addition changing the capacity equation.
The requirements engineering process above is what makes that complexity manageable. Not because it eliminates the competing requests — it doesn't — but because it gives every request a common format that can be evaluated on the same terms.
A commercial stakeholder in one market requesting a feature can't reasonably be compared to a technical debt item from engineering until both are expressed in terms of business impact, user impact, and cost of delay. Once they are, the prioritization conversation changes from "whose request matters more" to "which item has the highest value given our current constraints."
That shift — from subjective to structured — is the core of what the PO role is for. And it requires requirements engineering to be done properly, not as an afterthought.
The Part Most PO Resources Skip
Everything above is a process. Processes are learnable and repeatable.
What's harder to teach is the discipline of saying "this story isn't ready" when there's sprint pressure to just start building. Every team has a version of this moment: the sprint is starting, the backlog item is in the "ready" column, but the acceptance criteria are still vague and refinement surfaced three unresolved dependencies.
The temptation is to let it into the sprint and figure it out mid-sprint. I've made that call. It consistently produces the same outcome: the story comes back in sprint review partially done, with a debate about whether "done" was achieved, and with the unresolved dependencies now blocking the next sprint.
The harder and more correct call is to pull the story, resolve the ambiguities, and bring it back to the next sprint properly prepared. This feels like slowing down. It is, in the immediate term. It is also the only thing that actually speeds up delivery over time.
The Product Owner's job is to protect the sprint from unready work as much as to fill it with valuable work. Both directions of the filter matter.