I just came across this video where Rita McGrath shares her views on how to fail intelligently. First, do take some time and watch the short video below.
She talks about the 4 different activities that constitute intelligent failure.
How does success will look like?
I think she makes a great point here. One of the biggest challenge that I have seen in innovation projects is they have a big goal and know what success at the highest level looks like – successful product launch, getting the next round of funding, getting approval from the management to go into production, etc. However, the team does not necessarily know what does success look like at the micro level – for the different activities that they are doing. For example., what does success look like when you are interviewing a potential user for research; what does success look like when you are building a prototype; what does success look like when you are trying to figure out the right channel for your product to be sold through; what does success look like when you are looking for potential partners. You get the point. It would make life and the process of innovation much easier to manage if at the start of any key activity of the project, the team already defines and knows what success in the activity looks like.
Assumptions to Knowledge
The only way you actually innovate is through making small or little bets on your assumptions and testing them out. This is also how scientists work. They try and understand what is happening in and around their field of research. Then they make assumptions of causality. Then they create a hypothesis based on their assumptions. They also know the results that they should see, if their assumptions and the hypothesis are correct. Then test go out and test the hypothesis and explore the results of the test. If the test results are exactly what they had assumed, their assumptions seem to hold good and they move on to making subsequent assumptions (if this is true, then I think this should also be true) and the process goes on. Every assumption that is being tested is either confirmed & becomes knowledge or denied and therefore dumped as inaccurate.
What is critical is that in an innovation project, this entire process be done explicitly rather than implicitly and the results of the experiment shared with the entire team.
Limit Uncertainty
This is again a great advice and follows the scientific method of enquiry. In order for you to be able to test your assumptions, you need to be able to single out the causality or the number of elements that could impact the assumptions. This is the reason, why you will find that most scientific experiments are done under controlled environment first and are progressively moved to the real world based on the confirmation of different assumptions that is already known knowledge. Similarly, for an innovation project to succeed, you need to be able to start with the place where you are able to control the different variables and progressively increase the variability based on your knowledge.
Codify and Share learnings
This is probably the area where most innovation projects fail. Irrespective of the success or failure of an innovation effort, it is critical that the team does reflect on the process and share their learnings from the project with the larger teams, so that everyone understands and learns form the effort. This is how we make scientific progress. Scientists report the findings from their experiments in the various journals. Other scientists read and learn from these findings and make their own connections, observations and assumptions, which they can go out and test. This is how you also create a culture of innovation and learning.
I am not sure that this is the comment space for the article by Rita McGrath, but here is a comment on that article. I like what you say but innovation, in spite of what everyone says, is a rush job. Someone has an idea, the CEO integrates it into his 2 year strategy and everyone gets panicked with the pressure of the rush. I have dealt in that world for 30 years and came across a nice little tool that I call: “The 5/67 Rule”. It is a corollary to the 20/80 or 80/20 rule depending on your preference. What it says is this: 5% of the features give you 67% of the benefit of a product. But which 5% will that be? That is the rub. And so a product is put out there with the wrong features and everyone is in a tizzy. But the key to using the 5/67 Rule is that it is OK to be wrong, take input from early adopters and try a new release. A lot goes into this process but you can see how it might work. My point is from a scientific paradigm perspective, you sometimes get paralysis of analysis and that doesn’t work. Try a less expansive, controlled initial release and gradually refine it.