The On-Site Customer

XP originally called for an on-site customer—a real user or their representative, physically present with the team.

Why so extreme?

Software development is constant decision-making:

• How should this edge case behave?
• Which of these two designs is better for users?
• Is this bug worth fixing or a known limitation?
• What's more important: feature A or feature B?

If the customer isn't available, developers guess. They guess wrong. They build the wrong thing. Or they wait, blocking progress until they can get an answer.

Available customers:

• Unblock decisions in minutes, not days
• Catch misunderstandings early
• Make priority calls in context
• Build trust through close collaboration

The XP customer role comes with both rights and responsibilities.

Customer rights:

• Know the estimated cost of each story
• Know the team's velocity and when things will be done
• Change priorities at any time (within iteration boundaries)
• Cancel the project and get a working system (whatever's been done)
• See progress through working software, not just reports

Customer responsibilities:

• Be available to answer questions quickly
• Make priority decisions when asked
• Provide acceptance criteria for stories
• Accept trade-offs when scope exceeds capacity
• Give feedback on delivered software promptly

This is a partnership. The customer isn't a distant stakeholder throwing requirements over the wall. They're a team member making decisions daily.

In practice, the "real customer" is often unavailable. They have jobs. They can't sit with developers all day.

Enter the product owner proxy—someone who represents the customer:

• Product managers
• Business analysts
• Product owners (Scrum terminology)
• Internal subject matter experts

The proxy model works when:

• The proxy truly understands user needs
• The proxy has authority to make decisions
• The proxy is genuinely available (not double-booked)
• Real customers provide regular input (demos, feedback sessions)

The proxy model fails when:

• The proxy doesn't understand the domain
• The proxy can't make decisions without escalation
• The proxy is too busy to be available
• Real customers never see the software

Acceptance tests are how customers and developers verify they understand each other.

For each story, the customer defines acceptance criteria:

• Given [this context]
• When [this action happens]
• Then [this should be the result]

These become executable tests. When the tests pass, the story is done. No debate about whether it's "really done."

Benefits:

• Unambiguous requirements (if the test passes, it works)
• Living documentation (tests describe what the system does)
• Regression safety (tests catch when behavior changes)
• Customer engagement (writing criteria requires thinking)

In modern XP, acceptance tests are often written in collaboration between the customer and developers. The customer describes the behavior; developers help translate to testable form.

Modern teams are often distributed. The "on-site" customer is a Slack channel, a Zoom call, or an async message.

Making it work remotely:

• Overcommunicate (assume nothing is obvious)
• Use video for face-to-face interaction when possible
• Create low-friction ways to ask questions (chat over email)
• Record decisions so they're findable later
• Respect time zones (don't expect instant answers at 3 AM)

Async customer involvement:

• Write clear questions with context
• Offer options rather than open-ended questions
• Set expectations for response time
• Use documents for complex decisions (easier to review async)

The principle remains: minimize the time between question and answer. Remote work makes this harder but not impossible.