Customers
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.
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.
In a horizontally scaled group of teams (see “Scaling Horizontally”), 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.
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” instead.
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.
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 its 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.
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”.
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.
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 one another. If you’re located near one another, 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 an in-person team, consider using a virtual whiteboard for your visual plan, so you can more easily share and discuss plans.
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.
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.
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 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 is the visible tip of the software development iceberg: software that’s intended to be used across a wide range of industries. Consumer websites 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, UX testing, community previews, early access and beta releases, and so forth.
We’re creating a website 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 website 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.
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 UX 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.
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.