Fail fast but not first

The "fail fast" principle, sometimes expressed as "fail often" or "fail cheap," has become a common idea in business and product development.

The reasoning is simple: test an idea as early as possible, discover whether it works, and stop investing before failure becomes expensive.

And there is a lot of value in that.

The problem starts when "fail fast" becomes an excuse to start without thinking.

The purpose of failing fast

Failing fast is not really about failure.

It is about limiting the cost of being wrong.

If a product idea is unlikely to work, discovering that after spending six months and hundreds of thousands of euros is obviously worse than discovering it after a week.

The earlier we can identify a fundamental problem, the less we have to lose.

This is why experimentation, prototypes, customer interviews, small releases, and other forms of early validation are so valuable.

But there is an important question that often gets overlooked:

What should we test first?

Starting is not the same as learning

A common interpretation of "fail fast" is:

"We don't know if this will work, so let's just start and see what happens."

It sounds reasonable.

After all, we cannot predict everything. At some point, we have to build something and put it in front of real people.

But starting immediately does not necessarily mean learning quickly.

If we begin without understanding the problem, the market, the constraints, or the assumptions behind the idea, we may end up experimenting without knowing what the results actually mean.

We can spend months changing direction without ever establishing whether the original idea was wrong, the implementation was wrong, or the strategy was never properly defined in the first place.

At that point, "fail fast" can have the opposite effect.

Instead of reducing waste, it can create it.

Analysis is not the opposite of experimentation

This does not mean that everything should be planned in advance.

It is impossible to predict the future with complete accuracy, especially when people, markets, and technology are involved.

The purpose of analysis is not to eliminate uncertainty.

It is to understand which uncertainties matter.

Before building something, we should ask:

• What problem are we actually trying to solve?
• Who has this problem?
• How are they solving it today?
• What assumptions are we making?
• Which assumption, if proven wrong, would invalidate the whole idea?
• What is the cheapest way to test it?

These questions do not replace experimentation.

They make experimentation more useful.

A good analysis gives us something against which we can compare reality.

Without it, almost any outcome can be interpreted as a lesson, and it becomes difficult to know whether we are actually moving forward.

Software is a good example

Software development makes this distinction particularly important.

Software is relatively easy to change compared with physical products. This makes it excellent for experimentation and iteration.

But that flexibility can also create the illusion that planning is unnecessary.

A team can start building immediately, change direction later, and tell itself that the changes are simply part of the process.

Imagine a company wants to build a new marketplace.

Following a simplistic "fail fast" mindset, the team might immediately spend three months developing the platform.

They launch.

Nobody uses it.

The team has technically failed.

And perhaps they can even celebrate that failure as a successful experiment.

But what did they actually learn?

More importantly, did they need to build the platform to learn it?

The team could have first spoken with potential customers, studied existing alternatives, tested the value proposition with a simple landing page, or even operated the service manually.

If those experiments had shown that customers did not have the problem in the first place, three months of software development could have been avoided.

The software was not the experiment.

It was the expensive implementation of an assumption that had not yet been properly tested.

Build when building becomes the experiment

This does not mean that software should only be written once everything is known.

Quite the opposite.

There are many questions that can only be answered by building something and putting it into the hands of real users.

The important distinction is what we already know and what we are trying to learn.

A prototype might be built to test usability.

A small feature might be released to test behaviour.

A minimal product might be launched to test whether people actually return.

These are meaningful experiments because we have identified an uncertainty and chosen an appropriate way to investigate it.

The goal is not to avoid building.

The goal is to avoid building something merely because we have not yet thought of a better way to learn.

Fail fast, but not first

This is where the principle of “fail fast” becomes much more useful.

First, understand the problem.

Then identify the assumptions.

Then determine which assumptions are most dangerous.

Then find the cheapest meaningful way to test them.

And when experimentation is necessary, experiment quickly.

Sometimes the right experiment is a conversation.

Sometimes it is a spreadsheet.

Sometimes it is a prototype.

Sometimes it is a manually operated service.

And sometimes it is a full piece of software.

The point is not to choose the smallest possible implementation.

It is to choose the smallest meaningful experiment.

That distinction matters.

Learn fast

Ultimately, I don't think the goal should be to fail fast.

The goal should be to learn fast.

Failure is simply one possible result of learning.

If an idea is wrong, we want to discover it early.

If an assumption is wrong, we want to discover it before building around it.

If an implementation is wrong, we want to discover it before scaling it.

And if the original idea is right, we should be able to move forward with greater confidence rather than constantly changing direction without knowing why.

So, yes: fail fast.

But don't confuse speed with immediacy.

Think before you build. Experiment before you commit. And when you finally need to fail, make sure you have failed cheaply enough to learn from it.

Because if you have no idea what you are trying to learn, you cannot really measure how fast you failed.