The Right Kind Of Wrong

Making a mistake is not a nice feeling, especially when that mistake is public to some degree. 

Building a product company the vast majority of our mistakes are out in the open by default. Making mistakes in this context you become aware of a certain vulnerability. Not only to your fellow company builders but also, perhaps more keenly, to our users. It’s a vulnerability you probably didn’t know you had until the mistake is made. On balance, it’s one of the more emotionally heightened moments of startup life.

So lets talk about making mistakes and getting things wrong.

There are 3 points I’d like to make here:

  1. At some point things will go wrong. This is practically inevitable.
  2. However, there is a right kind of mistake.
  3. If you make mistakes the right way, it’s totally okay.

Lets talk about each in turn.

Things Will Go Wrong

There’s a great line in Fight Club: “on a long enough time line the survival rate for everyone drops to zero”. It’s the same with startups.

Startups often establish new categories and new markets, creating something that has no proven or pre-existing model. The surface area of unknowns is therefore far greater than the known, and in this environment of uncertainty getting things wrong at some point is almost inevitable.

However - while we cannot escape making mistakes altogether, I’d suggest we can at least make the right kind of mistakes.

The Right Kind Of Wrong.

Don’t worry I’m not about to tell you how great failure is, TED talk style and how we should all celebrate it. Failure is a bad thing and don’t let the startup heroes tell you otherwise. 

The right kind of failure is defined by two things. One that happens before and one that happens afterward.

Before: have good reasons.

Good reasons don't have to be a mathematical surety of successful outcomes. It can just be some data you've gathered or some qualitative research that you think demonstrates a theme. 

Good reasons can include the obvious things like “all our customers are complaining we don’t have So-And-So, and the value add and business case is clear”. But also include less guaranteed outcomes: “Well we have never tried doing ABC, so we have no idea whether our users will respond to it, why don’t we try a small scale experiment?”.

The question to ask yourself is: can I articulate why this is something we should try?

Intuition is a great start, but if you can't clearly verbalise the reasons, you should probably stop and reflect if it makes sense to go ahead.

Afterwards: you/we should have learnt something.

The real sin in getting things wrong is not learning anything from the mistake.

Forensic analysis of mistakes is really, really valuable. This is where we compare our hypothetical models of the world/market/people/needs/etc with actuality and note the difference. It’s in the expected versus actual outcome gap that we can improve and update our model.

Albert Einstein’s criteria for insanity is: “doing the same thing over and over again and expecting different results”. If we make mistakes without carefully and consciously updating our hypothesis models, we are doing just that.

We’ve Got Your Back

For all this talk of failure the thing is: Qwilr wants you to be brave. That’s how we keep pushing our product and our company forward. That’s how we win. This kind of intellectual bravery means pushing into unknown territory, where mistakes and missteps are far more likely.

To be clear: making mistakes the “right” way is totally fine (it better be because I’d wager I’ve made more mistakes than any other member of the Qwilr family!).

If you have good reasons for trying something but it doesn’t work: that’s okay. Provided we learn from it, we put a new system in place or we refine or redefine our thinking: that’s totally fine. 

If you make mistakes the right way your company mates will support you, the founders will support you and in general, with good reasons, yes, our users will support you too. 

So go out, be brave, and if mistakes are made, we’ve got your back.

Onwards and Upwards,