A prospective customer says, “We would be interested in a pilot.” The founder hears progress. The customer may mean something much less specific: a demonstration, a free experiment, a technical review, or a project that has not yet found an internal owner.
The next job is to turn interest into an agreed test. A useful pilot connects a real task to observable results and a subsequent decision. It also protects both sides from an open-ended engagement with no clear limits.
This guide proposes an operating structure. It is not a contract, a safety authorization or a substitute for legal, security and technical review appropriate to the product.
Establish the problem before naming the pilot
Ask how the task is currently performed, who experiences the difficulty, and what happens if nothing changes. Examine actual workflow evidence when access is permitted. Do not use a product demonstration as a substitute for understanding the work.
NSF’s I-Corps program treats commercialization as an experiential learning process, rather than an exercise confined to technical development. 1 A pilot should continue that learning, not suspend it because a prospective customer sounded enthusiastic.
For a fictional document-processing product, the problem may not be extracting information. It may be resolving exceptions, checking evidence or obtaining approval. A pilot focused only on extraction accuracy could miss the reason the organization would—or would not—buy.
Identify the people behind the word “customer”
At minimum, understand who uses the result, who coordinates the pilot, who approves relevant access, and who can make a later purchasing decision. One person may fill several roles, but do not assume that the first enthusiastic contact represents all of them.
Ask the prospective owner what they need to learn and what constraints matter internally. A successful technical test may still fail to produce a purchase if nobody has agreed to evaluate the commercial next step.
That is not evidence that the customer was dishonest. It may reveal that the founder never established the decision process.
Write one decision the pilot should inform
A pilot should answer a bounded question, such as whether an identified workflow can be completed under agreed conditions with acceptable quality and effort. It should not promise to prove the entire market.
The end decision might be a purchase, a larger evaluation, a revised test or a stop. Make the possibilities explicit before starting. If the next step requires a separate procurement process, record that fact instead of describing pilot completion as automatic conversion.
For a hardware product, a first test might establish feasibility in a controlled environment before any live site deployment. The scope should reflect the consequences of failure, not a founder’s desire for a faster sales cycle.
Specify the work and its boundaries
Element | What the pilot brief should establish |
|---|---|
Task and users | The work to be tested and who will perform it |
Inputs and access | What data, equipment, systems and permissions are required |
Baseline | How the current task is measured or described |
Success evidence | Agreed observations, quality checks and limitations |
Human assistance | What the startup will do manually and how that effort is recorded |
Time and resources | Duration, customer responsibilities and startup effort limits |
Decision meeting | Who reviews the result and what can happen next |
Stop conditions | What pauses or ends the test before completion |
A brief can be short while answering these questions. The purpose is mutual understanding, not documentation volume.
Make the baseline credible
Describe the existing process before the intervention. If you intend to claim reduced time, define the start and end of the task, who performs it and whether review work is included. If you intend to claim improved quality, define how errors are found and classified.
For small samples, report observations as observations. A few successful runs do not establish performance under all customer conditions. Keep ordinary cases and difficult cases visible rather than selecting only the inputs the product handles well.
Also document the startup’s manual contribution. An assisted result can be a valuable learning milestone, but it should not be presented as evidence that the product independently delivers the same result.
Agree the economics without pretending there is one universal rule
Paid pilots can test a commercial commitment and help cover delivery work. A tightly bounded unpaid evaluation may also be reasonable when the learning value and costs are explicit. This guide does not prescribe one approach for every product.
What matters is clarity. State any fee, included effort, expenses, extension conditions and treatment of custom work. Do not conceal the true project cost inside an optimistic future sale.
An internal budget should include founder time, technical support, travel or installation where relevant, and the work required after a problem occurs. Set a limit beyond which the test must be renegotiated rather than quietly expanded.
Operate the pilot with visible checkpoints
At kickoff, confirm access, owners and the first observable task. During the test, record deviations from the plan. A missing permission, changed workflow or additional stakeholder can materially change what the result means.
Review problems promptly. Do not wait until the final presentation to explain that the customer did not supply a necessary input or that the product required extensive manual repair.
When scope changes, decide whether the original question can still be answered. Sometimes the responsible outcome is to pause or redesign the test. That may be more valuable than declaring a nominal completion under conditions neither party originally agreed to.
Close with an evidence review, not a celebration deck
Present the agreed question, what was actually tested, the result, limitations, startup assistance, customer effort and unresolved issues. Compare the evidence to the original criteria before introducing a new sales proposal.
Separate technical success from adoption, and adoption from purchasing approval. A customer may appreciate the result but lack a viable deployment path. Document the barrier so the next decision is informed.
Agree the next action and owner. If the pilot ends, arrange access removal, data handling and equipment or work-product handoff under the relevant agreements. Do not leave a trial indefinitely active because no one wants to send a closing message.
Learn across pilots without building separate companies
After several engagements, compare which work repeats. Are customers asking for the same capability under similar conditions, or are you delivering unrelated custom projects? Either business can be legitimate, but they imply different products and economics.
Preserve evidence that contradicts the preferred story. A failed pilot can reveal an unsuitable segment, a product limitation or a purchasing obstacle. The remedy depends on which one it is.
The useful transition is not from interest to a calendar event called “pilot.” It is from an ambiguous conversation to a bounded test that both sides know how to judge—and from that test to an honest decision about what should happen next.
Sources and research scope
[1] NSF I-Corps — U.S. National Science Foundation. Official program overview. Reviewed 2026-10-04. Experiential commercialization training; application eligibility and funding must be checked separately.
