The Customer Clock: Welcome to Pilot Purgatory
Imagine a deep-tech startup that has done almost everything founders are told to do.
It has built the technology. A major corporate customer has tested it. The pilot worked. The engineering team demonstrated measurable performance improvements. The customer’s innovation team is enthusiastic, the internal champion wants to continue, and the final presentation ends with exactly the words every founder hopes to hear: “This is really promising.”
Six months later, there is still no purchase order.
The startup runs another pilot with another company. That one works too. Then another. Its website fills with partner logos. Its investor deck gains case studies. Its pipeline grows. Revenue does not.
Welcome to pilot purgatory.
This is where the Customer Clock becomes one of the most misunderstood clocks in deep-tech commercialization. A successful pilot can prove that a technology works for a customer. It does not necessarily prove that the customer’s organization is ready to buy, integrate, budget for, govern, and scale it.
The Customer Clock describes the pace at which a market moves from curiosity about a technology to repeatable willingness and organizational ability to adopt it. In deep tech, that clock can run very differently from the Technology Clock.
A Pilot Is Not a Customer
The confusion begins because pilots feel commercial.
There is a real company on the other side. Real people are testing the product. There may be a contract, a pilot fee, access to operational data, and regular meetings with senior stakeholders. For an early-stage company, this can feel like unmistakable evidence that the market has arrived.
But a pilot and a commercial deployment answer different questions.
A pilot asks: Can this technology create value in our environment?
A commercial deployment asks something much harder: Is the value important enough, proven enough, safe enough, budgeted enough, and operationally compatible enough for the organization to change how it works?
That distinction is increasingly visible across emerging technologies. In June 2026, McKinsey’s research on corporate–scale-up partnerships found that many collaborations remain limited to low-risk pilots or proofs of concept and lack clear business ownership, dedicated budgets, strategic buy-in, or a defined path to scaled deployment [1]. The World Economic Forum reached a similar conclusion after surveying more than 200 early-stage ventures: startups need to design a route from pilot to an operational business solution rather than treating the pilot itself as the destination [2].
The customer is not truly adopting the technology when the innovation team approves a demonstration. Adoption happens when the operating organization is willing to depend on it.
The Three Customers Hidden Inside One Customer
This is especially difficult in deep tech because “the customer” is rarely one person.
The person experiencing the problem may be an engineer, plant manager, clinician, sustainability lead, logistics operator, or analyst. They understand the pain and may immediately see the value of the technology.
But they may not own the budget.
The economic buyer may sit somewhere else entirely. Their question is not simply whether the technology performs better. They want to know what it saves, what it earns, what risk it removes, how quickly the investment pays back, and what happens if the supplier disappears.
Then there is a third customer: the institution itself.
Procurement wants contractual certainty. Cybersecurity wants to understand attack surfaces. Legal wants liability defined. Compliance wants evidence. Operations wants reliability. IT wants integration. Finance wants a budget category. Senior management wants strategic relevance. In regulated industries, an external authority may effectively become another participant in the purchase.
A founder can therefore have an enthusiastic user and still have no customer.
This is why the Customer Clock is often slower than expected. The technology does not need to convince one person. It needs to survive an organization.
Proof of Concept Is Not Proof of Purchase
Deep-tech teams are trained to reduce technical uncertainty. That instinct naturally carries into customer engagement: demonstrate the capability, collect performance data, and prove that the system works.
But the experiment founders need to run with customers is broader.
A good pilot should not only test the technology. It should test the buying pathway.
Who owns the problem after the pilot ends? Which budget would fund deployment? What procurement threshold will be triggered? What security, insurance, certification, data, or integration requirements appear at scale? Who signs the commercial contract? What evidence does that person require? If the pilot succeeds, what specifically happens next?
If those questions have no answers at the beginning of the pilot, technical success can produce commercial ambiguity.
This is one reason successful corporate–startup collaboration increasingly emphasizes designing for scale from the outset. McKinsey’s 2026 work argues that the strongest partnerships align around a real use case, establish ownership and incentives, and create a path from technical validation toward embedding and commercialization [1]. The European Innovation Council similarly identifies strategic alignment, mutual commitment and value creation, skills, and structured experimentation as core ingredients of effective corporate–startup collaboration [3].
The objective is not merely to prove that the product works.
It is to prove that the organization can buy it.
The Most Dangerous Metric in Deep Tech: Number of Pilots
Founders understandably celebrate pilot activity. Investors ask about pipeline, customers under evaluation, letters of intent, and proof-of-concept programs. These signals matter—particularly when a technology is early.
But pilot count can become a dangerous vanity metric.
Ten pilots may indicate extraordinary demand. Or they may indicate that the company has discovered a repeatable way to generate experiments without discovering a repeatable way to generate customers.
The difference is conversion.
A useful Customer Clock should therefore track movement through adoption rather than activity around adoption: from problem recognition to champion, from champion to funded use case, from funded use case to procurement, from procurement to deployment, and from deployment to expansion or repeat purchase.
The key question is not “How many pilots are we running?”
It is “What percentage of successful pilots become something larger?”
That question can be uncomfortable. It is also commercially clarifying.
Design the Pilot Backward From Deployment
One way out of pilot purgatory is surprisingly simple: design the pilot backward.
Instead of beginning with “What can we demonstrate?”, begin with “What would have to be true for this customer to deploy?”
Suppose an industrial customer says it needs 99.9% reliability, integration with an existing control system, a defined maintenance process, cybersecurity approval, and a return on investment within twenty-four months.
That is not bureaucracy to be discovered after the pilot. It is the specification for the pilot.
The test should be designed to generate the evidence required for the deployment decision. The right stakeholders should be involved before testing begins. Commercial success criteria should sit alongside technical ones. The post-pilot decision process should be understood before the first piece of equipment is installed.
This does not guarantee a sale. Corporate priorities change. Budgets disappear. Champions leave. Strategy shifts.
But it converts the pilot from an open-ended innovation exercise into a decision instrument.
And that changes the clock.
Sometimes the Customer Clock Runs Faster Somewhere Else
There is another implication that matters particularly for companies commercializing deep technology internationally: customer readiness is geographic.
A technology can be early in one market and urgently needed in another.
Different countries have different procurement cultures, regulatory environments, industrial structures, government incentives, infrastructure constraints, and tolerance for emerging suppliers. A solution struggling to move beyond pilots in one geography may encounter customers elsewhere whose economics or strategic priorities make adoption considerably easier.
This is why globalization should not always be treated as something that happens after product-market fit.
For deep-tech companies, geography can be part of finding product-market fit.
A startup may validate with a sophisticated reference customer in Singapore, manufacture elsewhere in Asia, sell into a market with a stronger immediate demand signal, and use that commercial evidence to return to more conservative customers later.
The question is not simply: Where is the largest market?
It is: Where is the Customer Clock moving fastest?
The Customer Clock Must Meet the Other Three
The Customer Clock also exposes why none of the Four Clocks can be managed independently.
A customer may be ready before the technology is. That creates pressure to deploy an immature product and can push the Technology Clock beyond what reliability allows.
The technology and customer may both be ready while the company lacks the capital to manufacture, certify, or support deployment. The Capital Clock then becomes the constraint.
Or all three may align while regulation, infrastructure, standards, or supply chains remain immature. The Ecosystem Clock stops the transaction.
Conversely, the right customer can accelerate every other clock.
A credible cornerstone customer can provide operational validation, recurring demand, market credibility, data, manufacturing confidence, and a signal that helps unlock financing. McKinsey’s analysis of European scale-ups found that a sample of companies reporting corporate partnerships raised roughly five times as much funding as peers without reported partnerships, illustrating how commercial validation and capital formation can reinforce one another [1].
The best customers do more than buy the product.
They help make the company investable, scalable, and credible.
The Goal Is Not to Escape Pilots. It Is to Make Them Matter.
Pilots are not the problem.
For genuinely new technologies, they are often essential. Customers need evidence. Founders need operating data. Engineering teams need exposure to environments the laboratory cannot reproduce. Regulators and insurers may need proof. Investors need validation.
The problem begins when the pilot becomes a comfortable substitute for adoption.
A deep-tech company can spend years being interesting to customers without ever becoming important to them.
The Customer Clock forces a harder definition of progress. Interest is not adoption. A meeting is not demand. A letter of intent is not revenue. A successful pilot is not a scalable customer relationship.
Commercial progress occurs when each customer interaction removes uncertainty about the path to repeatable deployment.
The Technology Clock asks whether the product can become dependable.
The Customer Clock asks whether someone is prepared to depend on it.
Those sound similar. They are not.
And the gap between them is where some of the most impressive technologies in the world can spend years waiting.
References
[1] McKinsey & Company, “How corporate–scale-up partnering can boost Europe’s tech competitiveness,” June 10, 2026. Source
[2] World Economic Forum, “How to scale a business – lessons from 200 start-ups,” April 22, 2026. Source
[3] European Innovation Council, “European Innovation Council publishes flagship report on corporate-startup collaboration,” July 10, 2025. Source
