The Pilot as Product Discovery

The National Science Foundation's I-Corps program places customer and industry discovery upstream of commercialization decisions for deep technologies. It asks teams to evaluate product-market fit and the wider business model outside the lab. Other federal deep-tech commercialization mechanisms, from Department of Energy demonstration programs to the Defense Innovation Unit's prototype contracts, similarly place real-world testing between technical development and scaled adoption.

For a deep-tech or infrastructure venture, that discovery process runs through pilots. A pilot subjects a general-purpose capability to commercial selection pressure. Some parts of the capability harden into product on contact with a real counterparty. Others fail to survive.

The venture that treats pilots as validation exercises for products already designed in the laboratory tends to miss the mechanism entirely. The product that emerges from a well-run pilot program is often not what the founders intended to build. The difference is the venture's most important output.

The Product Surface Is Larger Than the User Interface

For infrastructure ventures, the product surface extends well beyond the software or hardware interface. A capability must resolve into technical decisions about what it does functionally and how it integrates with adjacent systems.

It also involves institutional decisions about what information downstream actors receive and how audit and procurement classify the deployment. Commercial decisions about the unit of sale, the budget line, and the pricing model are equally critical. Each of these dimensions is underdetermined by the capability itself.

A technically complete project can be almost entirely product-incomplete when only the functional dimension has been worked out. The protocol may function, the algorithms may perform, and the hardware may hold specification. Yet no one may yet know whether the commercially relevant object is an appliance, a managed service, or a per-transaction fee.

An appliance requires an on-premises install and a hardware supply chain. A managed service requires operations personnel and continuous availability commitments. A per-transaction fee requires metering infrastructure and usage-based contracts. None of these choices can be settled reliably in the lab alone.

The pilot forces those abstractions to collapse into a concrete configuration. A materials-characterization instrument piloted with a semiconductor fabrication line can produce a different product than the same instrument piloted with a pharmaceutical research organization, even when the underlying measurement is identical.

The differences arise from which data formats are consumed downstream, which regulatory framework governs the operating environment, and which budget line pays for the service. None of those choices can be settled reliably in isolation from a deployment.

Surface inversion describes a pattern in which the pilot reveals that the customer values something adjacent to the original capability more than the capability itself. A venture built around a novel industrial sensor may discover that customers will pay for the calibration service around the sensor.

A venture built around a new battery chemistry may discover that more commercial value resides in the thermal management system than in the cell alone. The original capability persists as technical differentiator, but the object of sale has shifted.

Surface inversion is difficult to establish from prospect conversations alone. The relative value of the surrounding product surface may become clear only in deployment.

When surface inversion happens, the venture faces a strategic choice. Following the inversion means reorienting the product around what the customer actually pays for, which may require subordinating the original capability to a supporting role in a larger offering.

Resisting the inversion because the original story was more elegant can leave the venture with a technically impressive product and few buyers. The pilot's diagnostic value is greatest when the venture is willing to act on what it reveals.

One Pilot Cannot Distinguish Product from Idiosyncrasy

A single pilot, however successful, cannot reliably separate what belongs in the product from what belongs in the first customer's workflow. That separation requires structural variation across counterparties.

A useful sequence runs from discovery through falsification to portability. The first pilot reveals what an actual deployment requires. The second falsifies which of those requirements were inherent to the product and which were quirks of the first customer. The third tests whether the resulting product survives another organization without major reinvention.

Falsification is an easy step to skip. After a successful first pilot, the temptation is to scale on the assumption that what worked will keep working. The discipline of the second pilot is to select a counterparty structurally different from the first. This helps distinguish requirements inherent to the product from artifacts of the first deployment's particulars.

A second pilot with a customer too similar to the first can produce more confidence than information.

Recurrence across pilots is the sorting mechanism. After one customer requires a particular feature, the venture has a requirement. After three structurally different customers independently require the same feature, the venture may have a product primitive.

Features requested only by the first customer should be treated as candidates for configuration, an adapter layer, or a professional-services engagement until recurrence demonstrates otherwise. The venture that treats every request as core specification will accumulate features faster than it can integrate them, and the product will lose coherence as it grows.

The risk across multiple concurrent pilots is drift. Each pilot exerts pressure to bend the substrate toward one buyer's operational particulars. A venture that satisfies each pilot in isolation, without a deliberate view of what belongs in the core versus the periphery, ends the process with a substrate contorted into an unreconciled bundle of features.

This results in a collection of custom features rather than a coherent product line with a shared foundation. Divergence across pilots is useful when watched for convergence.

The counterparty organization's structural capacity to absorb the technology is part of product-market fit. Long security-review timelines, absent budget owners, and users without authority to change their own workflows count as product information.

They may indicate that a software sale needs to become an appliance, that a self-serve SDK needs to become a managed service, or that a direct sale needs to run through a systems integrator. Deep-tech ventures have an adoption architecture alongside their technical architecture, and pilots test both simultaneously.

Adoption architecture becomes clearest in deployment. The same capability delivered as a hosted API, an on-premises appliance, and an SDK integrated into a partner's product is commercially and operationally three different products from the perspective of the buyer's procurement and operations teams.

