Optimising too early can kill invention

“It’ll never make it to production.”

Too expensive. Too slow. Too complex. The component isn’t suitable. The algorithm needs too many resources. The architecture will never scale.

The awkward part is that all these objections can be perfectly correct.

They’re just sometimes raised far too early.

In R&D, an idea is sometimes abandoned not because it doesn’t work, but because it’s already being asked to meet the constraints of a product that doesn’t exist yet.

Not every question belongs to the same moment #

An experiment can sometimes have a single goal: finding out whether a phenomenon exists.

In that case, it doesn’t matter that the first rig is bulky, that the sensor costs ten times the price acceptable for the final product, or that the computation takes three seconds when it will one day have to run in real time.

What you’re trying to find out at that instant is far simpler: does it work?

If the answer is no, you’ve learned something.

If the answer is yes, other questions follow naturally.

Can you get the same result with a cheaper sensor? Cut the computation time? Miniaturise the rig? Lower its power draw? Make it reproducible?

These questions matter. Some will even end up deciding the product’s viability.

But they don’t necessarily need to be solved during the first experiment.

The prototype is not the product #

Take an algorithm that, for the first trials, needs a powerful computer, while the final product will have to run on an embedded system.

You can look at the resource usage and immediately conclude that the approach isn’t viable.

Or you can start by checking that it actually produces the information you’re after.

If it brings nothing, the matter is settled.

If it works particularly well, then it becomes worth looking for how to keep that result with fewer resources.

Maybe you’ll have to change the algorithm. Maybe move some of the processing. Maybe use a different data representation, or rethink the architecture entirely.

That’s precisely the work that comes afterwards.

The initial prototype didn’t need to hold all those answers. It had to let you find out whether the lead was worth continuing to question.

It’s a distinction that looks obvious on paper and is far less so in a real project.

Our best practices can trip us up #

Industrial constraints aren’t the only thing that can close a lead too early.

Our engineering habits can do exactly the same.

We naturally want clean code, a robust architecture, reproducible measurements, security, maintainability. And when the product falls under regulatory requirements, we know those will have to be accounted for too.

All of that is perfectly legitimate.

The problem appears when the cost of testing an idea becomes almost as high as the cost of starting to turn it into a product.

You then hesitate to try something slightly odd because you’d first have to integrate it cleanly into what already exists.

You set aside a component because it’s too expensive, when it would have let you check a hypothesis in two hours.

You give up on an algorithm because it’s far too slow in its first version.

Little by little, you mostly end up experimenting with what you already think will work.

And for R&D, that’s rather a shame.

A prototype can be allowed to be bad #

Bad in the sense you’d mean for a product.

It can have wires everywhere. Use an outrageously expensive component. Require manual handling. Take several seconds to compute something. Be unable to run more than twenty minutes without a restart.

None of that matters if none of these points is the question the experiment is trying to answer.

What you do need is to know why you’re accepting these flaws.

And to keep them in mind.

Because once the principle is validated, they become problems to solve again.

That’s where the order of the questions becomes important.

First: is it possible?

Then: is it interesting enough to continue?

And if so: how do you turn it into something that actually works within the product’s constraints?

Mixing these steps sometimes amounts to industrialising a hypothesis.

Knowing what you want to keep #

This is also the moment when optimisation becomes far more interesting.

You’re no longer vaguely trying to “do better”.

You know what works and what you want to preserve.

The sensor costs too much? Let’s try another and check the information stays usable.

The computation takes three seconds? Let’s cut it without losing what made the result valuable.

The rig is too complex? Let’s simplify it and watch for the point where its performance really starts to degrade.

Each constraint you reintroduce then becomes a new experiment.

You no longer ask the idea to prove immediately that it can become a product.

You gradually look for how far you can constrain it without losing what made it interesting in the first place.

And that’s often where the real engineering work begins.

Then, of course, you’ll have to come back to the real world. Because the opposite excess exists too: by experimenting endlessly without ever reintroducing the product’s constraints, you end up building very fine demonstrators — with no idea what to do with them.

---

Perspective 06 — next Monday: Keep every option open, and you eventually stop moving forward.