In the worlds of Lean Startup, Lean UX, and Design Thinking (DT), the prevailing wisdom tells us to build the smallest viable thing, test, evaluate, and iterate. The reason being, the more time, money, and effort you invest in the untested, the more you stand to lose. And, the more likely you are to get it wrong.
Let’s face it, until something is validated it’s just an assumption. In that way, fail fast, learn fast, just makes good sense. So what’s the problem?
In DT, for example, there are three steps to take before building. Empathize, define, and ideate. These are all intended to challenge our assumptions so we can build a better hypothesis before we build. Many are jumping straight o build and iterate, and skipping these critical steps.
When we begin with a wild guess rather than an informed hypothesis we’re more likely to fail big and learn little.
Not all failure is equal
We need to get real clear on the fact that not all failures are equal in scale or their ability to provide learnings. Failure is not an absolute condition. Failure spans a scale from insignificant to catastrophic.
The Big Bang Theory: Gradations of Wrong – YouTube
It is a little wrong to say a tomato is a vegetable, it is very wrong to say it is a suspension bridge. – Stuart to Sheldon on The Big Bang Theory
Unless you’re building a suspension bridge or other thing that has the real potential for life and death, most of your mistakes will never reach the catastrophic end of the scale. That said, when it comes to learning from our mistakes, the bigger they are, the harder it is to learn from them.
The reason it’s so hard to learn from bigger failures is due to the number of variables that may have played a role. Did we target the wrong audience? Did we test the wrong features? Were there too many feature, or too few? Were we addressing the right problem? How do we know?
The more variables at play, the more chances we have to focus on the wrong one. These larger failures are most often due to beginning with an uninformed assumption rather than an informed hypothesis.
Before we build a prototype to test, and before we can build an informed hypothesis, we need to test our assumptions. As a traffic court judge once said to me, “When you assume, you make an Ass of U and Me.”
Testing assumptions is the least expensive and most impactful step in failing fast, learning fast. Ask yourself, and your team, questions like:
- How do we know our assuptions are right?
- What data supports that assumption?
- What data contradicts the assumption?
Anyone in science or math knows that no matter how right your answer is, if you start with the wrong assumption, the answer is wrong. Make no mistake, creating a great user experience is a science. For example, BetaMax lost to VHS because it assumed that image quality was more important than the length of the recording. (Sorry if you’re not old enough to remember BetaMax and VHS recorders)
Validate your assumptions by doing Kano analysis, conducting some user interviews, and running surveys. You can often get insights in as little as a few hours or a few days. Use these findings to write jobs-to-be-done (JTBD) stories to help you build an informed prototype for testing. It’s always less expensive to test assumptions than prototypes.
Build a better hypothesis before you build anything else
The quality of our questions determines the quality of our life. – Tony Robbins
It doesn’t matter how we answer the questions above. It only matters how our target audience answers them. It’s easy to believe we figured things out. The unfortunate truth is that or brain is wired to make this happen.
- Our brain is a pattern recognition machine. It excels at this. It’s excellent at this. But there’s a problem.
- Our brain likes to confirm what it knows. It’s called the confirmation bias. We all have, suffer from, it. It’s how it build patterns. We see what we want to see.
Have you ever thought of something and the suddenly everything seems to say you’re right? If you think a certain design pattern is bad, you suddenly find dozens of articles that agree with you. They tell you how they tested the pattern, and sure enough, it doesn’t work. Ever happen to you? Of course it has. It’s happened to all of us. Why?
You likely did a search to find out if others felt the same way. You may have used a search phrase like “Is {design pattern] bad?” or “How bad is {design pattern}?” Google, unsurprisingly, returns thousands of articles about how bad it is. What would have happened if instead you used a search phrase like, “Does {design pattern} work?” or even better, “How well does {design pattern} work?” Guaranteed, you get different results. Try it.
When we know the answer we want, it’s easy to ask the questions that get us that answer. Everyone wants to believe they know the answer, so they set out to find evidence that supports their position. It’s rare that people go out of their way to prove themselves wrong. And that’s also a problem.
Don’t skip user research and jump straight to building something to test. Part of the reason fail fast is possible, is because you’ll always get it wrong the first time. The question is, how wrong? A little, or a lot, or even catastrophic? Up front research can help you build a better hypothesis before you begin building a solution. Talk to your audience first. Ask them about your ideas.
Henry Ford and Steve Jobs were mostly wrong
People are quick to jump on quotes of Ford (still openly debated) and Jobs to support their position that people don’t know what they want or need, so why bother to ask them.
If I asked people what they wanted, they’d say faster horses. – Henry Ford (debatably)
A lot of times, people don’t know what they want until you show it to them. — Steve Jobs.
This is another case of a little wrong or a lot. Jobs is a little wrong. You can ask questions of people and get insightful answers. but, you do have to ask the right questions the right way to make sure you aren’t playing to your confirmation bias.
Ford on the other hand was a lot wrong. There’s at least one clear insight in the answer he anticipated. People needed to get from one place to another faster. Now, it’s up to the innovator to figure out how that happens.
In both cases, these legendary innovator were wrong to think that people don’t what they want or need. For many, there was desire to connect with others faster, from more places, more often, and in more ways. Viola, the iPhone. People needed to get places faster, not have to shovel horse manure, or get rained on while doing so. Viola, the automobile.
Would the average person have conceived of those specific solutions? Unlikely. Do you always need to build something before you know if the need exists? Maybe, but not always. Ask before you build. Reduce the risk of wasted effort. Reduce the size of the failure. In the process you will improve your ability to get insight from you failures. Insights that you can act upon. Insights that increase your chances of success.
I hope you’ll adopt a new mantra. Fail better, learn better.
