Chapter 3. Value

• “Solve my problem completely.”

• “Don’t waste my time.”

• “Provide exactly what I want.”

• “Deliver value exactly where I want it.”

• “Supply value exactly when I want it.

• “Reduce the number of decisions I must make to solve my problems.”

Let’s take a look at a company that seems to have gotten this message several years ago.

In 1999 Google joined the crowded field of search engines with the lofty goal of making the world’s information accessible to everyone. The company decided that in order to do this, it needed to focus on two things: 1) provide more relevant search results than anyone else, and 2) provide a truly engaging user experience. The strategy worked. In the last issue of 1999, PC Magazine awarded Google a technical excellence award in Web applications. As PC Magazine said, “It doesn’t take many visits to Google to get hooked. And who can avoid getting hooked on a search engine that consistently returns good results?”³ The award drew attention to Google and started its meteoric climb to the top of the search engine industry.

Google’s corporate philosophy, published on its Web site, begins with these four points:⁴

1. Focus on the user and all else will follow.

2. It’s best to do one thing really, really well.

3. Democracy on the Web works.

4. Fast is better than slow.

In its early days, Google resisted strong pressure to compromise on the user experience—pop-up and banner ads, all the rage at the time, were strictly banned because users found them annoying. Google has always been fanatical about speed. Any noticeable delay in responding to a search request would waste users’ time. While most of their competitors were creating portals, Google kept its home page extremely simple: one logo, 30 small words, and a single search box with a couple of buttons. Google didn’t want to distract users with extra features.

Finally, Google was really, really good at finding relevant search results, and it got better over time. The founders had developed a unique way of ranking search results—they tallied the number of “votes” for a page, that is, the number and importance of references to the page. The page with the most votes won. As time went on, Google continually refined its ability to have people vote on pages and ranked them accordingly.

Google applies the same four principles in its product development process:

1. Value—Focus on the user and all else will follow: Development teams are encouraged to develop products with a “laser like focus” on users. Once the product becomes popular, company officials are expected to figure out how to make a profit.⁵

2. Excellence—It’s best to do one thing really, really well: Google is like its search engine, built to be extraordinarily good at what it does. Its deep technical bench gives it the flexibility to experiment and try many things at once.⁶

3. Democracy—Democracy on the Web works: New ideas gain traction at Google by attracting a critical mass of enthusiastic people willing to work on them. Products gain stature by getting listed on the Google Labs site and attracting user attention.

4. Speed—Fast is better than slow: At Google, things that would take years at other companies happen very quickly...on the order of days or weeks.⁷

Consider Google’s approach to adding maps to its repertoire of capabilities. In March 2004 Google launched a beta version of Google Local, a tool to restrict a search to a geographic area. In October of the same year, Google acquired the company Keyhole, giving it access to detailed, worldwide, satellite imagery. In February 2005 Google added mapping capability to Google Local. In April 2005 it added satellite imagery just six months after acquiring Keyhole. Two months later, Google Earth was launched, packaging satellite images, maps, and local searches in an innovative and engaging desktop interface that imitates a globe and streams data from the Internet.

Google focuses on its strategic vision: Organize the world’s information, and make it universally accessible and useful. To support that vision, Google develops both internal tools and Web-based products that involve a mix of sophisticated algorithms, complex hardware, and well-designed software. Products and tools are developed quickly and incrementally by small teams that include product management, design, engineering, testing, launch, and continuing engineering. Teams are encouraged to release products before they are fully refined in order to get feedback from users. Google’s software has a reputation for elegant design and high quality, and it invariably delights users.

By all measures, Google is a very successful organization (as of this writing), and more importantly, its products have changed the way the world works. Google continually introduces new products despite the fact that it doesn’t have a long-term product map and it expects technical staff to spend 20 percent of their time on their own projects. The company decides what products to work on much the same way it ranks search results: priority is based on the interest of development teams and number of users attracted to the product.

