Dear Readers, Brilliant Minds and Game-Changers,
Today I am in Basel for the QAI Ventures Quantum Global Summit.
This is a particularly important event for me because QAI Ventures is not simply an ecosystem I observe from outside. I have the honour and chance of working with QAI Ventures and, through that relationship, with companies in its startup ecosystem.
That gives me a particular perspective on one of the most important transitions in deep tech.
The transition from: “This technology is interesting.”
to: “Let's test it together.”
At first sight, this sounds like success.
And often it is.
A prospective customer is interested.
An industrial company proposes a proof of concept.
A research organisation sees an integration opportunity.
A strategic partner wants to experiment.
For an early-stage company, that is exciting.
But it is also where strategy becomes extremely important.
Because two pilots that look almost identical on a slide can produce completely different strategic outcomes.
One becomes a customer.
One becomes a case study.
One creates valuable IP.
One generates learning that changes the product.
One consumes six months of engineering and disappears.
One locks the startup into custom development.
One transfers so much knowledge to the customer that the startup weakens its own position.
And one gives away broad exclusivity in return for a relatively small project.
They all begin with the same sentence:
“Let's run a pilot.”
Which is why I believe: The pilot is not the prize.
The prize is what becomes possible afterwards.
Why pilots matter so much in quantum
Quantum is precisely the kind of technology where experimentation is necessary.
The OECD's 2026 work on business readiness highlights technical immaturity, uncertainty regarding use cases and business implications, costs, skills shortages and integration complexity as continuing barriers to adoption. [1]
A customer often cannot simply buy a quantum solution off the shelf and know its value in advance.
It needs evidence.
That means pilots will remain important.
But there is a huge difference between an experiment designed to create evidence and an experiment performed because experimentation sounds innovative.
Start with the decision, not the technology
Imagine an industrial company exploring a quantum optimisation technology.
What exactly is the proof of concept supposed to demonstrate?
That the quantum algorithm can run?
That it produces a better answer?
That the answer is obtained faster?
That the improvement beats the best classical baseline?
That integration with existing IT is feasible?
That the economic gain exceeds the cost?
That the system can operate under realistic constraints?
Each is a different question.
A pilot that attempts to prove everything may prove very little.
So I would begin with one sentence:
If this pilot succeeds, which decision should the customer be able to make with greater confidence?
Now we can design the experiment.
Define success before the project begins
One of the most dangerous conclusions after a proof of concept is: “The results are interesting.”
Interesting for whom? And interesting enough to do what?
Different participants may leave the project with entirely different interpretations.
Instead, establish the evidence threshold beforehand.
It might be:
- performance above a classical benchmark,
- a cost threshold,
- a reduction in execution time,
- specific accuracy,
- technical compatibility,
- manufacturing feasibility,
- or confirmation that a previously uncertain mechanism actually works.
The success criterion does not always need to be numerical.
But everyone should understand what outcome justifies the next decision.
Every pilot creates multiple asset flows
This is where intangible-asset management enters.
A collaboration contains several categories of assets.
Background assets
What each organisation possessed before the collaboration:
- Patents.
- Software.
- Know-how.
- Datasets.
- Algorithms.
- Methods.
- etc...
Contributed assets
What each party makes available specifically for the experiment:
- Customer data.
- Interfaces.
- Technology modules.
- Internal expertise.
- Etc...
Foreground results
What the collaboration produces:
- New inventions.
- Code.
- Models.
- Experimental results.
- Reports.
- etc...
Improvements
Changes made to existing assets.
Learning
And this last category is frequently overlooked.
Even if the pilot produces no patentable invention, one party may learn:
- which parameter matters,
- which architecture fails,
- what the customer genuinely values,
- what data is insufficient,
- what integration is difficult,
- or which use case deserves an entirely new product.
That knowledge can be immensely valuable.
The contractual and strategic question is: Who can use what afterwards?
“All results belong to the customer” may be simple, and disastrous
Imagine a startup solving a customer-specific problem.
During the project, it improves the core platform in a way useful across several industries.
The contract says: all project results belong to the customer.
- Does the customer now own the platform improvement?
- Can the startup use it with another customer?
- Can it incorporate it into its product?
Conversely, the customer may reasonably fear that proprietary industrial knowledge discovered during the project will become part of a solution offered to competitors.
Both concerns are legitimate.
This is why simplistic ownership clauses are dangerous.
The more strategic approach is to distinguish:
- core platform,
- customer-specific implementation,
- general improvements,
- customer data,
- results,
- background know-how,
- and confidential application knowledge.
Then decide what each party actually requires.
Not everything needs the same ownership model.
Exclusivity can be extraordinarily expensive
There is another word startups should treat carefully: exclusive.
A prospective customer may say: “We will invest time and data into this pilot. We want exclusivity.”
Understandable.
But exclusivity over what?
An application? A sector? A country?
A particular customer category? The entire technology?
For how long? In exchange for what minimum commitment?
What happens if the customer never commercialises?
For a startup, broad exclusivity can eliminate an entire future market before that market has even been properly understood.
Its economic cost may be enormous.
It simply does not appear as an expense in the accounts.
Exclusivity should therefore correspond to the value received in return.
The customer also contributes valuable intangibles
This conversation should not become one-sided.
Customers take risks too.
An industrial company participating in an early pilot may expose:
- internal processes,
- data,
- manufacturing knowledge,
- technical constraints,
- business priorities,
- customer problems,
- and strategic information.
That knowledge may improve the startup's technology considerably.
The relationship therefore requires an architecture protecting both sides.
The startup needs freedom to improve its general platform.
The customer needs confidence that proprietary knowledge will not be converted into an advantage for its competitors.
This is where well-designed intangible-asset governance can actually accelerate trust.
A good pilot should increase optionality
There is one strategic test I particularly like:
After the pilot, do we have more good choices than before?
A successful pilot may create the option to:
- sell,
- license,
- co-develop,
- enter a new market,
- raise capital,
- create new IP,
- form a strategic partnership,
- or productise a repeatable solution.
That is optionality.
A badly designed pilot can do the opposite.
It can create:
- dependency,
- unscalable customisation,
- ambiguous ownership,
- unfunded obligations,
- or constraints on future markets.
Revenue is important.
But strategic optionality is also value.
Design the exit before entering
There is another question that should be discussed before the experiment starts: What happens if it works?
Will there be:
- a paid deployment?
- Procurement?
- A second phase?
- A licence?
- Joint development?
- Investment?
No promise is necessarily required.
But there should be a credible conversion path.
Otherwise a startup can complete a technically successful pilot only to discover that nobody at the customer organisation owns the budget—or authority—to proceed.
Technical success then becomes organisational failure.
And design failure too
What happens if the pilot does not succeed?
What data must be deleted?
What can each party retain?
Can anonymised or aggregated learning be reused?
Can improvements be retained?
Will results be published?
Can either party mention the collaboration?
A failed experiment does not necessarily create zero value.
If it removes uncertainty, it creates knowledge.
But only if the organisation preserves and uses that knowledge.
The one-page collaboration brief
Before an important deep-tech pilot, I would want six questions answered on one page:
1. What decision is the experiment supposed to unlock?
2. What evidence will count as success?
3. What intangible assets does each party bring?
4. What new assets or learning may emerge?
5. Who can use what after the project?
6. What strategic options exist if it succeeds—and if it fails?
If those answers are clear, drafting the technical statement of work becomes much easier.
The deeper lesson
A pilot is an experiment. A business relationship is not.
It needs:
- objectives,
- boundaries,
- rights,
- responsibilities,
- and a route to the next decision.
As fractional CIAO, that is exactly the type of question I believe deserves to be considered alongside the technology itself.
Because an extraordinary technology can still produce a strategically poor deal.
And an intelligent collaboration can create value even before significant revenue appears.
So today, as conversations happen across the QAI Ventures Quantum Global Summit, one question is particularly useful:
If this collaboration works, what strategic position becomes possible that did not exist before?
That is the prize. Not the pilot.
