Beta Launch Plan

Every Invitation Opens an Obligation

A beta is often described as early access. For a solo founder, access is the least interesting part. Every admitted user creates an obligation to observe the value path, provide support, recover from failures, protect whatever data the product receives, and follow the evidence through to a decision. Ten invitations can become ten half-understood product tests competing for the same founder’s attention.

Use a beta to increase exposure deliberately after an MVP or manual workflow has produced a result worth repeating. The product should be able to carry a narrow part of the promise without private founder heroics. Manual onboarding, review, and support may remain, but they must be visible inside the result.

Bring the MVP Experiment Card, the target-user definition, the shortest onboarding path, known limitations, the observation plan, the recovery path, and a candid limit on founder capacity. If the value event is still vague, the product cannot deliver it safely, or the founder cannot see where a user stopped, make the experiment smaller before recruiting a beta cohort.

Write the Expansion Decision First

“Learn from users” does not tell the founder which users to admit, what to watch, or when to stop. Name the decision this beta must change. It may decide whether to widen access, narrow the segment, repair onboarding, retain a manual review, or stop investing in the workflow.

Then copy the plan. Write the gates before the first invitation; thresholds written after the outcome are explanations, not controls.

BETA LAUNCH PLAN

DECISION
Decision this beta must change:
Evidence already earned:
Question that wider exposure must answer:
What this beta cannot prove:
Review date and natural return interval:

COHORT CONTRACT
Target user, role, and recurring situation:
Qualification evidence required before access:
Exclude or defer:
Promise in the user's language:
Required input or setup:
Activation event:
Experienced value event:
Repeat behavior and when it should occur naturally:
Product boundary; founder work shown separately:
Unsupported workflows and known limitations disclosed:

EXPOSURE AND CAPACITY
Wave sizes and admission dates:
Maximum active accounts or simultaneous workflows:
Founder availability during each wave:
One support channel and response boundary:
Support, failure, or trust condition that pauses invitations:
Safe fallback, correction, rollback, or recovery path:
Data, access, retention, deletion, and human-review boundary:

OBSERVATION PATH
Record for every invited user:
source -> qualified -> accepted -> onboarded -> activated -> reached value
-> returned / did not return / not yet due

Evidence captured by the product:
Evidence captured in the recruiting or customer record:
Errors, abandonments, and silent nonuse made visible by:
Founder minutes, reminders, repairs, corrections, and judgments recorded in:

USER RECORD — COMPLETE ONE PER INVITEE
User, role, source, qualification evidence, and invite date:
Accepted, declined, or no response:
Setup begun and onboarding help supplied:
Activation event and date, or last observed stopping point:
Value event and date, or why value was not reached:
Return due date; returned without reminder / after reminder / did not return:
Support contacts, themes, severity, and minutes:
Founder repairs, corrections, manual work, or rescue:
Product failure, workflow mismatch, trust concern, or unresolved risk:
Outcome and next contact or decision:

GATES — WRITE BEFORE THE BETA BEGINS
Admit the next wave only when:
Pause invitations immediately when:
Widen access when:
Hold and repair when:
Narrow the segment or promise when:
Stop the beta when:

The cohort contract keeps the audience and promise stable long enough to interpret behavior. The user record preserves the denominator: an invited person, a qualified person, an activated user, and a returning user are different states. The gates turn those states into action.

Let One Wave Earn the Next

A cohort is not controlled merely because it is small. Admit users in waves that fit the product’s failure modes and the founder’s capacity to respond. The first wave should be large enough to expose variation but small enough that one serious failure can be understood before more people encounter it.

Wait for the relevant behavior, not an arbitrary number of days. A weekly reporting product needs another reporting cycle. A close-management product may need the next monthly close. A developer tool may reveal activation in its first successful call but require another deployment to show repeat value. Mark users whose return is not yet due; do not classify them as retained or lost to make the review date tidy.

Do not silently change qualification, onboarding, or the promise halfway through a wave. When a necessary repair changes the path, record which users saw each version. The comparison may be useful, but it is no longer one unchanged exposure.

Follow Behavior Before Asking for Opinions

Feedback is most useful when attached to an observed point in the workflow. “I liked it” cannot substitute for reaching value. “I would use this” cannot substitute for returning at the natural interval. A feature request from a user who never entered the core workflow has a different weight from the same request made after repeated use.

