A working PoC doesn't prove you have a product

The demo works.

The target phenomenon is observable. The algorithm produces the expected result. The prototype behaves correctly.

Good news: the technical hypothesis may just have been validated.

Bad news: that says almost nothing about the product yet.

A PoC answers a question #

The purpose of a proof of concept is precisely to reduce an uncertainty.

• “Can we measure this phenomenon?”
• “Does this algorithm let us extract this information?”
• “Can these two technologies work together?”

The prototype needed to answer that question can be ugly, fragile, expensive, or dependent on a perfectly controlled environment.

That isn’t necessarily a flaw. If its purpose is to test a hypothesis quickly, demanding that it be manufacturable straight away can even slow the experiment down.

The problem appears when you confuse proof of feasibility with technological maturity.

Working is only a step #

The TRL scale (Technology Readiness Levels), used notably by NASA, illustrates this progression well. An experimental proof of concept sits at the first levels of technological maturity.

Then come validation in the lab, validation in a representative environment, the demonstration of a prototype in its operational environment, and finally the complete system.

Between “it works on my bench” and “someone can actually use it” lie a great many questions.

• Is the result reproducible?
• What happens when the environment changes?
• Will the chosen components still exist in two years?
• Does the system tolerate manufacturing variation?
• Can you test it? Maintain it? Produce it at a cost that fits its market?

Let’s not ask the PoC to prove what it doesn’t test #

A good PoC isn’t a miniature product. It’s an experiment built around a clearly identified uncertainty.

Before building the prototype, one simple question is worth writing down: “what should this experiment let us decide?”

If the result changes no decision, the PoC is probably testing the wrong thing.

And when it works, the right reaction isn’t necessarily “we have our product”, but rather: “good. Which uncertainty just disappeared, and what’s the next one?”

That’s how a prototype gradually becomes a technology. Then, eventually, a product.

This is the path — from an experimental hypothesis to a technology you can protect and industrialise — that the assets developed at Y’s Lab follow.

Perspective 03 — next Monday: Every component works. Yet the system fails.

Source #

• NASA — Technology Readiness Levels (TRL), from proof of concept to a system demonstrated in an operational environment.