The Product Owner Who Runs Fourteen Branches
Meridian Bank is building a mobile account-opening journey. The product owner is a branch operations manager who also runs 14 branches; she gives the team about three hours a week, and decisions take on average eight working days. A financial-crime risk SME sits in another country, declines all stand-ups and refinement invitations, and sends policy documents instead. A contact-centre team leader attends every session, is the most vocal participant, and has no authority to approve anything. Each sprint ends with at least one story parked waiting for sign-off. The team is seven people running two-week sprints; across the last three sprints they delivered 40% of the scope they committed to. The programme manager has told the BA to write the requirements properly and get them signed off so the team can just build.
1. Diagnose the collaboration failure. What is the actual constraint here, and why is the programme manager's instruction unlikely to help?
Read the worked answer
The constraint is decision throughput, not requirement quality. The 40% delivery figure and the parked stories are symptoms of decisions queueing, not of the team building the wrong things slowly.
Map the stakeholders on influence and interest, then look at decision rights. The product owner holds accountability but has almost no available time, so every decision waits for her. The financial-crime SME holds an effective veto over a whole class of rules but sits outside the loop, so those risks surface late and expensively. The contact-centre lead has high interest and high visibility but no authority, so airtime is consumed without producing decisions. The BA is the only person connected to all four groups, which makes the BA the integration point and the bottleneck simultaneously.
The programme manager's instruction treats the output (documents) rather than the constraint (decisions). Producing a more detailed specification for the PO to sign off adds queue time and still leaves the SME outside, so risk is discovered later, at higher cost. It also runs against the principle that business people and developers work together, replacing contact with a hand-off. Writing is not the problem to solve.
2. Propose a concrete decision-rights model and cadence, with numbers you would publish.
Read the worked answer
Classify decisions by type and assign them deliberately. Financial-crime policy rules: the SME is accountable, but must name a deputy with real authority and guarantee a two-day response, or take part in a 30-minute weekly rule clinic. Journey and user-experience trade-offs: the product owner decides at a weekly 45-minute decision forum with the BA, tech lead and contact-centre lead, the latter in an advisory role. Implementation approach: the team decides, without escalation.
Publish a decision log with owner, date raised, due date and outcome. Set a service level of 90% of decisions resolved within two working days, and show median decision age as a tracked metric next to velocity, because that is the number the programme manager needs to see.
Reduce the product owner's load rather than her authority: send a one-page set of options with a recommendation and a deadline 24 hours before the forum, so she chooses instead of researching. Do not try to force the SME into daily events; redesign the interface to match the constraint, by giving her a monthly policy review plus the rule clinic. This is a design change to collaboration, not a request for more commitment.
3. The contact-centre team leader is vocal but has no approval authority. How should the BA handle this without losing their input?
Read the worked answer
Treat them as a valuable source of user evidence and a governance risk at the same time. They probably know more about real customer pain in this journey than anyone in the room, so suppressing them loses signal; but letting them set the agenda means the backlog reflects one stakeholder's opinions while decisions stall.
Give them a defined role rather than an undefined voice: owner of the contact-centre impact assessment for any story touching account opening, consulted on those stories, and a named invitee at sprint review. State explicitly which decisions they own, which is likely none, and which inputs they are accountable for supplying. Use facilitation techniques that structure contribution - silent written brainstorming, dot voting, round-robin - so airtime does not equal influence, and step in when they answer questions directed at the product owner.
Watch two failure modes. A stakeholder who is consulted but never heard tends to escalate at UAT, which is where late blocking appears. And the BA must check whether their confident opinions are being written into stories as user need; pair their input with call recordings, contact reasons data or observation of actual applicants before it becomes an acceptance criterion.