Fail Fast, Fail Often : Challenging What the Books Say With Reality

Many big companies want to work with mantro because we are the very culture that is needed to build successful digital business: we are creative, non-hierarchical, hands-on, and have a positive culture of making mistakes. Wait- what did I just say? What is this positive culture of mistakes? After all, most aim not to make mistakes at work…

Can “making mistakes” be an actual goal?

The real goal of a startup is to achieve the Product Market Fit in the shortest amount of time possible. This goal is only achievable working quickly with rapid growth in user numbers.

Why is rapid user growth important? Well, I need a high number of users to develop the product. Even if I use the best Design Thinking methods, observing real users in the product is the best guide. For the market development I have to have a functioning product fast, otherwise, the competition will catch up to me.

Unfortunately, speed often comes at the expense of quality (this rule does not only concern software). No matter what measures we take as a team to protect the quality — these measures slow down the development. A certain number of people only have a limited amount of time in which something can really be done productively.

All this is to say: a culture which allows mistakes is essential for any startup. If even one team member is afraid of making a mistake, that member will be slow. With a team of four to six people, that means lost time and productivity that could be fatal to the business.

Our goal is not blatantly to make mistakes, but it is our goal to learn as much as we can in as little time as we can.

Let me put it like this: when a baby starts walking, falling is not a mistake, but part of learning. In fact, the earlier it falls, the sooner it will be able to walk. This is exactly what we do in product development: We launch MVPs that only fall for the time being. Only when we know what users are doing with it, we will build the product — also on a feature-based basis.

But what about REALLY BIG mistakes?

In addition to this learning process, there are of course big mistakes, simply because someone has legitimately screwed up. Like when learning to ride a bike, falling off your bike is one thing, driving into traffic is something else.

In my opinion, dealing with this dichotomy makes every team a challenge. Most people have learned behavior that mistakes lead to trouble, guilt and consequences. You don’t want team members to feel this, but ignoring the fact that a person has made a mistake leads to frustration in the entire team. With those dynamics and the need to make mistakes in order to see results, what can be done?

A positive error culture is still achievable. You can learn to handle mistakes without frustrating team members or being contradicting. Let’s look at how.

A small example from reality

WerkerApp is a documentation tool for craftsmen, which we founded in September 2017. In addition to a web application, we have an app for Android and iOS. In December, we released an MVP and slowly gained users to learn. After three months, we are now at the point where we put the application on stable “product legs”, because we have certainty which features are needed, and the number of users is steadily growing.

For this process, we had to force the existing users to update the app. That is: We had to lock them out of the old versions. It was planned that we would lock users out of the app overnight — for a maximum of six hours — and then force them to update.

Unfortunately, we made a really stupid mistake and locked out users for two full days from the app. And that felt really, really shitty. You literally see in your mind, how suddenly every craftsman — and really every craftsman — goes on an angry rant in the morning at the bakery about this totally crappy app that simply does not work and NO ONE will ever use the app again.

Responding to Chaos: Two Options

As a founder, this presents me with two main options:

Option 1: Follow the learned impulse
This is perhaps most people’s natural reaction and what we wanted to do at first…

Step one: Imagine the damage the error could cause. “All craftsmen talk bad about WerkerApp — everything goes down the drain, we announce insolvency the day after tomorrow”

Step two: Find the culprit and put him down (I would not like to reproduce my hypothetical wording here…)

Step three: Try to contain the error and cover it up. Write panic emails and say to the outside world, “Apple is guilty!”

Option 2: Work with the error
This is the much healthier, more efficient route, and what we actually did.

Step one: Take a breather and make a plan. Don’t fire anyone in the first five minutes.

Step two: Take action to deal with the error; We notified all affected users and sent a push notification when WerkerApp was available again. We proactively rewarded non-productive users.

Step three: Learn from your mistakes/Consider the damage when it becomes visible; After the shit hit the fan, we’ve changed the workflow for the next app release. We also looked at the positives. 32 users wanted to use the app while we were offline. 6 of them had proactively contacted us and were very understanding. And actually, there hasn’t been any drastic change in the overall (Web, iOS, Android) daily active users per week.

With a mistake like this, there’s unavoidably work for everyone on the team. Customer support needs to reassure annoyed users on the phone; customer success needs to think ahead to proactively educate users; front end developers needs to implement those changes, and prioritize product management and development. In case of doubt, the management and the management have to face the investor.

On “the day of the mistake” (which sounds like the title of a movie), every team member was actively engaged and implemented measures quickly and pragmatically. In the first Daily Scrum after all users were able to use the app normally again, we discussed the mistake and considered how to avoid such a screw-up in the future. Do you need a quality measure? Does anyone need additional know-how? Should I create a checklist? Whatever needed to be done, we made sure we discussed it. All the while keeping a team attitude and not pointing fingers while addressing problems.


A culture of allowing for error does not evolve overnight, and I can not realistically ask every member of the team to completely accept this attitude from Day 1 onwards. Our entire (global) education system has trained us too well in the concept of the culprit.

But still, the following process can help:
1. Take action
2. Consider damage when it’s there
3. See the consequences and learn from them

Thus, helping every startup not to be slowed down by mistakes.