Design a pilot that gives you a real answer
One page that forces a bounded question, a number that would change your mind, and a date you agree to stop on.
When to use this
Use this before a pilot starts, not after the first results arrive. A pilot exists to answer a bounded commercial and operating question with a named owner, a short clock, and a stop/go decision — not to generate a general sense of how things are going. If the team cannot fill in most of this one-pager, the proposal is not ready for field time or partner goodwill, whatever the pitch deck says.
It follows naturally from a Partnership Channel Design Scorecard that has cleared its gates, or from Phase 3 of the 5-Phase Commercial Turnaround Framework. It is the wrong tool for testing something with no realistic operating capacity behind it yet — a pilot cannot substitute for the delivery capacity a channel doesn't have.
1. The decision this pilot will inform
At the end of [date], we will decide whether to: continue / narrow / stop / scale to __________.
Decision owner: ____________________ Review date: ____________________
Naming the decision owner here, before the pilot starts, matters more than it looks. A pilot with no named decision owner tends to drift into a fourth option nobody wrote down: continuing indefinitely because stopping it feels like admitting a mistake.
2. Hypothesis and scope
| Prompt | Answer |
|---|---|
| Priority customer or user | |
| Problem or trigger | |
| Offer being tested | |
| Why this route or partner | |
| Testable hypothesis | If we __________, then __________, because __________. |
| Geography / sites | |
| Pilot dates | |
| Explicit exclusions |
The hypothesis line is the one worth pushing back on hardest. "If we add a third pharmacy site, then revenue will grow, because more sites mean more volume" is not a testable hypothesis — it has no failure condition. A testable version names what would have to be true for the bet to fail, not just what success would look like.
3. Operating design
| Step | Owner | Evidence of completion | Service-level expectation |
|---|---|---|---|
| Reach or referral | |||
| Qualification | |||
| Booking / order | |||
| Fulfilment | |||
| Payment / claim | |||
| Follow-up / closure |
Single operational owner on our side: ____________________
Single operational owner on partner side: ____________________
"Single" is doing real work in both of those lines. A pilot with a team of owners on either side is a pilot with no owner — when something goes wrong at 6pm on a Friday, there needs to be exactly one name each side calls, not a group chat.
4. Measurement plan
Choose a small set of measures that can actually be evidenced from existing workflows, not measures that would require a new reporting process to exist before the pilot can be judged.
| Measure | Definition | Baseline | Target / threshold | Source | Review cadence |
|---|---|---|---|---|---|
| Demand | |||||
| Conversion | |||||
| Delivery / fulfilment | |||||
| Cash / unit economics | |||||
| Quality / safety guardrail | |||||
| Partner execution |
Do not count: activity that cannot be linked to an agreed ID, delivery record, or payment evidence. This is the same evidence discipline used in the 48-Hour Revenue Leakage Audit — a pilot's headline numbers are only as trustworthy as the weakest link they're built on.
5. Economics and assumptions
| Item | Assumption | Owner to validate | Date validated |
|---|---|---|---|
| Price / payer | |||
| Cost to serve | |||
| Partner fee or margin | |||
| Staff / stock requirement | |||
| Collection timing | |||
| Maximum acceptable loss |
Pilot budget cap: __________ Approval: __________
The maximum-acceptable-loss line is the one teams most often leave blank, usually because agreeing on it forces an uncomfortable conversation about how bad "bad" is allowed to get before someone pulls the plug. Fill it in anyway — it is cheaper to have that conversation now than during week three, with a partner watching and money already spent.
6. Data, privacy, and risk boundary
- Minimum data needed to fulfil the service: __________________________________
- Commercial reporting fields (prefer IDs, counts, status, and bands): __________
- Patient-level data required? yes / no. If yes, approved workflow/reference: __________
- Quality or safety stop trigger: ______________________________________________
- Privacy, legal, or clinical reviewer: _________________________________________
- Incident or escalation route: ________________________________________________
Work through this section using the Healthcare Commercial Data Boundary Guide rather than guessing at what "minimum data" means in a healthcare context — the boundary between operational data and patient data is exactly what that guide exists to draw.
7. Go / no-go review
Run this at the review date named in section 1, not before.
| Question | Yes / no | Evidence / action |
|---|---|---|
| The buyer and service problem are specific | ||
| The partner can fulfil the proposed route | ||
| Payment event and reconciliation are defined | ||
| Measures can be produced without manual guesswork | ||
| Data access and permissions are agreed | ||
| Stop conditions have an owner |
Decision: ____________________ Date: __________ Signed by: ____________________
How to read the result, and where this fails
A completed one-pager proves the pilot is capable of producing a real answer either way — a lower and more important bar than proof the pilot will succeed. The most common failure is teams treating a mostly-blank one-pager as a formality to complete after the pilot has already started informally. The blanks are the actual design work; skipping them just moves the same unresolved questions into the field, where they're more expensive to answer.
The second failure is softer and harder to catch: a hypothesis written vaguely enough that almost any result can be read as a partial success. If the go/no-go review at the end produces a debate about what the numbers mean rather than a clean read against the threshold set in section 4, the threshold was set too loosely in the first place — tighten it next time, don't argue the current pilot's numbers into a shape that fits the outcome you wanted.
Worked walkthrough
A generic example: a diagnostics company piloting a new pay-on-collection model at three of its twelve Ikeja pharmacy partners, where the current model bills the lab directly and collection has been slow.
Section 1 names the decision plainly: at the end of six weeks, continue to all twelve sites, narrow to the two best-performing of the three, stop and revert to the old model, or scale to a fourth site type. The hypothesis in section 2 has a real failure condition: "If we collect payment at the point of sample collection, then average days-to-cash will drop from eighteen to under five, because the step no longer depends on a separate invoice cycle — if it doesn't drop below ten, the model hasn't worked well enough to justify the added staff training." Section 4 sets that threshold explicitly rather than leaving "improved collections" vague, and section 6 confirms the pilot needs no new patient data — only an order ID and payment status, already covered by the existing operational flow.
At the six-week review, two of the three sites hit six days-to-cash; the third sits at fourteen, traced to a staff member skipping the point-of-sale step during busy hours rather than a flaw in the model. The decision recorded is "narrow": scale to the two working sites and the rest of the chain, and fix the third site's staff training before including it — a clean decision, possible only because the threshold and ownership were fixed before the pilot began, not argued about after.
If you're about to start a pilot without a written stop condition, contact Dr Tolu Ajidahun to work through the one-pager before the first day in the field.
Read next
The Metric That Was Measuring the Wrong Thing
Three weeks into building Dokitami's field team, signed partners were not converting into paying customers. This is the account of finding out why the number everyone was tracking told them nothing, and rebuilding pay and targets around the one that did.
The Banner That Didn't Fit the Shop
A single 27 by 40 inch banner was chosen as the standard way to make a Dokitami partnership visible in a store. It didn't fit half the stores it was made for. This is the account of what a materials decision made before the field data existed cost, and the fix once the data arrived.
What Nine Hundred Calls in a Day Actually Proves
A high-volume outreach sprint at Dokitami generated roughly 900 partner calls and 135 leads in a single day. The interesting part isn't the count. It's what has to exist before a number like that means anything.