| 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":"Salah-XD","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:
- How many meetings did you use MeetingMind for this week? (number)
- Did anything break or feel confusing? (text)
- 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.
