Failure is fundamental to the success and speed of innovation. How? Let me explain.
There is an idea in innovation literature and theory called “fail early” or “fail forward,” or something to that effect. They all mean and want the same thing, but I feel like the essence of the message often gets lost. I think that is why I see a lot of articles calling for the “fail early” movement to go away because failure is bad and cost a lot of money. They are completely missing the point. I want to use this post to clear up some things up about why and how this should be done.
Explained in the simplest term I can manage: failing early is all about learning quickly: Learning sooner rather than later.
What I really mean by “failing early”
The term “failing early” has a different meaning to different people, but it’s a common term many innovators and entrepreneurs recognize. That is the only reason I am sticking with it for this post. Some words might describe this better, but let’s just stick with “fail early” or “fail fast” as the standard ones for now.
The point is, of course, (for me at least) not to fail your business or idea as soon as possible. At least that is not the goal. I mean, you don’t want to fail, exactly. The point is to learn quickly without spending too much time and money. And you do that by testing your idea early and often to figure out two things:
- Does the idea have merit?
- What do I need to do to make it better?
If an idea has no merit, that is a good thing to know before you have spent months or years on creating something nobody wants.
If an idea, at least potentially, has merit you need to figure out how you can make it great! I’m sure you can agree that when making something, you want it to be good.
To do these things, what we really want is to learn quickly. Failing is a great way to learn, but it is not the goal. You can’t be afraid of failure either, as that will halt your learning!
We will get back to how to fail (or learn rather), but first, let’s look at why failing early is so important.
Why fail early?
There is two main reason why failing early is important:
- Save money
- Make great things
They both boil down to the need for learning quickly. Learn quickly to avoid wasting money and to be able to make the right things.
This is where the term “failing early” comes short because it only captures the “how,” not the “why.” Failing in itself is not what you want. What you want is to learn quickly to save money and make great things! And you do that by “failing quickly.” Sort of. We’ll get back to what we actually mean by “failing.”
Let’s dive a bit deeper into why failing early provides these two quite amazing effects.
Save Money (and time) by failing early
If you find out after one week of working on your idea that is is completely useless, and nobody wants it, instead of figuring it out after three months, you certainly have saved a lot of time and money right there. It’s that simple; Fail early, instead of later.
Innovation is going to have a high failure rate just because it by nature is very uncertain and “risky.” If you want to keep innovating, you are going to fail more often than not. And if you know that you are going to fail a lot, would it not be better to turn up the speed and fail quicker and cheaper? I think it makes perfect sense.
Make great things by failing early
Great things = Things that the user loves.
It’s easy to build something you will love. It’s much harder to build something that other people will love.
To build something the user loves, you can’t sit inside and guess what they want. You shouldn’t use your previous experience as the perfect measure. You have to be sure that what you are building is something the users need, want and will love.
To create something truly innovative and great, you need to tap into an actual problem and solve it in a way that will delight people. There is just no way around some research to get to those truths. The truth about what works well, what doesn’t work, what needs to be work differently and so on.
How to fail fast (and cheap)
The entire point is to learn as quickly and as cheaply as possible. You want to test out your idea without building an entire platform or product first. The way to do that is by testing out your ideas with low-fidelity tools. Pen-and-paper UI, mock-ups, drawings and the most simple tools possible to test out the basic assumptions about your idea.
Ask the right questions
To fail as quickly as possible, you need to find the right things to test. Find a list of hypotheses that support your idea. These will be basic assumptions that need to be true for your idea to make sense. You also need to find the high-risk critical assumptions that will make or break your idea.
The point is that you have to figure out if your idea is good or not. And you won’t do that by asking people if a UI design you came up with was beautiful or not. Also, you won’t get the correct answer if you experiment on assumptions that are optional for your idea to work.
Find the most fundamental and important assumptions about your idea, form hypotheses about them and run experiments to validate. Keep in mind that you can be creative here. Test assumptions in isolation or combination to get the most out of your time. Test your assumptions using any tools you’d like. The experiments can be very far removed from what you want to create in the end - as long as it validates your hypothesis.
Rapid Prototyping
Rapid Prototyping is like a field of its own. But the general principles around most techniques that fall under Rapid Prototyping is that you want to create cheap and quick prototypes, get feedback and then do it all over again (rapidly…).
I like to think of prototypes in terms of different levels of fidelity. Low fidelity prototypes are quick, cheap and get you honest feedback (because people are less likely to feel awkward criticizing something you obviously have not put a lot of time into). Higher fidelity prototypes are great for getting more detailed feedback and for fine-polishing designs.
Start out with low-fidelity prototypes. That means the output will be very rough. Possibly pen and paper. The point is just to visualize your ideas and get feedback. You could certainly use some mock tool to create fake apps if you want, but you should be able to build your first prototype in one single day. That means no code will be involved. You just have to communicate your intent! The question you want an answer to is: does this idea hold any merit? Can I explain it to anyone in straightforward terms with simple tools? Does anybody want/need this?
As you get some initial feedback, you can start creating higher fidelity prototypes. Wireframes, rough UI layout in a mock tool or possibly a simple coded tool with lots of fake back-end stuff. The point here is to get more insights into your idea around user flow and user interaction. The questions you want an answer to is things like: Does the idea make sense for the user? Is the general design of the idea somewhat intuitive? How do I need to design this thing?
You create high-fidelity prototypes as well, but I prefer just to create a simplified, but real, UI at this point and just fake out some of the back-end things to showcase how the system will look and work. It’s more about getting small detail feedback and “sell” your idea at this point. If you get to this point, you should, in theory, have answers to all the critical questions about your idea. You should feel fairly confident that your idea holds water.
Hypothesize, Test, Repeat
With all the feedback you get you can’t just say “Phew, that was hard. Glad I’m not doing that again!”. You have to take everything you learned and put it into the next iteration of your idea. And then you do it all over again.
Until you are done, you need to continue learning. And if you don’t want to throw money out the window, or if you want to make a great product (and make money), you better keep failing (…learning).
Not all feedback is good feedback!
Something important to keep in mind is that you don’t have to implement all the feedback you get. You have to be smart about it. If the feedback doesn’t sound like something you expect a target customer also to believe, you might want to gather more data to prove or disprove your hypothesis. Only having one data point is usually a bad thing.
On the flip-side of that, you also have to keep in mind that some people might give you too positive feedback. Or you might only hear the positive parts because you are so in love with your idea. Try to separate yourself from your idea - at least until it has been proven.
Failing is learning
We can probably agree that failure is a very negative word. But in this context failure is about feedback and learning.
Learning quickly (fail early) is something you do to save money and build great things. I think that should be reason enough for trying hard to innovate that way.
The faster you can fail (learn), the faster you can innovate. Go out there and innovate at the speed of fail!
Follow me on Twitter: @gjermundbjaanes