If the pilot works first time, maybe you haven’t tested anything. A few reflections…
July 2, 2026
We confuse «testing» with «confirming». And when a pilot is designed to succeed, it teaches us nothing about the future: it just gives us a staged photo of it. This is the difference between a proof of concept, a real pilot and a Living Lab methodology, and why confusing them costs us so much.
A few reflections, prompted by a post from Dr Julio Mayol on “pilots” in the health and clinical fields · linkedin.com/in/juliomayol
The staged photo of the future
Dr Mayol’s reflections are compelling and stress the need to define the innovation model clearly:
“There is a scene that repeats itself in every innovation committee. We present the results of a pilot and everything has gone well. Green indicators, a satisfied team, a happy board. Nobody asks the most uncomfortable question: under what conditions did it go well?
Because, if we read the fine print, we have almost always chosen the ground in our favour. We picked the hospital with the best digital culture. The department with the lightest caseload. The most motivated professional. The weeks without difficult on-call shifts. The patients without comorbidities. And with all of that stacked in our favour, the pilot goes well.
That is not a pilot. It is a staged photo of the future. And the problem comes later: we design pilots to succeed and then, when we scale them, we are surprised they fail. We shouldn’t be. A pilot that works first time, in ideal conditions, with the team that already worked and the service that already worked, has proven nothing. It has only confirmed that, when everything is in your favour, things go well.”
https://www.linkedin.com/posts/juliomayol_demo-pilotos-innovaciaejn-share-7478048306225414144-cJwr/
Here is a rule almost nobody wants to hear: if your pilots always go well, you probably aren’t innovating. You’re doing something else, public relations, managing the board’s expectations, or a success story for the annual report.
A pilot is not a proof of concept
Much of this confusion comes from a vocabulary problem. We use the word «pilot» for very different things, and mixing them up has consequences.
A proof of concept, a conceptual project, answers a very specific question: can this exist? Does the technology do what we say it does? Is it technically viable? To answer it, it makes perfect sense to work under controlled, favourable conditions. We want to isolate the technical variable from everything else. It does not tell us whether it will work in real life.
A pilot, by contrast, answers a radically different question: does this work in the real world? With real friction, with the people who actually have to use it, with the interruptions, the rush and the exceptions we hadn’t anticipated. A good pilot is not designed to succeed: it is designed to surface problems as early and as cheaply as possible.
Our habitual mistake is to run a proof of concept and label it a pilot. We choose the best conditions, get the result we were looking for and infer a confidence we haven’t earned.
«A proof of concept asks whether something can exist. A pilot asks whether it can survive the real world. Confusing them means building confidence on ground we have never actually walked on.»
Cheap failure is an investment; expensive failure is a disaster
The paradox is that we need pilots to fail. A failure at the pilot stage is valuable information that costs little: it tells us where the solution will break before we have invested the whole budget, our reputation and thousands of patients in it. The same failure, discovered at scale, is a disaster.
That is why a well-designed pilot actively seeks out uncomfortable conditions. It does not pick the best hospital: it picks the one that most resembles the average, or even one of the most strained. It does not select the easy patients: it puts in the complex ones, because they are the ones that will break our hypotheses. It does not ask for extra hours nobody will have in production: it tests the solution with the real time that will actually be available.
The role of Living Lab methodologies
This is where Living Lab methodologies change the rules of the game. A Living Lab is not a laboratory in the classic sense, a controlled environment where we isolate variables.
It is exactly the opposite: it is a real-life environment where innovation is exposed to complexity from day one. The logic is inverted: instead of engineering the conditions so the solution succeeds, we expose it to reality so it shows us where it fails.
- Co-design from the outset. Professionals, patients, carers and the community are not test subjects: they are co-authors. What gets tested is not a closed solution we bring in from outside, but one that is built with the people who have to use it.
- Real environment, not simulated. The Living Lab happens where life happens: at the health centre, at home, in the territory. No special conditions are requested, because the ordinary conditions are precisely the object of study.
- Continuous iteration and failure as data. There is no single verdict moment of «it works / it doesn’t». There are cycles of testing, learning and adjustment. Failure is not an accident to hide: it is the fuel of the process.
A Living Lab, therefore, does not replace the proof of concept or the pilot: it orders them. The proof of concept confirms that the technology is viable. The Living Lab validates, continuously and under real conditions, that the solution serves people. And only then does it make sense to talk about scaling.
Our commitment
In the Pirineus Project, at InnoHealth Academy, we have committed to precisely this logic: to build a Health Living Lab that does not chase the perfect “demo”, but honest validation. One that incorporates the voice of the communities of the Alt Pirineu, that tests solutions where they will really be used and that treats every difficulty not as a setback, but as what brings us closer to innovation that truly scales. Our territory, our people, our real conditions.
«The perfect “demo” is not the goal of innovation; it is its alibi. What we are looking for is not a pilot that goes well, but a solution that survives the real world.»
We invite you to reflect
- → Are your «pilots» real pilots, or proofs of concept disguised with conditions chosen in your favour?
- → When was the last time you celebrated what a pilot taught you by failing?
- → What uncomfortable conditions are you avoiding that will, sooner or later, show up at scale?