Pilots that stall consistently for institutional reasons rather than technical ones are informing the venture that its adoption architecture may be wrong for the buyer type it is pursuing. In such cases, reformulation may be more urgent than further capability development.

How Pilots Actually Get Realized

The default founder image of pilot acquisition is a linear enterprise sale: identify the customer, convince the customer, sign the pilot. For deep-tech ventures, that path is one option among several, and often not the most informative first rung.

Pilot access spans arrangements that reduce institutional risk, arrangements that align with the counterparty's existing structure, and arrangements that share the financial risk of the deployment.

Pilots that reduce the institutional risk of experimentation can get run where riskier pilots would not. A shadow deployment runs the new system alongside the existing one without controlling production decisions, exposing the technology to real data and real edge cases while leaving the counterparty's operations intact.

A historical or replay pilot uses bounded past events to ask what the system would have produced, generating weaker evidence than live operation but often enough to expose the initial product surface.

Testbeds and collaborative R&D arrangements can provide environments more realistic than internal simulation and less institutionally expensive than customer production. At the National Institute of Standards and Technology, cooperative research and development agreements can provide private organizations access to facilities, test systems, data, equipment, and expertise for collaborative R&D.

Pilots that align with the counterparty's existing organizational structure work when direct sales do not. A design-partner arrangement pairs the venture with an organization possessing enough domain expertise to generate real constraints, not merely enthusiasm for the technology.

An integrator- or channel-hosted pilot inserts the technology into an incumbent's existing customer engagement, and can reveal that the venture should not own the full application surface at all.

A consortium pilot, in which the deployment unit spans supplier, buyer, and integrator, can become necessary when the product surface itself resides between institutions. Interoperability technology, shared-data infrastructure, and standards-dependent systems can require consortium pilots because the value proposition of the underlying capability may materialize only when multiple counterparties adopt compatible implementations.

Pilots that share the financial risk of the deployment become possible when the counterparty is a public program designed for that purpose. The Defense Innovation Unit's Commercial Solutions Opening process awards prototype agreements and can provide a transition path into follow-on production procurement after a successful prototype.

Department of Energy demonstration programs use federal funding and, in several programs, cost-shared industry partnerships to move technologies toward demonstration, deployment, and market adoption.

The generalizable principle is durable: someone must finance the uncertainty between technical feasibility and commercial repeatability. Mechanisms that already contemplate a transition beyond demonstration can generate stronger commercial signals than pilots with no purchase pathway.

The distinction between an innovation team and a procurement organization can become a source of pilot failure. Innovation teams are often organized to test unfamiliar technology quickly, while procurement organizations are typically responsible for budget discipline, contracting, and vendor risk management.

A pilot that succeeds with an innovation team but has no path into the procurement organization has produced a technical validation without a commercial one. That gap can leave ventures accumulating impressive pilot logos without recurring revenue, and makes the pre-negotiated transition condition consequential.

The pilot itself requires engineering before it can produce product information. It must anchor to a defined decision or workflow rather than to an abstract evaluation of the technology, because a pilot without a specific decision to inform generates ambiguous signals that resist interpretation.

It must specify a deployment boundary, a baseline of current operations, and explicit hypotheses at technical, operational, and commercial levels. It must have a named institutional owner on the counterparty side and a pre-negotiated transition condition specifying what happens if the pilot succeeds.

The transition condition is often neglected. A venture can spend months proving something to an innovation team only to discover that production procurement belongs to a different unit that was never involved in the pilot.

The Diagnostic of Commercialization

A useful diagnostic of whether a deep-tech venture is commercializing rather than accumulating pilots is the marginal cost of deployment. The first pilot may require heroic effort. The fifth should require mostly configuration. The tenth should look like onboarding.

A declining deployment-cost curve is evidence that the venture is converging on a product rather than accumulating impressive logos through bespoke implementations.

Pilot purgatory has a recognizable shape. Ventures caught in it install every customer as a founder-led custom implementation, produce case studies rather than repeatable deployments, and never converge on a product primitive that other customers can adopt without similar bespoke effort.

Individual pilots may succeed on their own terms. The failure is in the venture's inability to extract product primitives from successful deployments, resulting in accumulation of case studies rather than repeatable customer acquisition.

For deep-tech and infrastructure ventures, the purpose of a pilot is to discover the boundary between technical capability and repeatable product, and to determine which parts of the capability survive contact with more than one counterparty.

What remains after that process is the product. It is often not what the founders originally intended to build. That difference is the venture's most important output.

Sources

• National Science Foundation. "NSF National Innovation Corps Teams (NSF National I-Corps Teams) Program." National Science Foundation, 2025.
• Defense Innovation Unit. "Solving Problems with Commercial Tech at Commercial Speed." U.S. Department of Defense, n.d..
• U.S. Department of Energy. "Office of Clean Energy Demonstrations." U.S. Department of Energy, n.d..
• National Institute of Standards and Technology. "Collaborate with PSCR." U.S. Department of Commerce, 2023.