Your pilot worked. So why did nobody buy?

The pilot worked. The technology did what you said it would do, perhaps even a little better. The engineers on the other side were enthusiastic. Someone used the words “really promising” in the final meeting. You sent the results around, agreed to speak again after the summer / budget round / internal review / insert-other-perfectly-reasonable-corporate-event-here and then... not much. A few emails. A meeting that moved twice. Your champion still likes you, by the way. They genuinely do. There is just no purchase order. Welcome to one of the stranger features of selling deeptech: you can win the pilot and still lose the deal.

There is a very good old TechCrunch article about this by Champ Suthipongchai, co-founder of deeptech investor Creative Ventures. He calls it “pilot purgatory”, which is about right. His argument is that deeptech founders often think too much about whether the pilot can succeed technically and too little about what exactly it has to prove for the customer to move to a commercial rollout. His most useful suggestion is almost painfully simple: agree the conversion metric before you begin. What has to be true at the end of this thing for the customer to buy? Not “the technology performs well”. Which performance, against what baseline, producing what result, for whom? And crucially, do the people who eventually have to approve the contract agree that this is the definition of success?

That last question is where this gets interesting, because a pilot is rarely one decision. The engineer may need to believe the technology works. The person running the factory, lab or product line needs to believe it can actually be used. Someone else owns the budget. Procurement needs to be able to buy from you. Legal, quality, IT or security may have their own reasons to object. And somewhere in the organisation there is usually a senior person whose enthusiasm can turn three months of process into three phone calls (or whose indifference can achieve the reverse). An excellent piece from Cowboy Ventures on how technical founders learn enterprise sales makes this point using the early experiences of companies including HashiCorp, Kong, Lightstep and Algorithmia. The technical user might be your champion, but they describe a much broader buying group around that person: the economic buyer, procurement, legal, security and the technical evaluator. Algorithmia apparently learned this the hard way on one of its first enterprise deals, underestimating both how long the contract would take and how many people would need to be involved.

So the first thing I would teach anyone running deeptech pilots is this: stop asking whether “the customer” is convinced. There is no customer. There are people inside a customer, and they are judging different things. Your job before the pilot begins is to work out who needs to believe what. That gives you a much better way of designing the pilot. The technical team may want to see accuracy, throughput, lifetime, yield or energy consumption. Operations may care about installation time, downtime and how often somebody has to intervene. The economic buyer may care about euros saved per production line, extra capacity or a problem that disappears altogether. Procurement cares whether you are a supplier it can actually contract with. A technically successful pilot that produces no evidence for the other people in that chain can therefore be completely successful and completely useless at the same time.

There is another distinction that is worth making because the language around pilots has become rather sloppy. A design partnership, a proof of concept, a pilot and a first commercial deployment are not the same thing, even though we happily use the terms interchangeably. Mark LaRosa at Amplify Partners wrote probably the most useful recent guide I found on this, drawing on more than twenty years in technical sales and engineering and the experiences of founders including Barry McCardel of Hex and Richie Artoul of WarpStream. His distinction is helpful: early engagements are often primarily there to learn. Does the customer really have the problem? Does your product solve it in their environment? Which bits matter? What have you misunderstood? He describes how WarpStream's early customer conversations helped them discover that a very specific combination of architectural choices mattered to customers. The point was not simply getting a logo. It was learning what the product actually needed to become.

This also means the fashionable advice that you should always charge for pilots is too easy. LaRosa actually argues the opposite for very early design partnerships: if your main objective is learning, introducing procurement, vendor review and budget approval can slow down exactly the feedback loop you are trying to create. Barry McCardel's argument, quoted in the piece, is essentially that the revenue from the first few design partners is almost irrelevant compared with finding out whether you are solving the right problem. There are exceptions, particularly where the pilot itself has substantial cost, where demand is high enough to filter for seriousness, or when the engagement has moved from learning into delivering a real business result.

And then there is BMW, which is useful precisely because it takes the other side of this argument. Gregor Gimmy, the entrepreneur and former IDEO consultant who created the BMW Startup Garage and coined the term venture client, designed the program around a rather different principle: if BMW is testing startup technology against a real business problem, BMW should become an actual customer. In a 2017 interview he explains that the startup gets paid, receives a BMW supplier number and gets a purchase order just like another supplier. The corporate is not mentoring the startup or politely helping it validate a prototype. It is buying something. BMW still runs the model that way today: startups selected for a project are taken through purchasing before the proof of concept, receive a supplier number and a first PO, and are helped through the organisation towards a longer-term supplier relationship. More than 280 startups have now run pilots through the program; BMW says more than half of its alumni secured paid follow-up projects and 38 became established BMW suppliers.

Both approaches can be right. The interesting question is what are you trying to learn or prove? If you are TRL 4 and still figuring out whether your technology solves the customer's problem in a useful way, a tightly managed design partnership may be enormously valuable even without revenue. If you already know the problem, have something the customer wants to deploy and are now proving the economic and operational case, running another completely free “experiment” can actually hide the most important risk. You have tested whether they like the technology but not whether somebody inside the organisation is willing and able to spend money on it. The €0 to €50,000 step can look trivial from the startup side. Inside a large company it may involve an entirely different budget, process and group of people.

Which brings us to perhaps the most important lesson: the path out of the pilot should be part of the pilot. In the Amplify guide, there is a painful example from Hex. They had a potential design partner and eventually discovered that moving from the agreed test environment into production would itself be a multi-year project. They walked away. WarpStream experienced another version of the problem when a pilot stretched to nine months because every month produced another previously undiscussed criterion somebody wanted tested. Richie Artoul's conclusion is a good one: sometimes you need to put rails around the engagement, or you slowly turn into a professional-services company.

This is why I would want six questions answered before putting serious founder or engineering time into a pilot. What business problem are we solving? What does it cost the customer today? What exactly will constitute success? Who owns that problem and who owns the money? What still has to happen inside the company before it can buy? And if we meet the agreed criteria, what decision will be made, by whom and when? You will almost never get perfect answers. That is not the point. The answers expose the holes. “We don't know which budget yet” is useful information. “Procurement has not been involved” is useful information. “The business unit loves it but global IT has to approve every deployment” is extremely useful information. You would much rather discover those things in week zero than week twenty-four.

And do not confuse movement with commitment. A demo is movement. Another enthusiastic meeting is movement. Ten engineers joining a Slack channel can still be movement. A customer giving you access to production data is commitment. Introducing you to the budget owner is commitment. Allocating internal engineering resources is commitment. Starting security review is commitment. Agreeing commercial terms is commitment. Issuing a purchase order is rather obviously commitment. The newer pilot-to-production literature is increasingly explicit about this distinction: founders should manage pilots backwards from the buying decision, rather than assuming a successful technical evaluation creates its own momentum.

That is ultimately why so many perfectly respectable deeptech pilots disappear. The technology did not necessarily fail. The startup simply tested one risk while leaving five others untouched. And then everyone discovered, rather late, that the interesting prototype also had to survive budgets, procurement, implementation, internal politics, timing and the wonderfully human question of whether somebody cared enough to spend their credibility getting it through.

Deeptech companies are very good at building evidence that their technology works. They need to become equally deliberate about building evidence that somebody can, will and knows how to buy it.

If you have three “successful” pilots sitting in your CRM without three purchase orders behind them, I would look there before starting a fourth.

We wrote more about the wider European version of this problem in our article on the deeptech scaling gap.

And if you have a pilot that worked but somehow went nowhere, tell us what happened. Those are precisely the deals worth taking apart.