AoAD2 Practice: Real Customer Involvement

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Revised: July 13, 2021

Real Customer Involvement


We understand the goals and frustrations of our customers and users.

I once worked with a team that was building software to analyze mass spectrometer data. The team’s domain expert was a chemist whose previous job involved using the company’s old software. She was invaluable, full of insight about what did and didn’t work with the old product. We were lucky to have her as a member of the team. Thanks to her, we created a more valuable product.

Whole Team

In an Agile team, on-site customers—team members with the skill to represent customer, user, and business interests—are responsible for choosing and prioritizing stories. The value of the team’s work is in their hands. This is a big responsibility. As an on-site customer, how do you know what to choose?

Some of that knowledge comes from your background and expertise. But you can’t think of everything. You can get so caught up in daily details that you lose track of your real customers’ interests.

To widen your perspective, you need to involve real customers and users. The best approach to doing so depends on who you’re building the software for.

Personal Development

In personal development, which I include mainly for completeness, the development team is its own customer. They’re developing software for their own use. There’s no need to involve anyone else; the team is the real customer.

Platform Development

In a horizontally-scaled group of teams (see “Scaling Horizontally” on page XX), some teams may build software solely for the other teams to use. The real customers of this sort of platform development are those client teams.

Client development teams need flexibility, autonomy, and ownership, not magic.

All too often, platform developers fall into the trap of making tools and libraries that are “easy to use.” But that’s not what your client teams need. They need flexibility, autonomy, and ownership, not magic. They need to be able to do their work without depending on your team to make changes. In general, that means that you should prioritize simple programming interfaces with clear responsibilities, minimal side effects, and an “escape hatch” that allows teams to dig into details when they need to.

Some organizations divide their teams into senior developers, who build a platform, and junior developers, who customize it to build products. Avoid this approach. Too often, it leads to an ivory-tower platform that tries to make customization “easy” but actually requires inexperienced developers to constantly work around its gaps. The result is a hard-to-maintain mess.

Be sure to work closely with representatives from the teams you serve when designing APIs and deciding on capabilities. Focus on giving your customers the ability to solve problems on their own, so you don’t end up as a bottleneck to their work. One way to improve understanding is to conduct “exchange programs” in which one of your developers trades places with a client team’s developer for several weeks.

If your team builds software to help developers in general, rather than supporting specific teams, see “Vertical-Market Software” on page XX instead.

In-House Custom Development

In-house custom development occurs when your team is building something for your organization’s own use. This is classic IT development. It may include writing software to streamline operations, automation for your company’s factories, or producing reports for accounting.

In this environment, the team has multiple customers to serve: the executive sponsor who pays for the software and the end-users who use the software. Their goals may not be in alignment. In the worst case, you may have a committee of sponsors and multiple user groups to satisfy.

Turn your real customers into on-site customers.

Despite this challenge, in-house custom development makes it easy to involve real customers because they’re easily accessible. The best approach is to bring your customers onto the team—to turn your real customers into on-site customers.

Rather than asking customers to join your team, it may be easier to move your team to sit near their customers.

To do so, recruit your executive sponsor or one of their trusted lieutenants to be your product manager. The product manager will make decisions about priorities, reflecting the desire of the executive sponsor to create software that provides value to the organization.

Also recruit some end-users of the software to act as domain experts. As with the chemist mentioned in the introduction, they will provide valuable information about how real people use the software. They will reflect the end-users’ desire to use software that makes their lives better.

Stakeholder Demos

To avoid tunnel vision, the product manager and on-site customers should solicit feedback from their colleagues by conducting stakeholder demos and sharing roadmaps.

If you have trouble getting your sponsor or users to join the team, see the discussion of outsourced development in the next section. If you have multiple sponsors or user groups, see “Vertical-Market Software” on page XX.

Outsourced Custom Development

Outsourced custom development is similar to in-house development, but you may not have the connections an in-house team does. As a result, you may not be able to recruit real customers to act as the team’s on-site customers.

Still, you should try. One way to recruit real customers is to move your team to your customer’s offices rather than asking them to join you at yours.

Visual Planning
Stakeholder Demos
The Planning Game

If you can’t bring real customers onto the team, make an extra effort to involve them in other ways. Meet in person with your real customers for the first week or two of the project so you can discuss your purpose and context, visual plan, and get to know each other. If you’re located near each other, meet again for each stakeholder demo and planning session as well as occasional retrospectives.

