A pilot should resolve a specific uncertainty about usefulness, adoption or delivery. Agree its scope, evidence, responsibilities and end date before starting. Decide what would justify continuing, changing or stopping so that a pleasant trial does not drift into an indefinite implementation.
Write the decision before the trial plan
Name what you do not yet know. Perhaps staff can complete a handover without assistance, managers will use a report in their weekly review or a service can be delivered within available capacity. Pick a primary question. Trying to prove demand, usability, financial viability and full rollout readiness in one small pilot usually creates ambiguous evidence.
State the next decision in plain language. “Decide whether to test a second shift” is more precise than “prove the concept”. List what the pilot will not establish, including conditions excluded from the trial. A narrow question can still be valuable when everyone understands which later questions remain open.
Agree the operating boundary with the participant
Document participants, workflow, duration and the work each side will perform. Specify support availability, responsibility for exceptions and how the trial can be stopped. If payment is involved, agree the commercial terms clearly. If data is involved, decide what is necessary, who can access it and what happens to it after the trial.
Choose a context where a failure can be managed. A pilot should not quietly introduce unreviewed safety, security or legal dependencies into ordinary operations. Use dummy or limited data where that answers the question. Obtain appropriate specialist input for consequential requirements, and preserve a workable fallback that participants understand.
Collect enough context to interpret the result
Record how the process works before the intervention. A recent period, sample of tasks or simple observation can provide context, but note differences in workload and staffing. A small before-and-after comparison rarely isolates every influence. Avoid presenting it as a precise causal estimate when conditions have changed.
Choose a small set of observations tied to the question. For a handover trial, that may include missing information, requests for clarification and support required. Capture exceptions as well as routine successes. A founder personally fixing each problem can make a pilot appear smooth while concealing the work an ordinary rollout would require.
Agree who records each observation and when. If people reconstruct events only at the final meeting, memorable incidents may crowd out ordinary tasks. A brief contemporaneous record also makes missing data easier to identify.
Close with a bounded next move
Schedule the review before the pilot starts and invite the people responsible for the decision. Compare observations with the agreed continuation and stopping conditions. Distinguish the product's behaviour from the customer's willingness to adopt it, and distinguish both from your ability to deliver support at a larger scale.
Possible outcomes include stopping, refining the approach, repeating the test under ordinary staffing or expanding one step. Explain why the evidence supports that move and what it cannot support. If the trial is extended, create a new question, boundary and end date. Otherwise an extension can become a way to avoid deciding that the original test did not answer the question.
Fictional example: one warehouse shift, one question
A fictional scenario to explain the method, not a customer result or a market benchmark.
A fictional warehouse tests whether a structured handover can make unfinished work clear to the next shift. The pilot covers one evening shift for two weeks. Both sides review earlier handover notes, agree what counts as missing information and nominate a supervisor to handle exceptions. Existing procedures remain available if the trial fails.
During the test, the team records clarification requests, unusual workload and every intervention by the supplier. At review, it finds enough useful observations to discuss a second test, but notices that the supplier rewrote several summaries personally. It therefore chooses to test ordinary staff completing the summaries before considering wider use. The invented case makes no claim of reduced error or causal improvement. It demonstrates why support effort can alter the next decision even when participants like a trial.
TAKE THIS INTO YOUR NEXT CONVERSATION
A practical next-step checklist.
- State one uncertainty and the decision it will inform.
- Agree scope, owners, fallback and an end date.
- Record a baseline with its important limitations.
- Capture supplier support and exceptional conditions.
- Define continuation and stopping conditions before launch.
Common questions.
Must a pilot be free?
No. Payment and pricing should be agreed explicitly. A free trial still needs scope and an end date, and willingness to use it does not establish willingness to buy.
What if the result is inconclusive?
Identify why: weak measurement, unusual conditions or a question that was too broad. Repeat only when a revised test can address the cause at a proportionate cost.
Further reading & source context.
These primary references provide background. They are not evidence for the fictional example above and do not endorse AccelerateLink.
Found an error or a missing qualification? Send an editorial correction.
Find my next move.
Use a practical tool to turn this idea into a clearer starting point.
Find my next move