We believe that Google has been successful because it gives users exactly the information they want, when and where they want it, with no hassle, and no wasted time or annoying ads. Google is easy enough for a small child to use. And it solves the whole problem—checks spelling, translates languages, converts units, contains a dictionary, calculator, and maps—the very definition of a “lean solution.”

Coming up with a brilliant product concept is the start of innovation. This can be a long process of research, or it can be a stroke of insight. Companies can create conditions for innovation, but there is no magic formula for coming up with great insights. However, a flash of insight is hardly enough: “Innovation is 5 percent inspiration and 95 percent perspiration.”⁹ The problem in most companies is that people with inspiration do not have the time or charter to pursue it. Companies that routinely turn inspiration into innovation create time and space for people and teams with good ideas to incubate those ideas and turn them into a product concept.

The feasibility stage of product development is important, because it provides space for experimentation. Note that the feasibility stage is not a paper study. Concepts are fine, but there is nothing quite like checking things out in the real world.

This is also the time for systems design, a critically important discipline that many companies seem to do without. What are the major features of the business process, the key modules of the hardware? What interfaces will the system have, and how will they interact? How will the software architecture support the product? What are the key constraints of the system, and how will they be addressed? An excellent systems design is the foundation of an excellent product. It should neither be done by amateurs nor by arms-length experts. Rather, it should be done by seasoned designers who know the systems design will evolve as the product emerges and who know how to make sure that evolution is taken into account so it can proceed smoothly.

No one expects fully formed products to emerge from the feasibility stage of product development. All that feasibility proves is that the product “could” work. At that point the real learning of product development begins. Good product development is composed of discovery cycles of trial and learning that increasingly refine the design of the product. The objective is not to complete the product but to get it to a point where a set of capabilities can be tested in a pilot. Through a series of increasingly complete pilots the product emerges.

The pilot stage of software development is more likely to involve actual release to customers than the equivalent stage in hardware development, although as we will see in Chapter 8, the Polaris submarine produced a series of working submarines, starting three years into a nine-year program. Even if a hardware pilot is not released to customers, it’s a good idea to plan hardware pilots that integrate embedded software as early in the development program as possible.

Releasing software to customers during the pilot stage is almost always beneficial, as long as the systems design was done well during the feasibility stage. Of course, early release is not always practical. Embedded software, for example, can’t really be released before the hardware. Games cannot be released in a partially done state, even to reviewers, because first impressions are almost everything in the game world, and shelf life is very short. But in most situations, we would be strongly biased in favor of evaluating software with alpha and beta releases. In particular, in legacy conversion projects you never know how your software will work until it is running on the real (usually messy) database with real users, at least in a mirrored environment.

The Kano model shows that just to get in the door, you have to meet customers’ basic needs. After that, there are two areas for differentiation: 1) increase performance by adding features, or 2) discover needs that customers aren’t even aware of and delight them by meeting these needs. Kano noted that increasing performance gives linear results—customer satisfaction is increased in direct proportion to the increased performance. To get an exponential increase in satisfaction, you need to discover and meet unmet needs and thus surprise and delight customers. Kano said that great products do not come from simply listening to what customers ask for, but from developing a deep understanding of the customer’s world, discovering unmet needs, and surprising customers by catering to these needs. This is the way to create delighted customers.

Google seems to be very good at delighting customers. As we travel around the world giving talks and classes, we usually ask the question: How many people in the room really like Google? Invariably, just about everyone raises their hand, and then we hear about an amazing number of ways in which people use Google products. Our son regularly sends us pointers to unique new Google features. Our granddaughter routinely uses Google to do elementary school research.

It was the late ’90s when every newspaper suddenly had to have a Web site. All of the other newspapers hired an outside firm to design their Web sites. We hired a programmer instead, and I worked with him. It was difficult at first for me to understand what he was talking about, but after a while I began to see what a Web site might be able to do for us. I was a business person interacting with a technical person, and we learned together what was desirable and what was possible. Eventually this led to something really valuable. We decided to offer access to our content for an increased subscription fee, even though our competitors were giving away access to their content. A very large percent of our subscribers signed up to pay the higher rate. Right now, every one of the newspapers similar to ours is struggling financially. On the other hand, we are very profitable.