If you’re far enough apart that regular visits aren’t feasible, stay in touch via videoconference and phone conferences. If you have a remote team, consider giving them access to your virtual team room. Try to meet at least once per month to discuss plans. Even if you have a in-person team, consider using a virtual whiteboard for your visual plan, so you can more easily share and discuss plans.

Vertical-Market Software

Unlike custom development, vertical-market software is developed for many organizations. Like custom development, though, it’s built for a particular industry, and it’s often customized for each buyer. Most software-as-a-service (SaaS) products fall into this category.

Because vertical-market software has multiple customers, each with their own needs, you have to be careful about giving real customers too much control over the direction of the product. You could end up making a product that fits your on-site customers’ needs perfectly, but alienates your remaining customers.

Stakeholder Demos

Instead, your team should include a product manager who understands the needs of your real customers impeccably. Their job—and it’s a tough one—is to take into account all your real customers’ needs and combine them into a single, compelling purpose. This includes balancing the desires of people who buy the product with the needs of people who actually use the product. For vertical-market software, their goals are often different, and can even be in conflict.

Create opportunities to solicit feedback from real customers.

Rather than involving real customers as members of the team, create opportunities to solicit their feedback. Some companies create a customer review board filled with their most important customers. They share their release plans with these customers and provide stakeholder demos for customers to try.

Depending on your relationship with your customers, you may be able to ask them to donate real users to join the team as on-site domain experts. Alternatively, as with the chemist in the introduction, you may wish to hire previous users to be your domain experts. You can also solicit feedback through trade shows and other traditional sources.

Horizontal-Market Software

Horizontal-market software is the visible tip of the software development iceberg: software that’s intended to be used across a wide range of industries. Consumer web sites fall into this category, as do games, many mobile apps, office software, and so on.

As with vertical-market software, it’s best to avoid giving real customers too much control over the direction of horizontal-market software. Horizontal-market software needs to appeal to a wide audience, and real customers aren’t likely to have that perspective. A product manager who creates a compelling purpose and go-to-market strategy based on all customers’ needs is particularly important for horizontal-market software.

Horizontal-market organizations may not have the close ties with customers that vertical-market organizations do. Thus, a customer review board may not be a good option. Instead, find other ways to involve customers: focus groups, user experience testing, community previews, early access and beta releases, and so forth.


We’re creating a web site for our marketing department. What kind of development is that?

At first glance, this may seem like custom development, but because the actual audience for the web site is the outside world, it’s closer to vertical-market or horizontal-market development, depending on your industry. The product manager should come from the marketing department, if possible, but you should also solicit feedback from people who will be visiting the site.



One danger of involving real customers is that they won’t necessarily reflect the needs of all your customers. Be careful that they don’t steer you toward creating software that’s only useful for them. Use your team’s purpose as its north star. Customer desires inform the purpose, and may even change it, but ultimately team members with product management skills hold final responsibility for the team’s direction.

End-users should be involved but not in control.

Similarly, users often think in terms of improving their existing way of working, rather than in terms of finding completely new ways of working. This is another reason why end-users should be involved but not in control. If innovation is important to your team, give innovative thinkers—such as a visionary product manager or user experience designer—prominent roles on your team.


When you involve real customers and users:

  • You improve your knowledge of how customers use the software in practice.

  • You have a better understanding of customers’ goals and frustrations.

  • You use customers’ feedback to revise your plans and software.

  • You increase your chances of delivering a truly useful and successful product.

Experiments and Alternatives

Feedback is essential, but direct involvement by real customers isn’t. Sometimes the best software comes from people who have a strong vision and pursue it vigorously. The resulting software tends to be either completely new or a strong rethinking of existing products.

Still, feedback from real customers is always informative, even if you choose to ignore it. This practice is about getting that real-world feedback. The goal is to create software that really meets customer and user needs, not just your team or organization’s imagination of their needs.

As you think of ways to experiment with this practice, focus on communication and feedback. How can you get better insights about how your software is perceived in the real world? How can you decrease the time between having an idea and getting feedback? How can you make better decisions based on feedback? The more information you have, the better decisions your team can make.

Further Reading

XXX Martin Fowler: Whenever I talk to people about product management, I always like to point people to the work of Kathy Sierra. Her "Badass" book is excellent, and there's tons of gold still there in her old Creating Passionate Users blog <>.

XXX Luiza Nunes: Recommend Team Topologies, Specification by Example

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.