Importance of Customer Engagement
No plan survives contact with the customer.
—Variation on Helmuth von Moltke
In Agile, delivering customer value is key. As discussed in the preceding chapter, what the customer finds valuable, changes over time, and so do the market conditions. This is why applying big upfront methods, such as waterfall, can be unwieldy. When you fix customer needs up front and plan the path to delivery without continuously engaging with the customer, you might stick to the plan, but you will be incrementally veering away from what the customer finds valuable. The moment you engage with customers on a continual basis, the plan will not survive. So the question becomes: Is it better to deal with a changing plan and deliver something the customer actually wants, or is it better to stick to the plan and not end up delivering functionality the customer wants? Keep in mind that if you are not listening to your customers, your competitors will be.
Agile Pit Stop The moment you engage with customers, the plan will not survive. But what is more important: the precious plan or meeting customer needs?
This is why it is critical to have effective customer engagement. If you have effective customer engagement, you should be building product and functionality that customers want, therefore increasing the likelihood of making more money for the company.
Identifying the elusive customer value is challenging. There have been several studies estimating that a majority of new products launched into the software product marketplace fail. More than 65 percent of new products built by established companies fail. 1 When you look further at startups, the failure rate of new products takes a huge leap to 90 percent. Based on the percentage of new products that fail, $260 billion is lost annually in the United States. If we extend this to companies around the world, we may be talking about more than half a trillion dollars of lost money. More important than the lost investment is the lost opportunity: this is half a trillion dollars that could have been spent building valuable products, which in turn would make the company more money.
To add to this, new functionality is being built into new or existing successful products that few want or end up using. Jim Johnson, chairman of the Standish Group, quoted two studies that highlight the amount of unused features. 2 A DuPont study found that only 25 percent of a system’s features were really needed and used by the user. A Standish study found that 45 percent of features were never used, and only 20 percent of features were used often or always. These findings are further supported by a Department of Defense (DoD) study, which found that only 2 percent of the code in $35.7 billion worth of DoD software was used as intended; 75 percent was either never used or was canceled prior to delivery. 3 Adding the initial and maintenance cost (paid by customers) of unused functionality of successful software products to the cost of failed software products (paid by sellers) brings us into the realm of a trillion dollars of lost money across the global market. Stanching this trillion-dollar hemorrhage is a major driver of the movement we see toward Agile and the agility and adaptability it brings.
Non-Agile Pit Stop An analogous predicament that many individual consumers experience is with cable TV service. Cable TV providers offer subscription channels only in big, expensive, one-size-fits-all bundles without reference to the individual customer’s needs, use patterns, or preferences. A result of this is that customers are compelled to pay each month for hundreds of channels that they could not be paid to watch. No wonder millions of cable customers have cut the cord (or are itching to do so).
Of the many reasons for new product failures, two stand out. First, many companies are not as in touch with their customers as they believe they are. Second, many companies aim to build a global set of features for any new product that will be imposed on every customer willy-nilly. They ignore the Agile approach: start out with a minimal set of core features based on customer prioritization and feedback, get the new product to market sooner, and build out the product based on ongoing and specific customer input.
As an exercise, ask yourself:
- What percentage of products have you built that have failed?
- What percentage of functionality of your released products is unused or has low usage?
It can be painful to answer these questions, because you may not want to hear the bad news. However, to avoid repeating the mistakes of the past, it is good to understand how you arrived at this situation and then, more important, how you can mitigate or avoid the same mistakes moving forward. Understanding and acting on the twin notions of continuous customer engagement and feedback and minimum viable product can help you build products customers want and value.
Continuous Customer Engagement
Catch-phrases in the software industry such as “customer is king” and “the customer is always right” are mostly noticeable when they are not observed. The actual time spent engaging with customers, understanding their needs, and continuously eliciting and processing their feedback is deficient. True customer management discipline to ascertain what is valuable to customers in the ever-changing conditions of needs and the marketplace is glossed over. Some of this complaisance is driven by the false assurance of some within a company that they already know what their customers need and want. Some of this neglect is because people like to lay out and then follow a precise and inflexible plan. Some of this neglect occurs because of a lack of consciousness of what true customer engagement means and a lack of continuous customer engagement strategy and practices therein.
Agile Pit Stop What the customer sees as progress is not project documents, project plans, and more status reports. Rather, customers see progress as tangible working product functionality.
We need to think like the customer. What the customer sees as progress is not the standard project documents, a project plan that indicates the task completion, or more status reports. Rather, customers see progress as tangible working product functionality. They purchase working software, not the plans, status reports, and other intangibles. Customers delight in seeing working software in action and the inspect-and-adapt approach allows customers to reconsider and adjust their needs until they are transformed into a valuable working product. Progress is not advanced until a piece of functionality is built with quality, meets the customer acceptance criteria, and is available for review by the customer in the demonstration.
Functionality equates to value for the customer and ultimately means delivering that business value. Of course, this implies that you have to continuously engage with the customer to get there. Engaging with customers only during the requirements-gathering phase and approaching product launch phase is not enough. We need to continuously engage with customers as we are actively building the product throughout the project life cycle.
Agile Pit Stop Engaging with customers only when gathering requirements and before product launch is not enough. We need to continuously engage with customers as we are actively building the product.
As discussed in the preceding chapter, the needs of customers change, and so do the market conditions. More traditional methods, such as waterfall (or hybrids of waterfall), apply a phase-based approach to product development. These methods postulate a fixed set of requirements up front as the first or second phase. Typically, some kind of change control or change management process is built into a waterfall model. However, these processes either tend to have strong teeth used to prevent change from occurring, or have no teeth and add new scope without taking much existing scope away. In an Agile model, change to requirements occurs on a continuous basis, applying a methodical prioritization and rank ordering throughout the project (Figure 4-1).
Figure 4-1. Agile adapts to changing customer needs and market conditions. The gap between what gets delivered and what the customer needs will be much smaller in Agile than in waterfall
For a waterfall-based project, the longer the time from the initial need (a.k.a. requirements phase) to the release of the product, the greater the risk (a.k.a. gap) of delivering unwanted functionality. As you will recall from Chapter 3, part of the definition of customer value is the timing. If you define requirements up front in the beginning of the year, inhibit the changes throughout the year for the release, when you get to the end of the year, the gap between what you delivered and what the customer needs may be quite wide.
In Agile, we follow a continuous build-inspect-adapt model so that requirements are continually validated with the Product Owner and customers during each iteration review (a.k.a. Sprint Review). This practice ensures there are continuous customer engagement and, more important, a continuous customer feedback loop. At the end of the project, the result should be a narrow gap between what was delivered and what the customer now needs. The narrower the gap, the more money a company is likely to make.
Dedicated Team Business Representative
The Business Representative is critical to identifying customer value. A key environmental accelerator to Agile adoption and project success is "dedicated business expertise" on the team. 4 Scrum addresses this need by requiring a Product Owner. The Product Owner should be a dedicated part of the team who bridges the gap between the customers and the engineering team.
The mission of the Product Owner is to identify requirements on a rolling basis and gather feedback from continuous demonstrations of working software, all with the goal of narrowing the gap between what was delivered and what the customer now needs (Figure 4-1). It is also his or her job to reconcile the different views of customer value as seen by different customer target groups.
The Product Owner is responsible for identifying and characterizing in detail the customers who are valuable to the company. That information helps in segmenting the customers to better understand their specific needs and pinpoint who should attend the Sprint Review/demos of the working software to supply the most valuable customer feedback. You will learn more about the Product Owner role in Chapter 12.
Minimum Viable Product (MVP)
When prioritizing a set of product features, sometimes it is hard to determine what is acceptable as the minimal set of features. Continuous customer engagement can help you understand what a minimum viable product (MVP) is for the first and subsequent releases.
The concept of MVP specifies a strategy whereby you attempt to identify the minimum amount of features that customers find valuable for any given release of the product—and no more. To identify the minimal set of features, a strong customer feedback loop (via Sprint Reviews/demos) is needed to ensure you are building the minimal features based on what customers deem valuable.
Figure 4-2. Applying the MVP approach. You can release earlier where the customer can use the value earlier and you can achieve an earlier ROI. Win-win for all!
A good way to think about MVP is to compare it to building a house. When you are a newly married couple with no kids, do you need to build a four-bedroom house for your small family? In most cases, you do not. Instead, you may build a smaller two-bedroom house with half the interior space, so that you can afford it, will be able to move in more quickly, and begin to enjoy the value of the house sooner. But if you did build a four-bedroom house, you would need to sustain parts of the house even if you won’t use them. You would need to keep a few bedrooms clean, provide heat and air conditioning, and other maintenance for functionality (a.k.a. space) that you don’t really need. However, if you build a two-bedroom house (the minimal viable product), you can always add functionality when you need it and when you will really value it.
Lack of identifying the MVP indicates a lack of customer engagement and validation. To prioritize requirements so that MVP can be identified, we need to engage with the customer continually. To be clear: Agile does not advocate arbitrary changes to requirements. Change must be strongly related to the priority that customers place on the value of what is being built. The Product Owner establishes this methodical prioritization process. This is especially delicate when the Product Owner interacts with multiple customers with different priorities.
Agile Pit Stop Agile does not advocate an arbitrary change to requirements. Instead, change must be strongly related to the priority that customers place on the value of what is being built.
Although the MVP can be drafted on a speculative basis at the outset of a project, the subsequent Sprint Reviews need to be applied with continual customer participation to validate the need and adapt as appropriate.
You should be alert to the possibilities of adapting your MVP along the way. What would you do if a customer were to say during the middle of a project that if you could get them the functionality they just saw during the demonstration portion of the Sprint Reviews, they would buy your product? Because of the continuous engagement, you can deliver this value to them for a revenue increase on your end and a delivery of customer value on theirs. Even if you don’t apply the MVP methods, you should at least apply basic customer priority techniques to ensure you build what the customer currently finds valuable.
Getting to Continuous Customer Engagement
The key is to understanding the elusive customer value is to know who your customers are and what they currently consider valuable. Identifying customers and segmenting them by target groups helps you get the right feedback for a particular feature. Yoking the concept of MVP with the concept of prioritization is foundational to understanding what customers consider most valuable. This knowledge enables you to provide the right value at the time customers need it.
Now that you have immersed yourself in the customer engagement material, I recommend a methodical approach to creating your vision for customer engagement. The reason I focus on a product level is that although the process of engaging the customer may be similar from product to product, the variety of customer groups will differ. To learn more about methodically creating a vision for customer engagement and validation, read Chapter 17.
Chapter 5 focuses on the benefits of empowering and engaging your employees and how it can contribute to gaining the benefits of Agile. If you focus on employees and provide them the space to make decisions and own their work, you can harness their vast brainpower and will begin to understand the value engaged employees can provide.
1 Rob Adams, If You Build It, They Will Come (Wiley, 2010), 1–2.
2 Jim Johnson at Third International Conference on Extreme Programming, May 2002.
3 Theron R. Leishman and David A. Cook, “Requirements Risks Can Drown Software Projects,” CrossTalk: The Journal of Defense Software Engineering (April 2002).
4 Scott Ambler, “Agile Adoption Strategies: November 2011 Survey Results,” http://www.ambysoft.com/surveys/agileStateOfArt201111.html.