A product pilot should end with a decision that the team is prepared to make. Without that agreement, a trial can collect enthusiastic comments, unresolved issues and more feature requests while nobody knows whether to continue. The remedy is a small operating plan written before the product reaches the participants. It defines the work, the evidence and the choices available at the end.
Consider an illustrative pilot for software that prepares installation requests for scheduling. The product receives information from a customer and helps a coordinator identify what is missing. The pilot is meant to establish whether a small operating team can use it for a defined set of requests. The plan below is an adaptable example, with the details to be agreed for the actual customer and product.
Write the decision in one sentence
Start with the question the pilot will resolve. “Should the team use this product for all requests at this location?” is more useful than “Does the team like the product?” The first question names a possible operating change. It gives the sponsor a reason to inspect reliability, adoption and support alongside feedback about the interface. Put the person responsible for that decision on the plan.
Agree the available outcomes before testing begins. They might be continue to a larger deployment, repeat a bounded part of the pilot after a specific repair, or stop. Each outcome should have a practical consequence. A decision to repeat needs a new question and a limit; otherwise it becomes an indefinite extension of the same trial. The founder and customer should know what evidence would support each path.
Define who and what enters
Select a narrow participant group whose work can be understood. Name the operating owner, the users and the person who answers support questions. State which types of requests enter the pilot and which remain in the existing process. For the installation example, one location and one standard job type might be enough to begin. The boundary should be easy for a coordinator to recognize during a busy day.
Write entry conditions for the product as well. Required accounts should be available, access should be appropriate and the team should know how to report a problem. Check that the examples used in training resemble the actual work. If the customer cannot provide the necessary records or staff time, resolve that before the clock starts. A pilot with missing inputs mostly measures the consequences of those missing inputs.
Agree the baseline and the evidence
Choose a small set of measures tied to the decision. For this example, the team could track the share of requests ready without another information exchange, the time to readiness and the number needing manual recovery. Record enough about the request type to interpret differences. Establish how those measures are recorded in the current process before comparing the new one.
The Service Standard’s measurement guidance connects success measures with user research. In a private product pilot, that can mean reviewing the numbers alongside short discussions of actual requests. A count explains how often something happened; the people handling the work help explain why. Keep both forms of evidence available to the decision maker.
Include the work around the product
A new tool can appear efficient by moving effort somewhere else. The coordinator may finish faster while a supervisor checks every record manually. A customer may submit complete information only after a support call. Record those activities during the pilot. The useful question is whether the whole responsibility is handled better, including the work required to keep the product operating.
Give users a simple way to record a recovery without writing a report. A short issue form can capture the request identifier, what blocked progress and what the person did next. Keep sensitive customer information out of informal chat channels. Decide who reviews the issue list and how often, then make that review part of the pilot routine rather than an optional task at the end.
Set a support boundary people can use
Participants need to know how to get help and what happens if the product is unavailable. Name a contact route and explain the fallback process. For an installation request, the team might return to its existing scheduling preparation while preserving the information already collected. Practice that fallback once so it is an operating procedure the team can use when needed.
Separate a product defect from a requested addition. A defect prevents the agreed task from working. An addition changes the scope of the product. Both deserve a record, but they should not automatically receive the same treatment during the pilot. The founder can repair a blocked submission while keeping a new reporting module for a later decision. That keeps the evidence connected to the original question.
Plan the review rhythm
Hold short reviews at agreed points rather than waiting for a final presentation. Bring a few real examples, the current measures and the unresolved issues. Ask whether participants are using the product for the intended work and whether the entry conditions still hold. A shift in staffing or request type can change the trial enough that the plan needs an explicit adjustment.
The GOV.UK beta guidance describes learning from real users while preparing a service for operation. For a small founder-led pilot, keep that connection concrete. Each review should resolve a question about the current product or the proposed next stage. Record the decision, the owner and the effect on the remaining pilot, then return the team to the work.
Decide what must stop the trial
Some conditions deserve an immediate pause rather than a note for the final review. Define those conditions with the customer. Examples may include incorrect routing of essential information, an access problem or an inability to recover a stalled request. The right list depends on the product and its setting. Make sure the operating owner knows how to pause participation and restore the existing process.
Also define the less dramatic reasons to stop. The product may handle the task, yet the team may not have the ongoing capacity to maintain the required source data. Or the selected workflow may occur too rarely to support a useful trial. A stop decision can clarify the next investigation. The pilot has done its job when it produces a reasoned choice the team can act on.
Prepare the exit before the final meeting
Write down how records and access will be handled when the pilot ends. If the customer continues, who owns administration and what support arrangement begins? If the trial stops, how will the team retrieve needed information and remove access? Confirm these responsibilities early. They are part of introducing software into an operating business, even when the first trial is small.
The final review should compare the evidence with the original decision statement. Show representative requests, explain what changed during the pilot and distinguish unresolved facts from future ideas. End with a named next action. A founder using NV2 can present a focused first product with a clear company identity and a disciplined trial behind it. The immediate next step is to write the one-page agreement with the operating owner before recruiting participants.