Some agile software development approaches have as a central tenet the premise that every project needs a full-time, on-site customer who sits with the development team and works closely with them. The rationale is sound. Only knowledgeable and empowered customer representatives can answer questions and flesh out high-level requirements. If they can’t get timely answers or clarification, developers must make their best guesses about what they think customers want. The right customers also can provide quick feedback on proposed user interfaces, clarify points of confusion, and resolve conflicting requirements and priorities.
I fully endorse the premise of intimate, ongoing engagement of appropriate customer reps on projects. Various other stakeholders also need to provide input in most cases. My concern about the phrase on-site customer is simply that it is singular. It suggests that a single individual is available who has sufficient knowledge, expertise, and authority to make requirements decisions for the entire user community. The product owner often is expected to fill this role on an agile project.
This article, adapted from my book More about Software Requirements, describe a more effective approach to finding the literal voice of the customer and engaging customers on a project.
User Classes and Product Champions
Most products have multiple distinct user classes, who have largely different needs. Certain groups — the favored user classes — will be more important than others to the project’s business success. Sometimes user classes aren’t even people: they’re other information systems or hardware components that derive services from the system you’re building. Such user classes also need a voice to speak for their needs. Rarely can any one individual can represent the needs of all these diverse user classes and balance their interests appropriately.
A more realistic approach is to enlist a small number of product champions to serve as key user representatives. More than thirty years ago, my software group at Kodak adopted the product champion approach with great success. In this model, the requirements flow bridges one or more business analysts working with one or more product champions:
As a start, look for one product champion per major user class. Some individuals might belong to multiple user classes and could indeed present the needs of all those groups. In other situations, a large user class might need to be divided into sub-user classes.
I encountered this situation on a project that was building an information system to track chemical usage. Our largest user class consisted of several hundred chemists. We found a chemist, Don, who could supply most of the requirements for the common needs these users had. Don served as the product champion, the primary interface between the chemists and the BA (me, a former organic chemist myself). Don communicated with his colleagues to identify requirements, propose ideas, formulate relevant business rules, and resolve conflicting inputs.
During this project, though, we learned that certain groups of chemists had some specialized needs. Therefore, we lined up a few other representatives to work with Don to ensure thorough coverage of the community’s requirements. If this group couldn’t all agree on some issue, Don made the call. Someone has to make these kinds of decisions; it’s better if a knowledgeable and respected user rep does it than if the BA or developers choose.
On this same project, we had three other important but much smaller user classes. We found one product champion to represent each of these other groups. Those four product champions together served as our “voice of the customer.” This requirements approach was a massive contributor to that project’s success.
Ideally, your champions will be co-located with the analysts and developers for the duration of the project so they can quickly answer questions and supply the details that written requirements specifications lack (or get wrong). This is the core intent of the on-site customer principle, and it can greatly accelerate progress. None of our product champions ever spent more than about one-quarter of their time working on our software projects. They weren’t co-located with the development team, although they were accessible enough to provide quick feedback when needed.
I’ve spoken to many BAs, developers, and end users from various companies who have tried the product champion model. They invariably report that the approach was highly successful, provided the follow four conditions are met:
- The right individuals assume the product champion role.
- Each champion understands and signs up for his responsibilities. Chapter 6 of my book Software Requirements, 3rd Edition describes typical product champion activities.
- Each champion has the time available to do the job.
- Each champion has the authority to make binding decisions at the user requirements level.
Simply having an on-site customer doesn’t guarantee success. My colleague Julia once had a product champion who was co-located with the developers but didn’t provide much value. As Julia said, “He sat in our midst and still managed to avoid us all.” Julia replaced him with a new champion who contributed much more effectively to shaping the project’s direction. The moral of the story is that your customer reps must commit to making the project contributions you need from them, and then they need to do the job.
The ideal product champion is an actual member of the user class he or she represents. This isn’t always possible, particularly when building commercial products for a faceless market. You might need to use surrogates in place of real user representatives. Perhaps a product manager can fill this role or a local subject matter expert can speak for the users, thereby acting as the product champion. Watch out for the following user surrogates, though:
Former members of the user class. When your product champions are former — not current — users, ask yourself whether a disconnect has grown over time between their experiences and the needs today’s users have. Their understanding could be obsolete. However, they might be able to do a good job if they’re still in touch with current users or if the application domain changes slowly.
When we were setting up the product champions for the chemical tracking system I mentioned earlier, the manager of the chemical stockroom told me, “I was a lab chemist before I got this job, so I can give you their requirements. You don’t need to talk to any other chemists.” She was wrong. She was the perfect product champion for the chemical stockroom user class, but she didn’t have a good understanding of how the other chemists in the company needed to use the system today. I thanked her for her offer, but then I lined up the other chemist representatives described above.
Managers of the real users. Managers sometimes are uncomfortable delegating decision-making authority to ordinary users. Often, they’re also reluctant to have their valuable employees spend a lot of time working with the software team as product champions. I’ve heard managers say, “I did that job myself for ten years. I can tell you everything you need to know.”
There are two problems here. First, those managers probably aren’t current members of the user class. Second, busy managers rarely have the time to devote to a serious requirements development effort. It’s better to have managers provide input to the business requirements (why we are undertaking the project, business objectives, scope decisions) and ask them to identify some current members of the user class to contribute to the user requirements (use cases, user stories, business processes to support, system quality characteristics).
Software developers who think they can speak for the users. Rarely, this situation can work. More commonly, even developers with considerable domain experience will find that actual users of the new product will bring a different — and more reliable — perspective. Of course, if the product is intended for use by software developers, your own developers might be great user representatives. Even in that case, though, perform a thorough user-class analysis and make sure someone will be speaking for each of them.
Now Hear This
Your stakeholders might hesitate to have knowledgeable users spend time working with BAs or through developers on requirements. Here’s how I see it. You’re going to get the customer input eventually. It’s a lot less painful to get it early and on an ongoing basis during development. The alternative is to wait until you deliver the product and start collecting complaints about everything that’s wrong or missing. Then you’ll spend a lot of unplanned time, money, and goodwill fixing those problems. That’s not a smart way to build software.
I encounter many teams that would love to have more customer involvement but which are deliberately blocked from talking to actual users. This is a special concern when the acquiring customer is not himself an end user, yet prevents the developers from interacting directly with users.
In other cases, no one wants to invest the time to work with the development team on requirements elicitation, prototype evaluations, or other interactions. If your customers won’t collaborate in making sure the product meets their needs, I question their commitment to the project’s success.
In an ideal world, a single, full-time, real user would indeed be sitting within view — ”on sight” — of developers, ready at a moment’s notice to speak definitively for the entire user community. In reality, this is unlikely in most situations. More realistically, the project manager, business analyst, or product owner should assemble a small group of product champions who can properly interpret and balance the needs of the user classes they represent. A close, collaborative relationship with those product champions will help you bring the VOC — the voice of the customer — as close as possible to the EOD — the ear of the developer.
If you’re interested in requirements and business analysis, Process Impact provides numerous useful publications and other resources.