The 3-2-1 Launch Method: A 90-Day Startup Experiment Plan
A 90-day launch plan can organize learning and a first customer offer. It cannot guarantee profitability, product-market fit or a viable business in that period. Use the deadline to bound spending and force decisions, while allowing evidence to change the scope.
The plan below is a suggested sequence for a small, unregulated product or service that can be tested safely. Hardware, clinical products, financial services and other complex or regulated activities may need substantially longer preparation. Do not compress essential safeguards to meet an arbitrary date.
What the 3-2-1 launch method means here
Use three learning stages, two decision checkpoints and one final commitment decision to organize the 90 days. This is an editorial planning structure offered by Startup Genius. We have not verified a canonical startup methodology with this exact name, and do not attribute it to a historical inventor or claim evidence that it produces profitable businesses in 90 days.
The three stages are discovery, offer-and-delivery testing, and repeatability review. The two checkpoints occur after discovery and after the first delivery period. The final decision determines what commitment, if any, the evidence justifies. These counts organize the work; they are not a prescribed number of interviews, customers or experiments.
| Part | Suggested period | Evidence to bring to the review |
|---|---|---|
| Stage A: discovery | Days 1–20 | Customer situation, alternatives, buyer roles and contrary evidence |
| Checkpoint A | Around day 20 | A specific problem and a reachable audience, or a reason to narrow or stop |
| Stage B: offer and delivery | Days 21–65 | Clear pilot terms, actual customer actions and delivery effort |
| Checkpoint B | Around day 65 | Evidence about usefulness, payment and the burden of delivering the result |
| Stage C: repeatability review | Days 66–90 | A second delivery or customer test, economics and outstanding uncertainties |
| One final commitment decision | Around day 90 | Continue within a new limit, change a central assumption, pause or stop |
The calendar is adjustable. A customer with a quarterly buying cycle may not be able to purchase within the suggested period. Record that constraint explicitly rather than counting a warm conversation as a sale. If an essential approval cannot fit safely into the plan, change the scope or schedule.
Make both checkpoints consequential
At the first checkpoint, bring original notes and observations, not just a summary of encouraging comments. Ask whether the customer group has a sufficiently similar problem to test one offer. If the evidence divides into several unrelated needs, narrow the segment before building.
At the second checkpoint, inspect delivery records alongside customer enthusiasm. Has a customer received the promised result? What did the team do manually? Which input failed? Was the agreed payment collected or merely discussed? The same pilot can provide encouraging demand evidence and discouraging delivery evidence.
Write a short decision record at each checkpoint. It should identify evidence, an alternative interpretation, the next question and its resource limit. The team can continue despite uncertainty, but should be able to explain why that uncertainty is affordable.
For a usable record, adapt the startup experiment plan. Keep separate experiments for distinct questions if their conditions or audiences differ. Otherwise a positive result becomes difficult to interpret.
Define the single final decision in advance
The final decision is a choice about the next commitment, not a ceremonial launch announcement. Possible commitments include serving another bounded batch, building one repeatable workflow or testing a different buyer. Compare the cost of that step with what it would teach or deliver.
Illustrative planning example: a founder reserves a finite test budget and expects the pilot to require both setup and review time. During discovery, consultants confirm that the report matters but cannot provide compatible exports. The founder uses checkpoint A to narrow the audience to customers with suitable records. Checkpoint B then tests whether manually preparing a report creates sufficient value at an acceptable effort level. At day 90, the founder might authorize an import prototype instead of launching a broad platform.
That is useful progress even if the company is not profitable. Conversely, a small profitable pilot might depend on an unusually easy customer and still leave acquisition unproven. Preserve those distinctions when communicating the outcome to colleagues or investors.
Before day one: choose the question and limit
State the customer, problem and proposed outcome. Identify what would make the project unattractive even if the product could be built. Set a cash limit, a founder-time allowance and obligations you must preserve.
Write an initial decision rule. For example, a team might require evidence that appropriate customers will commit to a bounded pilot and that delivery appears feasible within its resources. The exact threshold depends on risk and context; copying another company’s target does not make it valid.
Days 1–20: investigate the problem
Recruit relevant prospective customers and reconstruct recent experiences. Compare current alternatives and the consequences of the problem. Identify the buyer, user and any person who can block adoption.
Create a short evidence summary, including conflicting accounts. Refine the segment if people describe substantially different needs. Use market research to separate population context from direct workflow evidence.
At the first review, choose whether to proceed with the current problem, narrow it or stop. Completing interviews is an activity; understanding a plausible purchasing situation is the milestone.
Days 21–40: test a specific offer
Draft an offer with a clear result, scope, delivery process and proposed price. Show a prototype or demonstrate the task where that helps customers understand it. Test understanding before interpreting reluctance as rejection of the underlying need.
Ask for an appropriate action, such as booking a detailed session, arranging buyer approval or agreeing to pilot terms. Describe what exists and what is proposed accurately. A waitlist can indicate interest under those conditions, but does not prove payment or regular use.
Review objections and acquisition effort. The value proposition guide can help distinguish a confusing message from an unappealing offer.
Days 41–65: deliver a narrow pilot
Build only what is needed for one complete task. Agree customer expectations and support arrangements. Record manual work, errors and exceptions so founder effort does not disappear from the economics.
Illustrative example: a founder tests a monthly reporting service for independent consultants. Rather than building a reporting platform, the founder offers a limited paid pilot using customer-authorized exports and a manual review process. The pilot measures report usefulness, delivery time, corrections and whether another report is requested.
Its success condition is not “launch a polished website.” It is evidence about whether a useful result can be delivered reliably at a plausible cost.
Days 66–90: test repeatability and decide
Try serving another suitable customer or repeating delivery to an existing one. Revisit the acquiring, onboarding and supporting effort. Compare collected cash with spending and outstanding obligations. Separate a one-time favorable event from a process another colleague could repeat.
| Evidence at the final review | Proportionate next action |
|---|---|
| Useful delivery and credible paid demand | Test a larger but bounded batch |
| Useful result with excessive delivery labor | Narrow scope or redesign the process |
| Interest without meaningful commitment | Revisit buyer, offer and switching barriers |
| Poor demand and little learning runway | Pause, stop or test a clearly different hypothesis |
Document the decision, including what the 90 days did not establish. A small pilot does not demonstrate market-wide demand or predictable acquisition costs.
Keep learning visible throughout
Maintain a weekly record of hypotheses, evidence, cash and decisions. A deadline is useful only if it leads to an honest choice. Extending the project may be reasonable, but state what another period would learn and what it would cost.
Use the startup checklist to identify any foundation the experiment still needs. Begin by putting the first research round and its decision review on the calendar, rather than promising a profitable company by day 90.