Hari Nallan, CEO, Think Design Collaborative Pvt. Ltd.
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 of it.
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 customers. 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 that the outcome will always be positive. By inculcating the concept of 'failing early' in organisational practice, we could drastically change the way things are conceptualised, built and delivered… failing early gives us a chance to succeed early (as well) and it now seems a no brainer that it is better to fail and succeed sooner than later.
- Start early: Whatever your mission, it is important to get on to 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; 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 … prototype instead. 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 question what they do, constantly. While it is in their very nature to do so, it is important to keep from this habit. It can lead to demoralisation 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 drawing board’ attitude: Be cognisant 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 costs.
- Avoid ‘expediency as a rule': ‘I want it yesterday’ is a very commonly used phrase among innovators. Well, then, 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 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.
Wish you a happy innovation!
