---
name: beta-launch-plan
description: "Plans beta launches with user recruitment, feedback collection, bug reporting, and iteration cycles. Use when preparing to launch a product or feature in beta."
allowed-tools: Read Write Glob
metadata:
  author: matthewhitcham
  version: "1.0"
---

# Beta Launch Plan

## When to Use This Skill

Use this skill when you need to:
- Plan a structured beta launch for a new product or major feature
- Design user recruitment and selection criteria for beta testers
- Build feedback collection and bug reporting systems
- Define success criteria for graduating from beta to general availability

**DO NOT** use this skill for full product launches, alpha/internal testing plans, or QA test plans. This is for external beta launch planning only.

---

## Core Principle

A BETA IS NOT A SOFT LAUNCH — IT IS A STRUCTURED LEARNING PERIOD WITH DEFINED GOALS, SELECTED USERS, AND CLEAR EXIT CRITERIA.

---

## Phase 1: Brief

### Required Inputs

| Input | What to Ask | Default |
|-------|------------|---------|
| **Product/feature** | "What are you launching in beta?" | No default — must be provided |
| **Beta goals** | "What do you need to learn from this beta? Validate demand, find bugs, test UX?" | Validate core workflow and identify critical bugs |
| **Target beta size** | "How many beta users do you want?" | 20-50 users |
| **Beta duration** | "How long should the beta run?" | 4 weeks |
| **Ideal beta user** | "Describe your ideal beta tester — role, tech comfort, use case." | Early adopter, tolerant of bugs, willing to give feedback |
| **Known risks** | "What are you most worried about?" | Core functionality breaking under real usage |

**GATE: Confirm the brief before building the plan.**

---

## Phase 2: Plan

### Beta Timeline

```
## Beta Timeline

**Week -2 to -1: Pre-Launch**
- Finalize beta criteria and success metrics
- Build feedback collection system
- Recruit and select beta users
- Prepare welcome materials

**Week 1: Controlled Launch**
- Onboard first cohort (50% of total)
- Daily monitoring for critical issues
- First feedback check-in (Day 3)

**Week 2: Expand**
- Onboard remaining beta users
- First iteration based on Week 1 feedback
- Structured feedback survey

**Week 3-4: Iterate and Evaluate**
- Ship fixes and improvements
- Final feedback survey
- Evaluate against success criteria
- Decision: ship, extend, or pivot
```

### Success Criteria

Define measurable exit criteria:

| Metric | Target | Measurement |
|--------|--------|-------------|
| Critical bugs | 0 unresolved | Bug tracker |
| Task completion rate | 80%+ | User testing |
| NPS score | 30+ | Survey |
| Active usage | 60%+ of beta users engaged weekly | Analytics |
| Feedback sentiment | Mostly positive | Qualitative review |

**GATE: Confirm timeline and success criteria before designing recruitment and feedback systems.**

---

## Phase 3: Execute

### Beta User Recruitment

**Application form fields:**
- Name and email
- Role and company size
- Current workflow for the problem the product solves
- Why they want to join the beta
- Availability for feedback (survey, call, async)

**Selection criteria:**
- Represents the target customer profile
- Has the problem the product solves
- Willing to commit to feedback schedule
- Mix of tech-savvy and average users

**Recruitment channels:**
- Email list announcement
- Social media post
- Existing customer base
- Community or forum post

### Feedback Collection System

**Structured feedback:**
- Weekly survey (5 questions max, takes under 3 minutes)
- End-of-beta survey (10 questions, comprehensive)
- Optional: 15-minute feedback call with 5-10 users

**Unstructured feedback:**
- In-app feedback widget (screenshot + text)
- Dedicated Slack channel or email thread
- Bug report form (steps to reproduce, expected vs. actual behavior)

**Bug Report Template:**
```
**What happened:**
**What you expected:**
**Steps to reproduce:**
1.
2.
3.
**Screenshot (if applicable):**
**Device/browser:**
```

### Communication Plan

- **Welcome email:** What to expect, how to report issues, feedback schedule
- **Weekly update:** What was fixed, what is being worked on, what to test next
- **Thank you email:** End of beta appreciation, what comes next, early access or discount offer

---

## Phase 4: Polish

### 1. Beta-to-Launch Decision Framework

```
## Go/No-Go Criteria

**Ship to GA if:**
- [ ] All critical bugs resolved
- [ ] Task completion rate exceeds 80%
- [ ] NPS is 30 or above
- [ ] No data loss or security issues
- [ ] Onboarding flow works without hand-holding

**Extend beta if:**
- [ ] 1-2 critical issues remain but are solvable in 1-2 weeks
- [ ] Usage is strong but feedback reveals UX confusion
- [ ] Need more data to validate a key assumption

**Pivot or kill if:**
- [ ] Core value proposition is not validated
- [ ] Beta users are not using the product despite reminders
- [ ] Critical technical limitation cannot be resolved
```

### 2. Beta User Appreciation

- Early access to the full product
- Founding user pricing or lifetime discount
- Public acknowledgment (with permission) in launch materials
- Priority access to future betas

### 3. Quality Checklist

```
## Beta Launch Checklist

- [ ] Success criteria defined with measurable targets
- [ ] Beta user application form is live
- [ ] Selection criteria documented
- [ ] Feedback collection system is set up (survey, widget, bug form)
- [ ] Welcome email drafted and scheduled
- [ ] Weekly update template created
- [ ] Bug report template provided to all beta users
- [ ] Go/no-go decision framework agreed on
- [ ] Beta appreciation plan defined
- [ ] Timeline has clear start, checkpoints, and end date
```

---

## Example

**Product:** AI-powered meeting note-taker for solopreneurs
**Beta size:** 30 users, 4 weeks

**Welcome email excerpt:**
"You are one of 30 people testing MeetingMind before anyone else. Over the next 4 weeks, use it in your real meetings. Things will break — that is the point. Report bugs with the red button in the bottom-right corner. Every Friday, you will get a 3-question survey. Your feedback directly shapes what we ship."

**Weekly survey:**
1. How many meetings did you use MeetingMind for this week? (number)
2. Did anything break or feel confusing? (text)
3. On a scale of 1-10, how useful was MeetingMind this week? (scale)

---

## Anti-Patterns

- **Too many beta users** — 200 beta users for a solo founder means 200 sources of feedback you cannot process. Start with 20-50.
- **No success criteria** — without exit criteria, beta runs indefinitely. Define what "done" looks like upfront.
- **Ignoring feedback** — collecting feedback without acting on it destroys beta user trust. Close the loop every week.
- **No communication cadence** — beta users who hear nothing assume the product is dead. Weekly updates are mandatory.
- **Treating beta as free marketing** — beta is for learning, not growth. Optimize for feedback quality, not user count.

---

## Recovery

- **Low beta signups:** Lower the barrier. Remove the application form and invite directly from your email list or social followers.
- **Beta users not providing feedback:** Shorten surveys to 2 questions. Offer a small incentive (gift card, extended trial).
- **Too many bugs to manage:** Triage ruthlessly. Fix critical (data loss, crashes) first. Acknowledge non-critical issues and timeline them.
- **Beta needs to extend:** Communicate transparently. Tell users why, what changed, and the new timeline.