There’s plenty of average software in the world, but occasionally some truly innovative software catches our attention. And we want to know “How do they do that?” or more accurately, “How can we do that?”

At P&G Cook had learned to deal with competition by thoroughly understanding the job that people need to do, what was wrong with current tools, and exactly what it meant to do the job better. He started by methodically researching how people currently managed their finances. He learned that most people did only three things: pay bills, maintain their check register, and periodically total and review their expenditures. And he discovered that they found these jobs unpleasant and wanted to complete them as fast as possible. So Quicken was designed from the beginning to do three—and only three—jobs faster than they could be done manually. By shifting his view of the competition to paper and pencil, Cook could not only ignore existing software competitors, he changed the basis of competition.

The P&G playbook included research throughout the product lifecycle. Cook found that competing financial software was laden with features and took hours to install. Cook decided to create a program so simple that a PC novice could install it and be writing checks in fifteen minutes. Then he more or less invented usability testing so that Quicken 1.0 could be tested and simplified until it met this goal. Meanwhile, the same tests confirmed that it took experienced PC users up to five hours to write their first check on the feature-laden competing products.

Because having a better tool is not enough, Intuit’s research extended to packaging and pricing. The people who have a job to do must clearly understand that there is a better tool for the job. Finally, Intuit continued to improve the tool, making sure that it maintained its position as the best tool for the job. Cook contends that value is created by focusing on the job that needs to be done and improving the product so that it does the job better than any alternative.¹²

Behind every great product there is a person with great empathy for the customer, insight into what is possible, and the ability to see what is essential and what is incidental. This person has a deep understanding of the customer as well as her own teams’ capabilities. She operates from a strong basis of knowledge and confidence. She thinks in terms of delivering superior value to the marketplace, and she defines good products that can be executed with a strong effort. This person may have the title of product manager or may happen to be anyone on the product team from an engineer to a company founder—the key is that this role must exist and the responsibilities carried out by someone with the skills and talents the tasks demand.

When we see struggling development programs, we usually observe that the champion role does not exist. There are several different models for implementing the role of champion. The best models clarify who has responsibility and accountability for the success of the product.

Consider the Sienna. The first version of the Toyota minivan didn’t sell particularly well. When Chief Engineer Yuji Yokoya set out to improve the vehicle, he knew he needed more than focus groups and voice-of-the-customer data. So he followed Toyota tradition of genchi-genbutsu, or “go, see, and confirm.” He drove a minivan—usually a Sienna—for 85,000 km (53,000 miles) through every state in the United States, every province in Canada, and every estado in Mexico. He usually traveled with a key member of the design team, including John Jula, a good-sized engineer who would redesign the seats. As he traveled, Yokoya came to understand what Sienna customers would value: more space, comfortable front seats for parents, a back designed for kids, and family pricing. The resulting 2004 Sienna more than doubled the minivan’s sales and raised the Sienna to the top of a crowded pack.

We recently bought a Sienna minivan. We seriously considered other vehicles, but we found the foot space in the front passenger seat of competing minivans to be cramped. We drive our minivan for days when we are on vacation, so front seat comfort is really important to us. When we test-drove a Sienna, we could tell that John Jula was thinking of us when he designed the front passenger seat of that car.

The chief engineer approach has the advantage of integrating a lot of information in the mind of a single, responsible individual. In addition, the entrepreneurial spirit that ownership creates has a long history of bringing brilliant innovations to the marketplace. Teams love to follow great leaders, because great leaders help make whole teams successful.

Most Open Source projects have a “Strong Project Leader” (or Chief Engineer).¹⁶ These Open Source projects start out with the vision of one individual, and even when many volunteers are working on the project, all code is reviewed and “committed” by the project leader or hand-picked assistants.

