Product Owner vs. Proxy Product Owner
In short In many agile teams the product owner cannot be with the team every day, so a proxy product owner, often a business analyst, acts as their day-to-day voice. The arrangement works only if both sides agree who decides what. This page gives a practical split of responsibilities.
Based on: business analysis training materials (PO/PPO responsibility matrix); IIBA, BABOK® Guide v3, section 11 (Agile perspective).
On this page
Key ideas#
Why the proxy role exists#
The BABOK® Guide’s agile perspective notes that the analysis role in an agile team may be played by a product owner, a product manager, a business analyst or another role. In practice, product owners are often senior business people with limited time. A proxy product owner (PPO) fills the gap: available to the team daily, but acting on behalf of the product owner (PO), who keeps ownership of the product’s direction.
What the product owner keeps#
A responsibility matrix used in business analysis training groups the PO’s duties into five areas:
- Ownership. Decides what gets built and in what order; owns the product vision, strategy, roadmap and backlog.
- Direction. Sets goals for the project and releases, understands budget and constraints, tracks progress.
- Requirements. Defines themes and epics (the “what”), assesses the impact of new business requests, reviews and approves user stories, acceptance criteria and the definition of done.
- Team integration. Acts as the knowledge source for the PPO, takes part in planning, refinement and reviews, sets the sprint goal, and accepts or rejects results.
- Coordination. Manages expectations upward and downward, supports user acceptance testing and training of business users, works with other IT teams and stakeholders, resolves conflicts.
What the proxy product owner does#
The same matrix gives the PPO four areas:
- Communication. Escalates questions to the PO, acts as the PO’s voice day to day, makes sure the team understands the requirements.
- Requirements. Breaks epics into user stories for the sprint backlog, writes detailed acceptance criteria, clarifies questions daily, elicits detailed requirements from business stakeholders.
- Supporting the PO. Runs business demos, does sanity checks in test and production environments, aligns the sprint goal with the PO.
- Part of the team. Helps deliver the product, prepares technical artifacts, works with testers on test scenarios.
The pattern is clear: the PO owns direction and decisions; the PPO owns detail and availability.
How to apply it#
- Agree the split in writing at the start. Use the template below. Go through it line by line with the PO and the team.
- Define the PPO’s decision limits. For example: the PPO may reorder stories within a sprint goal, but any change to the sprint goal or release scope goes to the PO.
- Set an escalation rhythm. A fixed weekly slot with the PO, plus a same-day channel for blockers.
- Keep the PO visible. The PO should still attend sprint reviews and accept results; otherwise the team loses contact with the real decision maker.
- Review the split after a few sprints. Adjust where decisions are bottlenecked or where the PPO is deciding without authority.
Template#
| Responsibility | PO | PPO | Notes |
|---|---|---|---|
| Product vision, roadmap | Owns | Contributes | |
| Backlog order (release level) | Decides | Proposes | |
| Epics and themes | Defines | Refines | |
| User stories and acceptance criteria | Approves | Writes | |
| Daily clarification for the team | Escalation only | Owns | |
| Sprint goal | Sets | Aligns with PO | |
| Sprint review: accept or reject | Decides | Demonstrates | |
| Detailed elicitation with business users | Supports | Owns | |
| UAT and business-user training | Owns | Supports | |
| Test scenarios with QA | — | Owns | |
| Stakeholder conflicts | Resolves | Escalates | |
Example#
At The Workshop, a fictional chain of 12 bike-repair workshops, the owner is the product owner for the new booking and notification system but spends most days visiting workshops. The business analyst becomes the PPO for the outside development team. They agree:
- The owner decides release scope: online booking first, status notifications second, parts ordering later.
- The analyst writes the stories and acceptance criteria, answers developers’ questions daily, and demonstrates each sprint’s work to the owner on Friday afternoons.
- Any story that would change what customers pay or how bookings are confirmed goes to the owner before it enters a sprint.
Pitfalls#
- A proxy without authority. If the PPO must escalate every small question, the team stalls. Give clear decision limits.
- A PO who disappears. When the PO stops attending reviews, the PPO becomes the de facto owner without the mandate.
- Silent priority changes. A PPO who quietly reorders the backlog undermines trust with the PO. Make changes visible.
- Two voices. If the PO and PPO give the team conflicting answers, agree that one channel is authoritative for each type of question.
Sources and further reading#
- Business analysis training materials (practice examples and templates): product owner / proxy product owner responsibility matrix.
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Section 11.1 (Agile perspective).