This chapter is from the book
This chapter is from the book
This chapter is from the book
Frame 1: Customer Focus
If you think of your organization as a system,11 then a clear, customer-focused purpose that can be used to drive holistic decisions is the starting point for systems thinking. Start by asking yourself, "Who are my customers, and what do they really want from my organization?" This is not as easy as it sounds, because it may not be clear who your customers really are. So let's start by defining whom we mean by customers.
Who Are Your Customers?
A customer is anyone who pays for, uses, supports, or derives value from the systems you create. Thus you probably have a lot of different customers. But wait; there's more. If you are working on a subsystem of a larger system, you have customers of your subsystem and customers of the overall system. So arriving at clarity about who your customers are can be challenging.
We recommend that you simplify the issue of identifying your customers by considering the whole system you are involved in creating, not just the software. If you are creating a subsystem of a larger system, think of those creating the other parts of the system as partners and focus on understanding the customers of the overall system. For example, if you are developing the software for a medical device programmer, the primary customers are those whose lives are improved by the medical device, followed closely by the medical personnel who select, deliver, and program the medical device. If you are developing software to automate a business process, the purpose of the software is to support the most effective business process possible, and the most appropriate measurements of success would be the business results generated by the improved business process.
Customers Who Pay for the System
Often the first customers who come to mind are the sponsors who pay for your systems. Ask yourself, "Why do these customers spend good money for my systems? What purpose are they trying to achieve? What are their key constraints?" Sponsors usually have a clear purpose: They know the overall results they expect from an investment. Cost is frequently constrained by a limit beyond which the investment would not make sense, and sometimes there is a deadline beyond which the system would not be useful.
Sponsors usually don't care about the details of the system, as long as their purpose is served. Thus it is very important to be clear about what this purpose is and to focus on it separately from the details of implementation. The objective is to be sure that the sponsor's purpose is achieved.
Customers Who Use the System
Customers who use your system may not be the same as those who pay for the system, and sometimes these users have a different purpose. They have a job to do, and they want the system to help them do their job more effectively, more comfortably, and more intuitively. As Carl Kessler and John Sweitzer say in Outside-in Software Development, "If your product makes end-users feel smart, effective, and in control of their work, you have a winning product." 12
Customers Who Support the System
When you release a system, you may breathe a sigh of relief now that your work is done; but the work is just beginning for those who support the system. Do you know how consumable your systems are—that is, how rapidly and easily your customers can begin realizing value from your system? What does it take to install a system or a release? How difficult is it to use? How much training is required?
You should also understand how robust your systems are. How often do they fail in normal use? How long does it take to recover? How easy is it to find and eliminate the cause? What does a failure cost your customers?
Customers Who Derive Value from the System
One of the most effective ways to create a competitive advantage is to help your customers be successful. So ask yourself whether you know how long it takes your customers to start deriving value from your systems. Is there anything you can do to help them?
Many companies expand their business by understanding their customers' value chain and helping their customers' customers be successful. For example, if a company helps its customers develop a truly effective call center, or sell software tools that increase the effectiveness of financial analysts, their customers will be delighted.
What Is Your Purpose?
A simple statement of purpose from a customer's perspective can do wonders to clarify what is important and what is not. For example, everyone at Southwest knows that the company's purpose is to make flying affordable and enjoyable for everyone. This means that costs have to be low and hassles minimized. This purpose guides both strategic initiatives and day-to-day decisions at all levels of the company.
Once you have identified your customers, it is time to come to a clear understanding of your organization's purpose from your customers' perspective. Create a brief, crisp statement of what is important for your organization to succeed. This is what your work system must deliver. Note: Your purpose is probably not to develop software. It is a rare customer who wants software; customers want their problems solved. If customers could solve their problems without software, they would be delighted.
As an example, let's look at how we would describe the purpose of the development group in the sidebar "Product Owners Aren't Customers." In this case, the primary customers were the users, the production operators; another important customer was the sponsor; and a third set of customers were the operations people who supported the system. The purpose of the development group was to provide a production information system that made production operators' jobs easier while improving quality and productivity in the manufacturing plant.
Let's look at another example. Werner Vogels, CTO of Amazon.com, defines the purpose of his IT organization thus: Provide a highly available, highly scalable technology platform for Amazon.com and its business partners. 13 By "available," Vogels means that shoppers can always browse a site and put things in their shopping basket, even if other parts of the system aren't working. By "scalable," Vogels means that there should be positive, not negative, economies of scale, and scaling should be available on demand. Over the past several years, pursuing this purpose has turned Amazon.com into an impressive technology provider as well as a retailer, while Amazon's IT department has become a true profit center.
What Is the Nature of Customer Demand?
The next step in establishing a systems view of your organization is to understand the patterns of customer demand for the products and services you provide. Customer demand comes in two forms. First there is demand for products and services that provide value. Second, when a product or service doesn't meet the customers' expectations, there is demand for failure remediation—that is, demand to fix something that appears to be broken, inadequate, or difficult to use, configure, or modify.
Failure Demand
Failure demand is the demand on the resources of an organization caused by its own failures. Support calls, for example, are almost always failure demand. They may be caused by some aspect of the system that is unclear to a user, or they may be caused by an outright failure of the system to perform.
Change requests may also be failure demand; for example, a change request may come from a failure on your part to understand your customers or a premature decision on your part about what customers actually want. Even if you deliver exactly what your customers asked for, once they see it they may realize that it doesn't solve their problem; from your customer's perspective change requests in this case are failure demand.
An insidious form of failure demand is the demand on your resources created by technical debt: things such as defects you have chosen to ignore, messy coding practices, duplication, lack of effective test automation, a tightly coupled architecture, multiple code branches—anything that makes it difficult to respond to a request for a change. All these things increase the demand on your capacity when customers ask for changes, even if the changes themselves are value demand.
Demand from support organizations that have to deal with your systems is usually failure demand. When your product is difficult to integrate with other systems, database migrations between versions are a nightmare, or intermittent lockups bring down the data center, you have serious failure demand. Even if your software performs exactly the way it was designed to operate, if it gives operations and support organizations problems, both you and they are wasting valuable time.
The purpose of looking for failure demand is to identify as much failure demand as possible, because failure demand is waste that you can do something about. In the beginning you should expect to find a lot of failure demand. Welcome it; do not penalize anyone for it. Failure demand is created by the way your work is done; exposing it gives you the opportunity for significant improvement. Your primary objective is to find and eliminate failure demand so that you have more time to accommodate additional value demand.
Once you have identified failure demand, calculate what percentage of the demand on your organization is failure demand. It is likely to be a big number; we have seen estimates between 30% and 70%. Think about it: If one-third of your demand is failure demand, you would increase the capacity of your organization by 50% if you could eliminate that failure demand. Eliminating failure demand provides a huge opportunity for increased productivity. In Chapter 4, Relentless Improvement, you will find ideas for ways to uncover the causes and reduce the amount of failure demand.
Of course, failure demand is not going to go away overnight, and while it exists, your secondary objective is to remediate each problem as rapidly as possible. John Seddon says, "As a rule of thumb, end-to-end time from the customer's point of view is almost always an essential measure in any 'break-fix' system."14 A break-fix system starts with a customer in distress (something is broken) and ends when the problem is resolved (fixed). For all failure demand that you choose to fix, the essential customer-focused measurement is the request-to-resolution time. Clearly, your first priority should be to eliminate the failure demand, but as long as it's there, minimize your customers' pain by fixing their problem as rapidly as possible.
Value Demand
The primary demand on your organization should be value demand. This demand can be in the form of requests for work that will add value from a customer's perspective, or it can be in the form of unmet needs that customers don't know they have, but that you discover and satisfy through your products and services. Value demand, when satisfied, usually generates revenue for your organization.
Almost every software development organization we know of has more demand for its services than it can accommodate, so a good question to ask is "What portion of incoming value demand does my organization have the capacity to satisfy?" If value demand exceeds your capacity to deliver, there are two steps to take: (1) Focus on eliminating failure demand so you have more time to work on value demand, and (2) evaluate how you filter value demand to decide which work you will accept and which you will turn down.
Once you have a good idea about the volume of value demand your organization is experiencing, how you qualify it, and what percentage you can accept, the next step is to establish a customer-focused view of the value you deliver. What do your customers really value? Once you understand what customers value, you can establish customer-centric measures to focus everyone on improving customer outcomes, rather than meeting internal targets. If you provide visibility into what it means to deliver customer value, development teams can act independently and creatively to give customers more of what they really want.
Examples of good customer-centric measurements might be the following:
- Time-to-market for product development (for the whole product)
- End-to-end response time for customer requests (request-to-resolution time)
- Success of a product in the marketplace (profitability, market share)
- Business benefits attributable to a new system (measureable business improvement)
- Customer time-to-value after delivery (consumability)
- Impact of escaped (post-release) defects (customer downtime, financial impact)