Proxy Product Owner by Accident
Harlow is a business analyst in a government digital service building a permit-application service. Over eight months she has become the only person who talks to users. Three groups - small applicants, agents who file on behalf of clients, and internal caseworkers - give her input, which she turns into user stories. The development team has not spoken to a user since month one. The product owner, a senior civil servant, attends sprint reviews but delegates all requirement decisions to Harlow. She now writes around 60 stories a quarter on her own. At the last release, 35% of UAT defects were logged as does not meet user need, and the service failed an accessibility audit on the application form. Her manager's response is that she should tighten the specifications and add more detail to the acceptance criteria.
1. What is the underlying problem, and which agile business analysis principles are being violated?
Read the worked answer
Harlow has become a proxy product owner and a single point of failure. The team's understanding of users is now a second-hand interpretation delivered through one person, which is a lossy channel and a bottleneck: at 60 stories a quarter nothing else can scale, and no one else can challenge her reading of the need.
The principle being violated is that business people and developers work together, reinforced by the idea that analysis is a collaborative activity rather than a document-producing one. Direct feedback loops have been replaced by a hand-off. The 35% of UAT defects marked does not meet user need are the measurable consequence: they are not specification defects, they are validation failures. The accessibility failure follows the same pattern, since the form was almost certainly never tested with assistive technology users and accessibility was not treated as a standing constraint.
Adding detail to acceptance criteria would make Harlow's interpretation more precise without making it more correct. The manager is asking for a better-quality bottleneck. There is also a governance problem: the product owner holds accountability but has delegated engagement, so no one with authority is close enough to the work to decide well.
2. What would you change in the next four weeks, concretely?
Read the worked answer
Reopen direct contact first. Two team members, a developer and a tester, rotate into a 30-minute user research session each week; sessions are recorded and clips shared with the whole team. One caseworker is invited to sprint review as a participant, not an observer.
Replace solitary story-writing with collaborative refinement: a 45-minute three-amigos session per story, with developer, tester and BA, plus a user or caseworker where possible. Acceptance criteria are co-written in that session, and every story touching the application form carries accessibility criteria derived from WCAG 2.2 AA as an organisational constraint, not as a separate accessibility story.
Recruit at least two users of assistive technology to test the form this sprint, so the audit finding is addressed by evidence rather than by a claim in a document, and add an accessibility check to the definition of done. Triage the 35% of UAT defects into misunderstood need, genuine defect, and changed need, and use that breakdown with the product owner. Finally, reduce Harlow's output on purpose, aiming at roughly 20 to 25 well-understood stories a quarter that the team helped shape, and track cycle time and defect origin to show whether the change works.
3. How do you bring the product owner into the loop without undermining their authority?
Read the worked answer
Assume the problem is time and exposure rather than intent, and design around that. Offer a weekly 30-minute decision forum with a one-page options paper circulated beforehand: the product owner chooses, rather than researches. Ask them to own prioritisation and outcome measures explicitly, and to attend at least one user research session a month so their decisions rest on first-hand evidence.
Make the cost of absence visible without turning it into a complaint: median decision latency, defects traced back to unvalidated assumptions, and the number of stories blocked pending a decision. Those numbers let the product owner see the trade-off they are making.
Clarify decision rights in writing: the product owner owns what and why, the team owns how, the BA owns analysis quality and facilitation of shared understanding. If the product owner genuinely cannot engage, the BA should escalate with that evidence rather than silently absorbing accountability without authority. Taking on the product owner's decisions protects the project for a sprint and damages it over a year, because nobody with authority is close enough to correct course.