The first customer agreeing to trial your platform does not necessarily need every feature imagined for next year. They do need to complete the work they pay for and understand the service's limits. That distinction should govern an MVP development brief, rather than randomly removing screens to obtain a lower starting price.
Write the commercial question the pilot should answer: does the customer use the core workflow in their work, and do they find enough value to continue under known terms? Successful registration or enthusiasm for a demonstration does not answer that alone. Equally, one paying customer does not establish market-wide demand or guaranteed scalability.
Choose repeatable work you can observe
In a fictional example, a platform collects print-shop customers' comments on artwork versions. Comments currently disappear across messages, making the reviewed version unclear. The first task is to display an identified version, collect comments attached to it and show that review has ended under an agreed internal definition.
The pilot excludes designing artwork, operating printing machines and proving legally binding approval. It begins with a participating print shop and defined users rather than public registration. These boundaries allow actual work to be observed without purchasing a complete printing management platform under the label first version.
A pilot worksheet before the feature list
| Decision | Write for the example | Evidence to review |
|---|---|---|
| Participant | A print shop and authorized reviewers with known tasks. | Who actually used the workflow and in which role? |
| Value | Reviewing a version without losing comment context. | Completed work samples and documented obstacles. |
| Scope | Version upload, comments and a defined review state. | A journey repeatable from beginning to end. |
| Operation | Invitations, support and declared manual steps. | Team intervention time and each intervention's reason. |
| Pilot ending | A review date and continuation, change or stop decision. | A result record, limitations and a justified next step. |
The table proposes an experiment design, not a ready-made success standard. Agree duration, payment, available service, support and how the participant relationship ends before starting. Do not present a usage percentage or customer target as a universal benchmark without a reason appropriate to the pilot.
Defer automation that does not test the question
The team might create customer workspaces manually and send invitations through a known procedure instead of building self-service registration and multiple plans immediately. Record that intervention, its limits and operating cost. If success depends on an employee doing most work for the customer, that is important product evidence rather than a detail to conceal.
An advanced report or nonessential integration might also wait if the task remains useful without it. Ask the SaaS development company how each feature affects the pilot question: what could we no longer learn if it were removed now? This reduces scope for an understandable reason instead of relying on intuition.
A small version still needs responsible operation
Deferring pricing plans does not justify unbounded customer file access or lost work without support. Specify accounts, permissions, data preservation, failures and end-of-pilot export according to what you actually provide. Consult the subscription platform scope guide for these responsibilities without implementing every option in the first phase.
GOV.UK guidance distinguishes alpha prototypes for exploring ideas from public services. Government procedures and durations are not being prescribed for a commercial product. The useful principle is testing difficult assumptions early. A paid pilot doing real work, however, has operational commitments to agree and should not be treated as a visual demonstration.
Measure events alongside customer statements
Lean Startup describes a build-measure-learn cycle linking an initial product to hypothesis testing. In the print-shop example, examine artwork reviews started and completed, where users left the journey and what the team performed manually. Add interviews explaining reasons rather than relying on visits or general satisfaction statements.
Separate willingness to pay for the pilot from reasons for continuing or stopping. A participant may use it because your team intervenes extensively or because their situation is unusual. Record contradictory as well as supportive observations. A limited sample is not measured market demand or a revenue forecast.
Finish with an explainable decision
At the end, identify what the sample established, what remains unknown and what needs testing next. The decision might be improving the same journey before another customer, changing the target group or stopping. If you are purchasing analysis only, consult discovery deliverables: buying consultancy differs from testing a product with a paying user.
Sources and preparation
The Lean Startup methodology and GOV.UK alpha guide were opened on 3 November 2026. They support assumption testing and early learning, not product success or pricing terms. The example and worksheet are editorial proposals. AI assisted preparation, with content and source review.
