You never forget being half naked on a fairly full airplane. But what can that teach you about innovation or new product development? I will explain.
It is often reported that nine of every 10 new product ideas/startups fail. Think about that for a moment. Entrepreneurs and intrapreneurs spend 90% of their time building things nobody wants. Sadly, I have witnessed this many times throughout my career. I agree with “Running Lean” author Ash Mayura when he says, “Life’s too short to build something nobody wants”.
As a member of the CA Accelerator team, I help budding intrapreneurs avoid this, and other, traps. I have learned that one of the key reasons innovators fall into this trap is that they do not adequately assess or test their assumptions. While explaining the criticality of this to the Accelerator team, I was reminded of a personal experience I had several years ago during a flight from San Francisco to New York.
About halfway through that five-to-six hour early morning flight, I visited the washrooms at the rear of the aircraft. My tired eyes were thankful that the light in washroom was dim, but seconds after I entered they were pounded by a blinding light. I was greeted by the shadowy figure of a flight attendant looking down at me. The door of this washroom faced the front of the aircraft, and as my eyes focused I realized I could see all the way to the cockpit door… as well as the other passengers. After an awkward silence I asked, “Um, can I help you?”
Together we determined that she had thought a person who had been in the washroom before me was still in there. She had delivered a service—that I definitely did not want or need—based upon an incorrect hypothesis. So how can we avoid this?
In the Accelerator, one of the key tools we use to help avoid this is the hypothesis tree. Our hypothesis trees typically have four levels. We begin by documenting the problem our new idea will address. In the second level, we document one or more solutions we believe solve the problem (the product). Though these things are typically well-defined prior to the creation of the tree, at times documenting them in this format results in deeper thinking about their relationship to each other and the customer, and one or both will be adjusted.
We then ask our new business teams to think about the assumptions they made which led them to believe that each solution element actually addresses their potential customers’ problem. Substantial changes to all three levels often occur at this stage. Finally, we ask them to document, in the rightmost column, ways they can prove or disprove their hypotheses. That column essentially becomes a pick list of experiments for subsequent sprints.
Throughout this exercise the team develops a clear plan to validate their problem-solution fit. It is important to note that each tree is a living document and is updated as experiments are conducted and as hypotheses evolve. This approach has helped us not only to avoid building something nobody wants, but it also helps us to develop more relevant solutions and to focus on the highest value work.
Had the flight attendant performed a more careful analysis like this, she may have figured out that her (flawed) hypotheses (a passenger she observed entering the washroom before me was still in there) might have been better tested by simply knocking on the door and asking if everything was OK.
George is co-author of “The Innovative CIO”
This blog is cross-posted at Highlights
You can follow @GeorgeDWatt on Twitter
Innovation, Technology, and Life in the Cloud 