Turn an uncertain idea into a small, inspectable test: one question, one complete promise, clear observations, and a decision you define before the results arrive.
For which of you, desiring to build a tower, does not first sit down and count the cost…Luke 14:28 (excerpt)
A pilot should make the next decision clearer. It is not a miniature launch designed to produce a flattering screenshot. You are choosing a small enough setting to notice where the promise breaks, while keeping enough of the real experience to learn something useful. If the result could not change what you build next, the activity may be a demonstration rather than a test.
The one-page plan below is for low-risk tools, workshops, community experiences, and services. It is not a substitute for specialist oversight where health, safety, safeguarding, significant money, or regulated decisions are involved. Start with a question you can investigate responsibly. A smaller pilot does not make an unsafe intervention acceptable.
Planning is a form of stewardship, not a promise that every outcome can be controlled. Write what you hope to learn, what would count against your preferred answer, and what you will do if the test cannot answer the question. That makes an inconclusive result useful instead of embarrassing.
1. Choose the decision before choosing the activity.
Begin with the decision that is currently blocked. Should you simplify the worksheet, offer a guided session, or stop building this particular solution? Then write the uncertainty underneath it. “Do first-time founders understand the promise without an explanation?” is narrower and more observable than “Does our mission resonate?”
Keep a learning question separate from a growth target. An attendance target can help you organize an event, but reaching it will not tell you whether the experience worked. A pilot question should name what you intend to observe and the decision that observation could inform. The GOV.UK Service Manual similarly connects service purpose, hypotheses, and meaningful measurements; the planning format here is an original SIX33 worksheet, not a government certification.
Decision: what might we continue, change, or stop?
Uncertainty: what do we not yet know?
Question: what observation could reduce that uncertainty?
Disconfirming signal: what would challenge our preferred explanation?
2. Make the scope small, but keep the promise complete.
Choose a tightly described participant group and the simplest experience that can still deliver the promised value. A promise worksheet might be one page and a short session. If the promise includes choosing a first test, the participant needs to leave with a test, not merely receive a PDF. Cut decorative features before cutting the part that makes the experience useful.
Write what is outside the pilot. You may be testing whether someone can complete a planning task, not whether their business will succeed. Do not let a convenient short-term measure stand in for that larger outcome. Also record the delivery conditions: a founder-led session, a self-guided page, and a workshop with peer support are different versions of the experience.
For whom: a specific situation and relevant recent experience.
Complete means: the recipient can do a named thing.
Included: the smallest materials, support, and follow-up needed.
Not tested: the larger claims this pilot cannot answer.
3. Decide how to observe the task before running it.
Choose what you will record, when, and by whom. For a worksheet, this could be whether the participant identifies a person, writes a complete promise, and chooses a dated next action. Record whether each step was completed independently, completed after assistance, not completed, or not observed. Those categories are more useful than a single “successful” checkbox.
GOV.UK describes moderated usability testing as observing people attempting realistic tasks. Apply that principle by describing the goal without explaining the answer. If you intervene, help the person, but record the intervention. Assistance is part of the evidence, not a failure you must hide. Keep observed actions, participant reports, and your interpretations in separate fields.
Task and observable completion definition.
Evidence source: direct observation, participant report, or another named record.
Assistance provided and where it was needed.
Date, setting, version of the experience, and missing observations.
4. Write a decision rule, not a claim of statistical proof.
A decision rule helps a small team avoid moving the goalposts after seeing the results. For example, you might decide that any repeated misunderstanding of the core promise triggers a wording revision before another round. That is an operational choice. It is not a validated threshold, an industry benchmark, or proof that a particular sample represents a wider population.
Use a threshold only if you can explain why it is appropriate to your decision. Keep the underlying counts and case notes even when you use a rate. Two completions out of three observations should remain “2 of 3,” with the context attached. A percentage alone can make a very small convenience sample look more conclusive than it is.
Continue when: the evidence is sufficient for the next limited test.
Change when: a defined problem or uncertainty remains.
Stop or pause when: the promise is not useful, delivery is unsafe, or the question cannot be answered responsibly.
Inconclusive when: missing evidence or changed conditions prevent the intended decision.
5. Work through a hypothetical pilot before inviting anyone.
This example is hypothetical and is not a SIX33 result. A builder wants to test whether a one-page promise worksheet is understandable without live coaching. They invite four first-time founders who recently struggled to choose an initial delivery. The task is to name one recipient, describe the complete promise, and choose a dated first test. The version, invitation route, and assistance policy are written down before the sessions.
Suppose two participants complete the task independently, one completes it after the builder explains a phrase, and one does not finish. The useful record is two independent completions, one assisted completion, and one non-completion among four participants. The next decision could be to rewrite the confusing phrase and run another round. “Three of four completed with differing support” may describe the task result; “our worksheet makes founders successful” is not supported by this test.
The sample is small and self-selected, the task is short, and business outcomes have not been followed. Keep those limits beside the finding. If the plan changes midway, record which participants saw which version instead of silently treating them as one identical group.
6. Protect the people and close the learning loop.
Explain the purpose, what you will record, how it will be used, and that declining or leaving will not affect access to help. Collect only what the test needs. An anonymous participant code is often enough for an internal learning record. Keep identifiable notes out of public build logs, shared screenshots, and templates. Ask separately before recording, quoting, or publishing a person's story.
At the end, compare the result with the original question. Record what changed, what remains unknown, and the next decision with an owner and a date. A pilot that exposes an unsuitable promise can save months of building. That is useful learning, not a transformation claim. If the question concerns later behaviour, plan a proportionate follow-up instead of treating a positive exit comment as an outcome.
The short versionA pilot earns its value by improving the next decision, not by making the launch story sound certain.
Put the guide to work
One-page pilot plan
Copy or download the blank template. Edit it in your own document, keep participant details private, and replace every bracketed prompt before sharing.
Read or select the full template
This downloads the public blank template only. It does not include your private journal notes or tool drafts.
Include the decision, uncertainty, participant group, complete promise, task, evidence source, time window, assistance rules, decision rule, privacy boundaries, and limitations. After delivery, add the finding and next decision without changing the original question to fit the result.
How many people do I need for a pilot?
There is no universal number that makes a pilot valid. Choose a scope suited to the question, risk, participant diversity, and observation method. A small learning round can reveal problems, but it cannot by itself establish population-level demand or a causal impact estimate.
Is a pilot the same as an MVP?
Not necessarily. An MVP describes a minimal product version; a pilot is a bounded test of an experience in a particular setting. A manual service or workshop can be piloted without building software. In either case, keep the useful promise complete.
What if the pilot result is inconclusive?
Publish what was observed and what could not be determined. Missing responses, changed conditions, or an unsuitable observation method may justify another test, not a success label. Do not convert a blank outcome into zero or assume a silent participant had a positive result.
