Customers Apprentice

As an "interview technique" to elicit requirements from a customer...

Be the Customer's Apprentice: To design a system to do your customer's job, you have to know how to do your customer's job. UsersAreSmarterThanProgrammers.

How do you learn to do the customer's job? By taking on an apprenticeship: The customer, the master at doing their job, teaches you, the apprentice, how to do it.

Alternately, if you're creating a system to assist them in doing their job, then they, the master, teach you, the apprentice, how to assist them in doing their job.

Talking with the user about their work, in the context of doing the work, helps overcome the difficulty they may have in thinking about things abstractly, as they can always resort to the actual example of the work in front of them. And it helps stop flights of speculative fancy (by either party), by giving you "an out" -- asking about particular examples of work, like the work before you, that support it.

Being "the Customer's Apprentice" is a particular practice of CustomerCenteredDesign?.

See "Apprenticing with the Customer: A Collaborative Approach to Requirements Definition" -- http://www.incent.com/papers.indx/requirements.html

and other ContextualDesignTechniques? at http://www.incent.com/dc_resource.html

This is not an ExtremeProgramming practice, but as we know, XP teams always work with a customer on-project who continues to do their normal work. So XP probably benefits from some aspects of this kind of approach, even if it doesn't do "Customer's Apprentice" directly. "Customer's Apprentice" is more about sitting down, watching the customer work, and talking about it than having the customer available at any time to answer questions.