Read the path in order. Of the people invited, who accepted? Of those who accepted, who qualified and began setup? Where did the right users stop before activation? Who experienced the promised result? Who repeated the behavior, and who needed a founder reminder? Keep the counts and the individual records; an aggregate conversion rate can hide one segment that works and another that consumes support without reaching value.

Instrumentation should preserve only the events and properties needed to operate the beta and answer its decision. Product events may show imports, errors, activation, and repeat use. A customer record can preserve source, qualification, follow-up, support, and the user’s account of value. Neither source makes the other unnecessary.

Put Support Inside the Product Result

Fast founder support can be appropriate during a beta. Invisible founder support is dangerous. Record the minutes, intervention, and outcome whenever the founder explains setup, repairs data, corrects an output, reminds a user, or completes part of the promised workflow.

Classify the intervention before deciding what it means. Onboarding help may reveal one explanation the product should make clearer. A repair may expose an unsupported input that should be rejected. Repeated judgment may belong in the human-reviewed promise. A rescue may be keeping a weak product alive. Work performed for only one customer may show that the user falls outside the intended segment.

Look at peak burden, not only the average. Five accounts requiring ten minutes each may fit. One account requiring three urgent hours during the same afternoon may break the support promise and crowd out recovery for the other four. Severity matters too: a privacy, data-loss, unsafe-output, or trust failure can justify pausing invitations even when the support queue is short.

A Two-Wave Beta That Resists Expansion

Consider a product that helps operations leads at small bookkeeping firms turn close checklists into a priority list for missing client documents. The founder has observed the workflow manually and can now produce the list in the product. The beta question is whether qualified operations leads can use that list during a real close and return at the next close without the founder privately repairing ordinary inputs.

The founder plans eight firms in two waves of four. Each firm must manage recurring monthly clients, have an operations lead responsible for close, and be able to supply the supported checklist format. The promise is narrow: show which missing documents deserve attention first. The beta does not send client reminders, accept every bookkeeping export, or replace the firm’s judgment about escalation.

Activation occurs when an operations lead imports a real checklist and produces a reviewable priority list. Value occurs only when the lead uses that list to change at least one follow-up. Return is another close begun without a founder reminder. The founder records import failures, time to activation, changed follow-ups, return, support contacts, and every private repair.

The first wave reveals two different breaks. One firm’s import partly fails, and the product reports the number of rejected rows without identifying them. Another firm pauses because the explanation of data access during support is unclear. The founder helps the first firm recover and answers the second honestly, but neither intervention disappears into a successful activation count. The user records preserve a product-recovery failure and a trust boundary that was too vague.

The written gate says the second wave may begin only when ordinary import failures identify affected rows, the data explanation matches actual practice, no unresolved high-severity issue remains, and support stayed within the promised window. The founder makes those repairs, records that the second wave will see a different path, and only then admits four more firms.

At the review date, five firms have reached value. Two have returned without a reminder; a third returned after follow-up. Most support came from firms whose apparently supported checklists contained unrecognized variants. That result does not earn public access. It supports another invite-only cycle with the segment and input contract held narrow. The next decision is to test whether the repaired import path and clearer data boundary reduce founder intervention—not to add more features or more people.

Close the Beta With a Written Decision

At the review boundary, choose one primary move.

• Widen access when qualified users repeatedly reach value, the path is observable and recoverable, and the founder can absorb the resulting support without hiding product weakness.
• Hold and repair when the intended users want the result but fail at a shared onboarding, reliability, recovery, or trust boundary.
• Narrow when one role, workflow, input, or acquisition source reaches value while the broader cohort creates noise or exceptions.
• Keep a bounded manual component when it is explicit, supportable, and part of what users value rather than a private rescue.
• Stop when qualified users do not reach or repeat value, ordinary use cannot be supported responsibly, or founder effort produces most of the apparent success.

Preserve the user records and the version of the path each person encountered. Then carry the beta’s original question, its actual denominators, the support and intervention record, the strongest counterevidence, and the chosen next move into the Launch Retrospective.

The beta is ready to grow when the current cohort has taught the founder how the product behaves without requiring the next cohort to repeat the same lesson at greater cost.