How to cut your innovation speed in half
Focus on your customer’s needs and iterate.
Workshop ideas. (source: Barry O'Reilly, used with permission)
“If I knew where all the good songs came from, I’d go there more often,” so said Leonard Cohen when asked how he wrote classic hits like “Suzanne” and “Hallelujah.” Formulating the ideas behind timeless hits is not an easy task—serendipity, stimulation, and skill all equally play their part.
Yet, in large organizations, a lack of ideas is rarely the problem. Business leaders and executives are inundated with suppositions, proposals, and pitches on how to increase, invent, and imagine new revenue streams. Most often, the biggest challenge is not conjuring up the concept—it’s killing it as quickly and cheaply as possible.
Learn faster. Dig deeper. See farther.
In The Principles of Product Development Flow, Don Reinertsen’s research concluded that about 50% of total product development time is spent on the ‘fuzzy front end’—i.e., the pitching, planning, and funding activities before an initiative starts formal development. In today’s fast-paced digital economy, the thought of spending half of the total time to market on meetings and executive lobbying with no working product to show isn’t just counterproductive and wasteful—it’s ludicrous.
Furthermore, the result of all this investment is often an externally researched, expensive, and beautifully illustrated 100-page document to endorse claims of certain success. The punchline presented through slick slide transitions is “All we need is $10 million, two years, 100 people and we’ll save the business!” Science fiction, theater, and fantasy rolled into one.
What is really needed is a systematic, evidence-based approach to managing the uncertainty that is inherent at the beginning of any innovation process. Our purpose when commencing new initiatives is to collect information to help us make better decisions while seeking to identify unmet customer needs and respond to them.
New business possibilities are explored by quickly testing and refining business hypotheses through rapid experimentation with real customers. Our goal is to perform this activity as early, quickly, and cheaply as possible; lengthy stakeholder consensus building, convoluted funding processes, and hundreds of senior management sign off sessions is not.
Decisions to stop, continue, or change course must be based on the ‘real world’ findings from the experiments we run, not subjective HiPPO (Highest Paid Person’s Opinions) statements about how they’ve “been in the business for 30 years and know better.”
Imagine a world without costly executive innovation retreats, and where the practice of pitching business cases at annual planning and/or budgeting cycle meetings is extinct. Instead, a similarly sized investment is assigned to small cross-functional teams to explore given problems, obstacles, or opportunities throughout the course of a year. Over a short fixed-time period, a team creates a prototyped solution to be tested with real customers to see if they find it valuable or not.
We are investing to reduce uncertainty and make better decisions. You are paying for information. The question is really: how much do you want to invest to find out?
In his book, How To Measure Anything, Douglas Hubbard studied the variables that hold the most information value when making investment decisions in software projects. The results showed two important insights: how much a project costs and how long a project is going to take held little significance in terms of understanding if a project would be successful or not. What really mattered was (1) will the project be cancelled, and (2) will anyone actually use it.
Now, let’s compare how investment decisions are made in the traditional and experimental worlds.
A traditional business case is a set of untested hypotheses and assumptions, backed up by subject matter experts, case studies, and market research. In an experimental approach to innovation, real data is collected from working product prototypes that have been tested and informed by feedback from real customers. Which of these strategies do you believe will most effectively provide answers to Hubbard’s most valuable variables?
Similarly, what happens next? In a traditional world once a business case is signed off, detailed requirements are created and a project is initiated to build, integrate, test, and (hopefully) release the entire recorded product requirement backlog—only once all the requirements have been captured, built, and released will we find out if our customer will use any of it. With an experimental strategy, we already have validated or invalidated our early working product prototype upon which we can stop, pivot, and/or immediately build new features and enhancements based on the customer feedback we collected through our early testing cycles.
Finally, and the most telling and critical piece: the most expensive way to find out if a product works is to build the entire product and then release it. The key to rapid experimentation is not to prove that all our ideas are winners, but to kill losing ideas early to cut out wasted effort, time, and further poor investment.
Summary
Not all our ideas will have a positive impact on the business. By testing early and often with the real people we are designing for—our customers—we can use their feedback to make more informed and evidence-based investment decisions for the future success of our business.
Like Cohen said, “I think you work out something. I wouldn’t call them ideas. I think ideas are what you want to get rid of… [they] dissolve into deeper convictions.”
Next time you have a new initiative in your organization remember these six principles:
- Stop typing documents. Start testing with real customers as soon as possible.
- Our mission is to discover as quickly and cheaply as possible the most valuable information to base further investment decisions on—i.e., will the project get cancelled or will anyone use it. Optimize for this.
- Define success before you start experiments. You need to hold yourself accountable to the results of your experiments to make decisions to stop, change course, or continue with your activities. Doing that after the fact isn’t an experiment. It’s “Experiment Theatre.“
- Form small cross-functional teams and equip them to explore problem domains at speed.
- When uncertainty is high, favour shorter, faster feedback cycles to generate information to make the next decision.
- Remember, true progress is more about killing bad ideas early than proving you’ve discovered the next unicorn idea.
References
Leonard Cohen: ‘All I’ve got to put in a song is my own experience’
How To Measure Anything, Douglas Hubbard
The Principles of Product Development Flow, Don Reinertsen