The chief engineer approach is not a panacea. It is possible for someone with the title of chief engineer to focus on control rather than leveraging the diverse capabilities of the entire team. This is not a problem in Open Source projects, because it is impossible for Open Source project leaders to attract volunteer developers unless they are “leaders” in the best sense of the word. However, it can be a problem in companies that do not have good training grounds for chief engineers or in companies that believe a chief engineer should focus on task management rather than integrating knowledge.

Many successful software companies were founded by an entrepreneur who combined technical capability with a clear insight into an unfilled market need. eBay is a good example. In effect, these companies were started by chief engineers. Unfortunately, we have seen many successful chief engineers who founded companies become unsuccessful CEOs as their companies grow. They neglect to create new chief engineers to replace themselves, often turning over the job of defining customer value to a marketing department. After five or ten years, these companies often falter as competitors take over the initial market and there is no chief engineer to envision the future and lead teams to create great follow-on products.

When there is a third critical piece of the equation—manufacturing for example—it makes sense to have three leaders for a product development effort. Honda uses a sales, engineering, and development—or SED—system in which leaders from sales, production engineering, and development work as a team to come to key product decisions. Above the SED leadership team, Honda also has a Large Project Leader (LPL), whose role is similar to the Toyota chief engineer.

It is important to provide leadership at the most critical points of a product. For example, at Alias (now part of Autodesk), a Toronto company that makes 3-D graphics products, the user experience is a critical feature of every product. Therefore, two interaction designers are assigned to as many teams as possible with full responsibility for customer research, interaction design, and usability testing.¹⁸ A lot of customer feedback is solicited through contextual inquiry, interviews, surveys, and usability testing. But the interaction designer is expected to integrate that input with a deep understanding of the job the software is trying to accomplish, and design a product that will accomplish the job in a superb manner.

Members of a leadership team must be “joined at the hip” so to speak, creating a unified direction for the entire development team.

Although it does not bring clarity to who has responsibility and accountability for decisions, the shared leadership approach can work for moderate-sized software development projects. In the Open Source community, Apache is a good example of a shared leadership approach.²⁰

At 3M, the development team generally comes to a consensus on key decisions, but in the end, the champion is responsible for the product and breaks any deadlocks. Similarly, at Toyota the basic principle is, “Teamwork is the key to getting high quality work done, but some individual always needs to be responsible.”²¹ In “Who Has the D? How Clear Decision Roles Enhance Organizational Performance” Paul Rogers and Marcia Blenko argue that good decision making is the hallmark of high-performing organizations and clarity of the decision-making roles is fundamental to making good, timely decisions.²²

The development team decided that its main job was to learn—learn about the customers’ job so they could develop just the right features, and learn about what kind of process would provide just enough structure without any waste. The team checked in with the management team on a regular basis to report on status, receive guidance, and get approval to continue to the next checkpoint. At each of these meetings the development team reported on what it had learned and what it planned to learn by the next checkpoint. Except for guidance received at these meetings, the team made both product and process decisions on its own.

The Quicken Rental Property Manager team began by going as a group to interview customers. Team members found that developers asked different questions than did marketing people and that everyone gained a deeper insight because of the various perspectives. They found that the development process didn’t require nearly as much paperwork as before, because everyone heard the same thing from customers.

Team members were energized by the challenge and became thoroughly engaged in developing a new process and a new product. Within a year, Quicken Rental Property Manager was released to reviews that raved about its clean interface and simple setup and operation.

In software development, the equivalent of design for manufacturability is design for operations. Some of the more underrepresented functions on software development teams are computer operations, networking, maintenance, and customer support. Every development team should have members who will challenge the team to consider what kinds of problems arise when software is actually being used in production and what capabilities are necessary to both avoid and recover from those problems.

