Customer Collaboration in XP

The last unit was about building software well: quality designed in, a pace you can hold. This unit shifts the question from "are we building it right?" to "are we building the right thing?" All the engineering discipline in the world is wasted on a feature nobody wanted. Extreme Programming's answer is blunt: collapse the distance between the people building the product and the people who will actually use it, and keep collapsing it.

XP's on-site customer practice puts a real customer voice, or an empowered product owner, continuously available to the team rather than surfacing once a quarter to sign off. The reason is cost. When access is missing or proxied entirely through documents, questions queue, developers fill the silence with assumptions, and you only discover the wrong assumption at the demo. An engaged customer answers the small questions in minutes, before they harden into rework.

That availability only pays off if you give them something concrete to react to, which is where short feedback loops come in: ship a usable slice each iteration, put it in front of real users, and let their reaction shape the next one.

• Ryan: We finally demoed the workflow we built last quarter, and the customer barely touched half of it.
• Jessica: When did they last see it before that demo?
• Ryan: The kickoff. We had a signed-off spec, so we just built to it.
• Jessica: That's the gap. A spec is a snapshot of what they thought they wanted months ago. If they'd seen a working slice each iteration, you'd have caught the dead half in week two, not month three.
• Ryan: So the fix isn't a tighter spec, it's a shorter loop.

Notice the leverage isn't a more detailed document up front; it's shrinking the time between building something and learning whether it was right.

A short loop needs something to feed it, and that something is working software. Incremental delivery means slicing a large feature into thin, independently valuable pieces and releasing them every iteration instead of holding everything back for one polished launch months away. Each slice does double duty: it delivers real value early, and it generates the feedback that corrects your aim for the next slice. The discipline is making the first increment genuinely small and genuinely usable, not half a feature with no standalone worth. If a slice can't stand on its own, you haven't sliced the value, you've just split the work.

Even with the customer close, you and they can talk past each other for weeks. Story mapping fixes that by making the whole journey visible at once: user activities run left to right across the top in the order someone actually does them, and the detailed stories hang down in columns beneath each step. Built together, the map exposes gaps, surfaces priorities, and lets you draw a line across it to agree the first thin slice that delivers value end to end. It turns a flat requirements list, which hides what matters, into a shared picture of how the product should evolve.

The skeleton looks like the table below: user activities run left to right across the top columns, the stories under each one hang down the rows, and a horizontal line marks the first thin slice. Everything in the "Slice 1" row is the smallest end-to-end path a real user can complete; the "Later" row waits for a future slice.

Drawing that line — agreeing what belongs in Slice 1 versus Later — is how you and the customer settle on where to start.

Across these practices, one idea holds. Building the right thing depends on two things: how short the distance is between your team and the customer, and how fast the loop runs between them. Several practices follow to put that to work. You'll spot what genuine customer access looks like versus a document standing in for it, design a feedback process and an incremental release plan you could hand your team this week, and then facilitate a live story-mapping session with a customer who would rather just hand you a spec. Start small: pick one feature in flight and count the days between what you're building now and the next time a real user will see it.