I came across the concept of failing early a few years back when I understood the several facets of Design Thinking. A decade later, today, this is catching up like wildfire across established technology companies and start-ups alike. Let us get an understanding of why and how.
Hari Nallan - July 2017
Challenges Associated with the Implementation
There was a time when a product or service was well thought out. Designed, developed, brushed up and released to its customer. Over time, the creators would understand that many assumptions that were made earlier didn’t hold good; and it demanded revamp of what was built earlier. The exercise was expensive, time consuming and highly labour intensive, As a result, it took several months to manage change and by that time, it again demanded fresh thinking. It felt like a cul-de-sac. Come concept of “failing early”
The Introduction to ‘Failing Early’
Concept of failing early addresses these specific issues around new product, service or process innovation.The underlying concept is that, when we are creating something out of the box, the outcome could be in any direction that we couldn’t have imagined before. It is hard to accurately predict the outcome and it’s not fair to expect the outcome will always be positive.
By inculcating the concept of ‘failing early’ in organizational practice, we could drastically change the way things are conceptualized, built and delivered. Failing early gives us a chance to succeed early (as well) and it now seems to be a no-brainer that it is better to fail and succeed sooner than later.
Above all, with company wide adoption, ‘failing early’ as a concept could encourage people to innovate much more than they do today. How do we do it?
Start Early
Whatever your mission, it is important to get on the bandwagon early. Let’s call it phase zero, when nothing is known, even the requirement or well-articulated problem statement isn’t in place yet. What we would have is a bunch of motivated people with a conceptual picture of what needs to get done.
Break Down
Instead of going for a ‘big bang’ approach, break your mission down to smaller tasks, separating each task with its own goal. Breaking into smaller chunks also mitigates ‘failing entirely’. It is more likely that you’ll fail in certain tasks, while you succeed in others. In this context, breaking down helps in reducing the larger risk.
Prototype
Don’t build the whole solution, instead build a prototype. Whether it’s a product, a service or a new process innovation, just prototype it in enough detail to get reasonable test results. With technology rapidly becoming consumerized and affordable, we can create our prototypes with minimal investment of resources, time and effort. It takes just a few hours to build a rapid prototype!
Validate and Iterate
Stay open minded while validating. Accept failures, create a context for success and iterate. Its fine to fail at this time, since you’ve invested very little time and resources compared to your ‘big bang’ approach.
A process of continuous iteration, prototyping, validation and iteration again leads to results that are mature over time; and accepted progressively by its users.
Cautious Steps Needed to be Followed
Innovators by their very nature are restless, and constantly question what they do. While it is in their very nature to do so, it’s important to keep away from this habit. It can lead to demoralization of teams, expensive investments in change management and confusing updates to the users. You may find these tips handy:
Avoid Self-evaluation
While, we as creators have an understanding of a much bigger picture than our evaluators, we are the wrong people to evaluate our own creation. Always involve those who weren’t a party to the creation process. It could be your own colleague.
Avoid Back to the Drawing Board Attitude
Be cognizant of the fact that while it’s instinctive to change everything, it is very important to have the maturity to fix only what is broken. It is a common trap that innovative people get into and it is prudent to avoid this trap at all cost.
Avoid Expediency as a Rule
‘I want it yesterday’ is a very commonly used phrase among innovators. ‘Well, you should have started a while back!’ You can build things very fast today, much faster than a decade back, but ‘I want it yesterday’ isn’t a phrase that will go down very well with your teams at all times. Expediency is required, but as an exception, not as a rule. I’m sure you don’t want to be alone creating what you wanted. It’s a trap you don’t want to get into.