Products, on the other hand, are typically funded incrementally (see Figure 3.3). This incremental funding is a clear signal to all that the scope is expected to evolve as knowledge is gained. The success of product development is generally measured based on the market share and profitability that the product eventually achieves.

There are other differences between projects and products. Projects have a beginning and (apparently) an end. Products, on the other hand, have a beginning and (hopefully) no end. Software is much more like a product than a project, because most good software lives on and changes for a long time. As we noted in Chapter 2, well over half of all software is developed after first release to production.

Projects tend to be staffed with a new team for each project. Products tend to be developed by intact teams that continue to support it over time. Software would be better off supported by an intact team, because the knowledge of the customer, the code, and the domain are difficult to transfer, while most software has a long useful lifespan of upgrades and improvements.

1. Software companies do research to really understand what the market wants, so they can come out with products that will sell. If they do this poorly, they won’t last long. In fact, software companies update their market research continually, always looking for better ways to serve the market. Because they can’t demand that their customers get involved in the system design, software companies devise all manner of advisory panels and focus groups to discover firsthand what customers really need. Too often IT departments skip the marketing step assuming that someone else has done the market research and are surprised when their products don’t meet the business needs.

2. Software companies sell to highly competitive markets, so they have to keep their costs in line. They design products that are simple enough that they can develop and maintain them cost-effectively, while making sure the feature sets provide their customers a compelling reason to buy the software. Too often IT departments assume that a list of business requirements are all essential features of the system, even if very expensive features are involved. They have little incentive to perform the same cost/benefit balancing act that software companies must play to stay in business.

3. Software companies realize that if customers are not successful with their products the company will not have a sustainable business, so it looks for every opportunity to help customers be successful, creating a broader revenue base for themselves while ensuring their products are successful in the marketplace over the long run. Too often IT departments feel that success with the systems they deliver is the responsibility of the business unit. While it is true, as we discuss below, that business units ought to be accountable for the success of software development efforts commissioned by their business, it is also true that the IT department is not successful unless its products contribute to the success of the business.

Many IT departments use the project model for software development, but the project model comes from the contracting industry, where trust is not part of the contract. In order to create healthy IT–business collaborations, we suggest that a product model be adopted, because the incentives built into this model are much more likely to produce a collaborative relationship. When IT is inside a company, there is no reason, really, to set up the we-they model for doing business that projects were designed to deal with. In particular, you do not need to fix scope at the beginning, you do not need customer sign-offs, you do not need to monitor detailed scope to schedule, and you do not need to do everything that your customers say is important. Instead, you need to work in collaboration with your business partner to deliver the most business value in the shortest amount of time for the lowest cost, help them to use the system effectively, and continue to deliver more and better features over time.

The problem of accountability is not unique to IT organizations. It occurs any time people on the same team work for different organizations with different ways of measuring performance. For example, an organization developing embedded software might be managed separately from the hardware development department. A consulting firm working for a business clearly has a separate management structure from its client.

It is not particularly effective to subdivide the effort along organizational lines and then have one part of the development team give “requirements” to the other part of the team. This approach has a tendency to obscure the overall business objective of the joint venture, and has a long history of generating suboptimal results. It is far more effective for members of a complete cross-functional team to share responsibility for achieving the business results that justified the funding of their work.

But in the end, there should be a single point of responsibility for the overall business results of an IT investment. We believe that this accountability should rest with the business funding the effort. When business leaders manage IT investments with the same rigor they bring to running their business, these investments will be more likely to produce significant business results.²⁵

2. In Chapter 10 we describe a single number that is a good measurement of customer satisfaction, called a “net promoter score.” Compute the net promoter score for your customers. Create a simple survey that asks your customers how likely they are to recommend your product or service to a colleague on a scale of 0–10. What percentage of responses are 9s and 10s? This is your promoter percentage. What percentage of responses are 0–6s? This is your detractor percentage. Subtract the detractor percentage from the promoter percentage. Is the net score positive or negative?

