Prepare your product for a measured launch.

A launch is a learning and delivery cycle, not a ceremony that makes an unfinished product valuable. Start with one buyer, one task, one scoped product, and the evidence you already have. If the buyer or task is still undefined, use the Offer Research Lab first. If the product page is misleading or incomplete, work through the Sales Copy Lab before inviting purchases.

Write a launch brief: buyer, finish line, current offer version, evidence and limits, files, distribution channel, measurement, owner hours available, cash you can afford to spend, and a review date. Choose one primary measure and two guardrails. A primary measure might be completed use of the sample or paid orders from defined qualified exposures. Guardrails might be access failures and support time. They are planning choices, not industry benchmarks.

Use the 14-day sequence as a dependency map. Days 1-4 investigate the task and scope. Days 5-7 create usable files and test delivery. Days 8-10 finish the decision page and one useful public guide. Days 11-14 publish only after gates pass, observe, and write a decision. A part-time creator may need several weeks. Waiting for participants, fixing accessibility, or pausing for a missing support channel is legitimate; do not relabel unfinished work as launched to match a calendar.

A gate asks whether a necessary condition is actually met. Examples are files open, the description matches them, permission exists for demonstration inputs, checkout and access are tested, and the business can receive support requests. A checkbox is a record, not proof. Attach the artifact or test note behind it. Completion in this self-paced lab is self-reviewed work, not instructor verification. Background references provide planning context, not a prediction of business success.

Worked example

Fictional worked example — Jordan prepares a bounded release of the Interview Outline Kit. Buyer: an adult first-time host with a booked guest and topic. Output: a one-page outline. Current evidence: two fictional usability attempts in this teaching scenario, not real customer evidence. Files: walkthrough, research worksheet, question map, rehearsal checklist. Channel: one permitted demonstration post and an optional subscribed-email invitation only if the email system is ready.

Jordan allocates 18 owner hours across three calendar weeks, although the planner has 14 work slots. Cash cap: $90 for approved promotion, with no spending until the product and delivery gates pass. Primary measure: paid orders from tracked qualified product-page visitors. Guardrails: failed access attempts and support hours. Unknown: demand beyond the small initial channel.

Week one covers slots 1-4. Week two covers files and delivery. Week three covers the page, guide, observation, and decision. A pending support mailbox prevents paid publication; Jordan does not tick it complete or promise a 14-day result.

Your exercise

1. Complete the launch brief using real current facts and labeled unknowns. Attach the offer decision if one exists; otherwise record why readiness research is pending.
2. In launch-planner.xlsx, Launch Plan tab, or a plain table, assign the 14 suggested days to your actual calendar and available hours. Give each task an owner, output, dependency, and review state.
3. Choose one primary measure, define its denominator if it has one, and select two operational guardrails. Keep learning measures separate from sales measures.
4. Set maximum cash and owner hours for this cycle. Record what pauses or stops the cycle, including missing delivery, misleading claims, or a broken support route.
5. Create a readiness checklist with a link or file reference for every completed gate. Mark unresolved items Pending instead of checking them optimistically.
6. Explain which task must finish before you invite a purchase and why. Move the calendar if that dependency is not ready.

Check your work

• One buyer, task, and scoped product are defined.
• Existing evidence and unresolved assumptions are distinguished.
• Each planned task has an output, dependency, owner, and realistic work slot.
• Cash and owner-hour caps are separate and explicit.
• The primary measure and two guardrails are defined before release.
• No unresolved file, checkout, support, or accuracy gate is presented as completed.