Work
Something you can use

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.

6 minPilots · Commercial operations · Partnerships

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.

Working on something like this?

Get in touch