Before looking for the solution, buy information

When a technical project stalls, the temptation is natural: to look for a solution straight away.

How long to fix the problem?

How much will it cost?

Which provider can do it?

Which technology should be used?

The trouble is that, at this stage, these questions sometimes come too early.

Because the symptom is known, but not necessarily its cause.

A prototype lacks reliability.

An industrialisation falls behind.

An architecture no longer holds under load.

A team can no longer move forward.

A product costs too much to manufacture.

In each of these cases, you can immediately try to fix what seems to be the problem.

Or start by buying something far less spectacular: information.

Uncertainty has a cost #

When the cause of a problem is poorly understood, someone has to carry that uncertainty.

On a time-and-materials basis, it’s mainly the client: the longer the investigation lasts, the higher the bill.

On a fixed price, it’s the provider who has to absorb the risk of discovering something they hadn’t anticipated. They price it in, underestimate it, or end up losing money.

In both cases, trying to contract too early for the resolution of a problem that is still poorly understood forces someone to gamble.

Yet there is a third option:

reduce the uncertainty first.

A diagnosis is not yet the solution #

A few hours or a few days spent observing, measuring, questioning the architecture, testing the assumptions and understanding the constraints may produce no additional feature.

From a distance, nothing has moved.

And yet the economic and technical nature of the project may have changed completely.

We now know what we are looking for.

We know which assumptions have been eliminated.

We know which unknowns still matter.

We can start to estimate a scope, a risk and a trajectory.

And sometimes, above all, we discover that the problem we were about to spend a lot of money on wasn’t the right one.

In R&D, an experiment doesn’t need to succeed to have value #

This is something we accept quite naturally in R&D.

An experiment that invalidates a hypothesis can be extremely useful.

It didn’t produce the solution.

It reduced the space of possible solutions.

In other words, it bought information.

This logic perhaps deserves to be applied far more widely to technical projects.

Before committing a lot of time, money or resources to a solution, it can be rational to commit a small part of those resources to understanding the problem.

Not every uncertainty is worth resolving #

The goal is obviously not to know everything before acting.

That would simply replace haste with paralysis.

The real question is rather:

What information could still change my decision?

If a piece of information changes neither the solution being considered, nor the risk accepted, nor the investment required, it is probably not worth seeking.

On the other hand, if it can tip the decision, acquiring it has value.

The first delivery can therefore be knowledge #

We tend to measure a project’s progress by what has been produced: code, prototype, electronics, mechanics, features.

But on a complex problem, the first useful thing to produce is sometimes simply a better understanding of the system.

Not to delay the decision.

On the contrary.

To be able, at last, to make one.