Proxy PO vs. Real Customer Involvement

---

The Original Intent

The Scrum Guide describes a single Product Owner who is "accountable for maximizing the value of the product." In Kent Beck's original XP, the equivalent role was the on-site customer — a real customer, physically present, available to answer questions. Both formulations assumed something most modern teams never have: a direct line to the people who will use the product.¹

In practice, most "Product Owners" are internal employees serving as proxies for the actual customer. They synthesize input from many users, prioritize on behalf of the business, and make trade-offs the team can't make alone. Whether this is acceptable or a compromise depends on the team.

The Case for Proxy POs

• Scalable across many users. A consumer product cannot have its actual users available daily. A proxy compresses thousands of users into one decision-maker.
• Internal expertise. Good proxy POs accumulate deep product knowledge, cross-team context, and strategic perspective real users typically lack.
• Continuous availability. Real customers have day jobs. Proxy POs are available to the team every day.
• Mediation of conflict. When multiple customers want different things, the proxy makes the trade-off. Real customers, all in the room, would deadlock.

How Proxy POs Fail

• Telephone game. Customer needs → research → PO → team. Each translation loses fidelity, and after a few cycles, what the team builds bears little resemblance to what the customer needed.
• Bias toward defensible decisions. Internal POs are accountable to internal politics. The decision that survives the next leadership review often beats the decision that serves the customer.
• The team loses customer instinct. Developers without customer contact build for the PO, not the user. They optimize for the wrong audience.
• The PO becomes a single point of failure. When the PO is sick, on vacation, or under-resourced, the team stops.

The Case for Real Customer Involvement

• Direct feedback loop. The team sees the customer's reaction to the actual product, not the PO's interpretation of it.
• Domain learning. Developers absorb the customer's vocabulary, workflow, and constraints. The product gets sharper as a result.
• Faster correction. When the build is wrong, the customer surfaces it in days, not months.
• Empathy. Teams that meet their customers regularly build better products. The literature is consistent on this.²

How Real Customer Involvement Fails

• Loud customer overweighting. The customer most willing to spend time with the team often isn't the most representative one. Their preferences distort the roadmap.
• Feature requests trump strategy. Real customers tend to ask for specific features. Without a synthesizing role, the product becomes a feature list, not a coherent design.
• Conflict. Multiple real customers want incompatible things. Without a decision-maker, the team becomes a referee.
• Time burden. Real customer involvement costs real customer time. Customers may agree in principle but withdraw in practice.

The Synthesis Most Healthy Teams Reach

The honest answer is: both. A proxy PO who is also continuously exposed to real customers is materially better than either pure form.

• The PO synthesizes and prioritizes, but does not substitute for customer contact.
• The team has regular, direct exposure to real users — through interviews, observational research, customer-support shadowing, or beta-tester groups.
• The PO is present during customer sessions, not only as a translator after them.

Marty Cagan's work on product management is unambiguous on this: the best product owners are not gatekeepers between the team and customers; they are travel companions on the team's customer journey.³

The Deeper Question

This debate hides an organizational question: is your company set up to let the team see the customer? Many enterprises have layers of account managers, sales engineers, customer success, and support that interpose between developer and user. The proxy PO is often a symptom of that organization, not a choice. Fixing the proxy problem usually requires fixing the structural one — and that is a much bigger lift than swapping a role.

Coaching Tips

Count team-to-customer touchpoints.

How many times last month did engineers see a real customer? If the answer is zero, that's the problem — not the PO.

Rotate engineers through support.

An afternoon a quarter on the support queue produces more customer empathy than any persona document.

Bring users to refinement.

Even one user in one refinement session per month changes the conversation. Make it a recurring slot.

Watch for "the customer said" without evidence.

If POs claim customer needs without ever showing the team the actual research, the proxy is operating as a single source of truth.

Avoid loud-customer skew.

The customers most willing to talk are not always the most representative. Look for the silent majority through analytics, not interviews alone.

Name the structural problem when you see it.

If account managers won't let engineers near customers, the issue is org structure, not method. Surface it to leadership.

Summary

The proxy PO is a pragmatic answer to a problem most organizations actually have: real customers are not available every day. The mistake is treating that pragmatism as the goal rather than the compromise. Healthy teams use proxy POs but refuse to let them be the only customer contact. The deepest predictor of product quality is not who the PO is — it is whether the engineers who write the code have ever watched a real customer use the product.

Back to The Great Agile Debates