LITMIR.BIZ

Скачать книгу

      I always like to clarify that this example is by no means an attempt to make fun of NASA. I tell the story a certain way to highlight the point I want to make. Indeed, the conclusion that NASA came to turned out to be the best one. There are good reasons not to use pencils in space: the lead tips can break off and float into an astronaut's eye or cause a short in an electrical connection. After the tragic Apollo 1 fire in 1967, NASA required all objects in the cabin to be nonflammable, including the writing instruments. So the Space Pen actually was a useful innovation, which the Russian space agency also adopted.

      When I mention the space pen in my talks, there is often someone who claims that the story is an urban legend. However, it isn't, as NASA explains at http://history.nasa.gov/spacepen.html, and the Fisher Space Pen Company confirms at http://fisherspacepen.com/pages/company-overview. The key point of debate usually is, who spent the money on research and development: NASA or Fisher? Fisher did, as I pointed out above.

      Problems Define Markets

      Early in my product career, Intuit's founder Scott Cook helped me solidify the concept of problem space versus solution space when I heard him talk about TurboTax. Speaking to a group of product managers, Scott asked us, “Who is TurboTax's biggest competitor?” Multiple hands shot up. At the time, the other major tax preparation software in the market was TaxCut by H&R Block. After someone confidently answered, “TaxCut,” Scott surprised us all by saying that the biggest competitor to TurboTax was actually pen and paper. He pointed out that, at the time, more Americans were still preparing their taxes by hand using IRS forms than all tax software combined.

      This example highlights another advantage of clear problem space thinking: having a more accurate understanding of the market in which your product is really competing. Those of us in the audience were narrowly thinking in solution space of the “tax preparation software” market, as defined by the two main software products. Scott was thinking in problem space of the broader “tax preparation” market – one that would also include tax accountants to whom customers delegate their tax preparation. As the previous chapter discusses, a market is a set of related customer needs, which rests squarely in problem space. A market is not tied to any specific solutions that meet those needs. That is why you see “market disruptions”: when a new type of product (solution space) better meets the market needs (problem space). New technology can often enable a market disruption to deliver similar benefits at a much lower cost. Voice-over-Internet-Protocol (VOIP) is a great example of a disruptive technology that has replaced traditional telephone service. At first, the sound quality of VOIP calls couldn't compare to that of traditional phone lines, but the cost was so much lower that it offered a superior solution for much of the telephone market.

      The What and the How

      As a product manager at Intuit, I learned to write detailed product requirements that stayed in the problem space without getting into the solution space. We were trained to first focus on “what” the product needed to accomplish for customers before getting into “how” the product would accomplish it. You often hear strong product teams distinguishing between the “what” versus the “how.” The “what” describes the benefits that the product should give the customer – what the product will accomplish for the user or allow the user to accomplish. The “how” is the way in which the product delivers the “what” to the customer. The “how” is the design of the product and the specific technology used to implement the product. “What” is problem space and “how” is solution space.

      Outside-In Product Development

      A failure to gain a clear understanding of the problem space before proceeding to the solution space is prevalent in companies and teams that practice “inside-out” product development, where “inside” refers to the company and “outside” refers to customers and the market. In such teams, the genesis of product ideas is what one or more employees think would be good to build. They don't test the ideas with customers to verify if the product would solve actual customer needs. The best way to mitigate the risk of an “inside-out” mindset is to ensure your team is talking with customers. That's why Steve Blank urges product teams to “get out of the building” (GOOB for short).

      In contrast, “outside-in” product development starts with an understanding of the customer's problem space. By talking with customers to understand their needs, as well as what they like and don't like about existing solutions, outside-in product teams can form a robust problem-space definition before starting product design. Lean product teams articulate the hypotheses they have made and solicit customer feedback on early design ideas to test those hypotheses. This approach is the essence of Lean – and was actually first advocated for years ago by practitioners of user-centered design.

      Should You Listen to Customers?

      Some people criticize user-centered design by saying that talking with users will not lead you to come up with new, breakthrough solutions. Those critics like to quote Henry Ford, who famously said: “If I had asked people what they wanted, they would have said a faster horse.” They also like to point out the example of Steve Jobs and how Apple has launched many successful products using what seems to be a very “inside-out” product development process. In fact, Steve Jobs cited the same Henry Ford quote in a 2008 interview with Forbes.

      It is true that customers are not likely to identify the next breakthrough solution in your product category. But why would anyone expect them to? They are not product designers, product managers, or technologists. The fallacious thinking comes in when people use this argument to rationalize why it's not important to talk with customers or to understand their needs and preferences. Most people who make that argument are really using it as an excuse to not talk with customers because they want to adopt an “inside-out” philosophy. They think that they have all the answers and that talking with customers is a waste of time. They don't understand problem space versus solution space.

      It's likely true that customers won't invent a breakthrough product for you; but that doesn't mean it's a waste of time to understand their needs and preferences. On the contrary, a good understanding of customer needs and preferences helps product teams explore new potential solutions and estimate how valuable customers are likely to find each one to be.

      Critics of user-centered design like to justify their views by saying, “Apple doesn't talk to customers.” At Apple's 1997 Worldwide Developers Conference, Steve Jobs shared a more enlightened perspective that is consistent with the Lean Product Process when he said:

      A Tale of Two Apple Features

      Even though Apple does indeed have a reputation for not soliciting customer feedback on products before they're launched, a large part of why their products are so successful is because, despite that, they have an in-depth understanding of customer needs. Consider the Touch ID fingerprint sensor that Apple introduced with the iPhone 5S. Touch ID utilizes advanced technology: the high-resolution sensor is only 170 microns thick and captures 500 dots per inch. The button is made of sapphire crystal – one of the clearest, hardest materials available – to protect the sensor. The button also acts as a lens to precisely focus the sensor on the user's finger. Touch ID maps out individual details in the ridges of fingerprints that are smaller than the human eye can see and can recognize multiple fingerprints in any orientation.

      It's unlikely that any iPhone customer would have come up with such a solution. I would guess that Apple didn't test the solution with many customers before launching it. Despite that, I argue that the iPhone team had a good understanding of the problem

Скачать книгу