3. Make a list of all the programs or projects that are currently active. For each effort, write down the name of the current leader or leaders. How many leaders does each effort have? Have you written down someone who provides both a market and technical leadership for each effort? Is there any correlation between how well a project is doing and its market/technical leadership (or lack thereof)?

4. Complete Teams: Do you have operations people on your team? Is someone from tech support regularly consulted when designing new features? Are testers involved in development right from the start? When do technical writers get involved? Are customers or customer proxies treated as full team members?

5. Projects / Products: Are development efforts funded incrementally or all at once? What are the success criteria of a development effort? Are teams kept intact or do people regularly move to new teams? Do teams maintain the code they develop? Who is accountable for the business results of the money allocated to software development?

2. From the Google Web site, www.google.com/corporate/tenthings.html.

3. PC Magazine, December 14, 1999, p. 104.

4. From the Google Web site, www.google.com/corporate/tenthings.html.

5. “Google’s Missing Piece,” by David A. Vise, Washington Post, February 10, 2005, p. E05.

6. “How Google Grows...and Grows...and Grows,” by Keith H. Hammonds, Fast Company, Issue 69, April 2003, p. 74.

7. From http://video.google.com/videoplay?docid=-8618166999532839788.

8. Sergey Brin and Lawrence Page, “The Anatomy of a Large-Scale Hypertextual Web Search Engine,” Computer Networks and ISDN Systems, 30(1–7):107–117, April 1998.

9. This quote is from Thomas Edison.

10. Kano Noriaki, Nobuhiko Seraku, Fumio Takahashi, and Shinichi Tsuji: “Attractive Quality and Must-Be Quality,” Hinshitsu. The Journal of the Japanese Society for Quality Control, April 1984, pp. 39–48.

11. From Inside Intuit by Suzanne Taylor and Kathy Schroeder, Harvard Business School Press, 2003.

12. Clayton Christensen, Scott Cook, and Taddy Hall, “Marketing Malpractice: The Cause and the Cure,” Harvard Business Review, December, 2005.

13. Kim Clark and Takahiro Fujimoto, Product Development Performance, Harvard Business School, 1991.

14. “Behind Every Great Product—The Role of the Product Manager,” by Martin Cagan, Silicon Valley Product Group; white paper downloaded from www.svproduct.com. February 7, 2006. Used with permission.

15. Information in this paragraph is from Chapter 7 of Durward Kenneth Sobek II’s “Principles That Shape Product Development Systems: A Toyota-Chrysler Comparison,” a dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Industrial and Operations Engineering) at the University of Michigan, 1997.

16. See Eric S. Raymond, “The Cathedral and the Bazaar,” www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/, 2000.

17. See Suzanne Taylor and Kathy Schroeder, Inside Intuit, Harvard Business School Press, 2003.

18. Lynn Miller, director of user interface development, Autodesk, Toronto, “Case Study of Customer Input for a Successful Product,” Experience Report, Agile 2005.

19. Sobek, Ibid. Sobek personally observed this team in action and reported on it in his thesis.

20. See Roy T. Fielding, “Shared Leadership in the Apache Project,” Communications of the ACM, April 1999.

21. James Morgan and Jeffrey Liker, The Toyota Product Development System: Integrating People, Process, and Technology, Productivity Press, 2006, p. 103.

22. Paul Rogers and Marcia Blenko, “Who Has the D? How Clear Decision Roles Enhance Organizational Performance,” Harvard Business Review, January 2006.

23. Reported by Soni Meckem at the Lean Design & Development 2005, Conference, Chicago, March, 2005.

24. “When IT’s Customers Are External,” by Simon P. MacGibbon, Jeffrey R. Schumacher, and Ranjit S. Tinaikar, McKinsey Quarterly, Q1 2006.

25. See “Who’s Accountable for IT?” by Dan Lohmeyer, Sofya Pogreb, and Scott Robinson, McKinsey Quarterly, December 7, 2004.