Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From rampstack-skills
Runs structured betas that produce real signal: participant selection, feedback collection, beta-to-GA decisions. Use when planning a beta, auditing past betas, or deciding GA readiness.
npx claudepluginhub rampstackco/claude-skills --plugin rampstack-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/rampstack-skills:beta-program-managementThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A senior product leader's playbook for running betas that produce real signal. Closed and open betas, alpha programs, design partner programs, early access. Participant selection, structured feedback collection, beta-to-GA decision criteria, and the difference between soft-launch (no structure, no signal), kitchen-sink (everyone in, no actionable feedback), and structured beta (calibrated cohor...
references/beta-onboarding-templates.mdreferences/beta-to-ga-graduation-criteria.mdreferences/beta-type-decisions.mdreferences/beta-wind-down-communication.mdreferences/cohort-sizing-patterns.mdreferences/common-beta-failures.mdreferences/feedback-collection-patterns.mdreferences/mid-beta-triage-and-iteration.mdreferences/participant-selection-criteria.mdOperational playbook for launching features: positioning, internal alignment, customer comms, sales enablement, support readiness, rollout strategy, monitoring, and post-launch measurement. Use when planning a launch, auditing a launch process, or fixing shipped-but-no-metric-movement.
Plans launches for developer tools, APIs, SDKs via tier assessment, plan generation, readiness checks, and checklists for docs, code assets, DX.
Share bugs, ideas, or general feedback.
A senior product leader's playbook for running betas that produce real signal. Closed and open betas, alpha programs, design partner programs, early access. Participant selection, structured feedback collection, beta-to-GA decision criteria, and the difference between soft-launch (no structure, no signal), kitchen-sink (everyone in, no actionable feedback), and structured beta (calibrated cohort, intentional feedback loops, clear graduation criteria).
Most betas underperform. Teams ship a beta because they think they should run a beta; participants are recruited loosely or open-flooded; feedback is collected ad-hoc through whatever channels exist; the decision to graduate to GA happens on calendar rather than on signal. The beta produced activity but not learning; the team launches with the same uncertainty they had before the beta.
This skill is the discipline that turns betas into decision input. Calibrated cohorts who match the post-launch user profile. Structured feedback that captures what the team needs to know. Mid-beta triage that uses what is being learned. Graduation criteria that distinguish "ready" from "we are tired of running the beta." The discipline is not bureaucratic; it is the difference between a beta that informs the GA launch and a beta that produces noise.
The voice is the senior product leader who has run betas with real signal and watched plenty of betas produce nothing. Concrete, opinionated about what produces signal, willing to call out where beta programs slide into ceremony.
When to use this skill: planning a beta for an upcoming launch, auditing why prior betas have not produced actionable signal, designing the beta participant experience, or deciding whether a feature is ready to graduate from beta to GA.
This skill spans beta program design and execution. The PM and engineering distinction:
feature-flagging is rollout mechanics; the technical layer for controlling who gets which features.beta-program-management (this skill) is participant management and feedback discipline; the human layer.feature-launch-playbook is the full launch (post-GA); this skill is what happens BEFORE GA.experiment-design is rigorous A/B testing; betas are softer, qualitative-leaning, smaller-N.user-feedback-aggregation is ongoing feedback streams; beta feedback is bounded to the beta period.discovery-research-synthesis is one-off discovery research; betas are validation-stage rather than discovery-stage.The audience: senior PMs, product directors, engineering leads coordinating with product, customer success and support running beta cohorts, anyone planning a closed or open beta.
What is not in scope: the broader feature launch (covered by feature-launch-playbook); the technical rollout mechanics (covered by feature-flagging); the rigorous experimentation methodology (covered by experiment-design); the discovery-stage research that informs whether to build the feature in the first place.
The keystone framing.
Soft-launch. "We will just turn it on for some users." No structured participant selection, no defined feedback collection, no graduation criteria. The beta runs because the team wanted to ship the feature without the full launch ceremony. Output: the feature is in production for some users; the team has no organized way to learn from their experience; signal accumulates through whatever channels happen to surface it; mid-beta course-correction does not happen because there is no structure to surface what should be corrected.
Kitchen-sink. Everyone gets in. The beta opens to whoever signs up. 5,000 beta users; 50 useful pieces of feedback; 4,950 silent users who provide no signal. Volume drowns signal. The team cannot tell which users matched the target post-launch profile. Feedback channels overflow; useful patterns get lost in noise; mid-beta triage cannot keep up. Output: a sense of "we ran a big beta" without the actionable feedback that smaller calibrated cohorts produce.
Structured-beta. Calibrated cohort selected by participant criteria. Intentional feedback loops the cohort knows to use. Clear graduation criteria that distinguish "ready for GA" from "tired of the beta." Mid-beta triage that uses what is being learned. Output: the beta produces decision-grade signal; the GA launch ships with confidence; problems that would have surfaced in production get caught and addressed in beta.
The litmus test. After the beta concludes, ask: what specifically did we learn from this beta that changed the GA launch? If the team can name 3-7 specific lessons, the beta was structured. If the team can only generally say "the beta went well," the beta was soft-launch or kitchen-sink.
Several axes of beta-type choice. The right combination depends on the launch context.
Closed vs open.
Alpha vs beta vs RC.
Internal vs external.
Time-bounded vs open-ended.
The combination decision. A typical structured beta might be closed + beta + external + 6-week time-bounded. A design partner program might be closed + alpha + external + open-ended. An open early access might be open + beta + external + time-bounded. The combination should match the kind of signal the team needs.
Detail in references/beta-type-decisions.md.
The discipline that makes calibrated cohorts possible.
The criteria that work.
The criteria that fail.
The cohort size question. Calibrated cohorts are usually 20-200 participants for closed external betas. Smaller (5-20) for design partner programs. Larger (200-2,000) for open early access. Beyond 2,000 the program is a soft-launch with beta branding.
Detail in references/participant-selection-criteria.md.
How big is enough; when does signal saturate.
Saturation patterns.
Sizing decisions.
The "beta size matches signal need" principle. Cohort size follows from what the team needs to learn. Larger is not always better; calibrated is.
Detail in references/cohort-sizing-patterns.md.
How participants enter the beta and what they know going in.
The setup.
The expectations contract.
Common onboarding failures.
Detail in references/beta-onboarding-templates.md.
Structured channels that produce signal rather than noise.
Channels that work.
Channels that fail.
Channel mix discipline. Most structured betas use 3-5 channels. Each channel surfaces different kinds of signal. The team synthesizes across channels.
Detail in references/feedback-collection-patterns.md.
How the team responds to feedback during the beta.
The principle. Betas where the team responds to feedback during the beta produce stronger signal than betas where the team waits for the end.
The triage cadence.
The iteration discipline.
The communication discipline. Participants are kept informed: "We received your feedback on X; we are addressing it in next week's beta update." Silence makes participants feel ignored; over-communication signals overhead. Calibrate.
Detail in references/mid-beta-triage-and-iteration.md.
Graduation gates that distinguish "ready" from "tired of running the beta."
The criteria.
The "we are tired of running the beta" anti-pattern. Beta has run long enough that the team wants to graduate regardless of signal. The graduation decision happens on calendar rather than on criteria. Resist this; either the criteria are met (graduate) or they are not (extend or reset).
The "perpetual beta" anti-pattern. Beta runs indefinitely because no firm graduation criteria were set. The team avoids the GA commitment by keeping the feature in beta. Force the graduation decision; if the feature is not ready for GA, identify what would make it ready or reconsider whether to ship at all.
Detail in references/beta-to-ga-graduation-criteria.md.
How the beta ends.
The graduation announcement. Participants are told the feature is graduating. Specific date. What changes for them: continued access (typically yes), pricing changes (often beta participants get free access for some period), feature stability commitments (the GA version is what they will use going forward).
The transition.
The thank-you. Beta participants invested time providing feedback. Recognition matters: named in changelog (with consent), gift cards or swag, advance access to future betas. The recognition strengthens future-beta recruitment.
The postmortem. Internal review of what the beta produced. What was learned, what changed in the GA launch, what would be done differently in future betas. This feeds the team's beta program practice.
Detail in references/beta-wind-down-communication.md.
Rapid-fire. Diagnoses in references/common-beta-failures.md.
When designing or auditing a beta program, walk these 12 considerations.
The output of the framework is a beta program that produces decision-grade signal, supports the GA launch, and treats participants well enough to recruit them for future betas.
references/beta-type-decisions.md - Closed/open, alpha/beta/RC, internal/external, time-bounded/open-ended. The combination decision and how it matches signal need.references/participant-selection-criteria.md - Criteria that produce calibrated cohorts. Common selection failures. The cohort size question.references/cohort-sizing-patterns.md - Saturation patterns by feedback type. Sizing decisions for different beta goals. The size-matches-signal principle.references/beta-onboarding-templates.md - Welcome communication structure. NDAs, feedback channels, support paths, incentives. The expectations contract.references/feedback-collection-patterns.md - Structured surveys, async forms, interviews, in-product widgets, beta-aware support. Channels that work and fail. Channel mix discipline.references/mid-beta-triage-and-iteration.md - Triage cadence. Iteration discipline (what to fix during, what to defer). Communication with participants.references/beta-to-ga-graduation-criteria.md - The six graduation criteria. The "tired of the beta" anti-pattern. Perpetual beta anti-pattern.references/beta-wind-down-communication.md - Graduation announcement, transition, recognition, postmortem. Treating participants well.references/common-beta-failures.md - 10+ failure patterns with diagnoses and cures.A structured beta is one of the most useful product activities available. The cohort experiences the feature; the team learns from their experience; the GA launch ships with reduced uncertainty. The discipline pays back many times its cost.
A soft-launch or kitchen-sink beta is one of the least useful. The team spends weeks running an activity that produces ambient activity without converting to learning. The GA launches with the same uncertainty the beta was supposed to address.
The teams that earn returns on betas are the ones that take the structure seriously: cohorts calibrated to the GA profile, feedback channels designed for signal, mid-beta triage that uses what is being learned, graduation criteria that distinguish ready from tired, wind-down communication that treats participants well enough to recruit them again.
When in doubt about whether a beta is ready, ask: are participants matched to the GA user, are feedback channels structured, is the team responding to feedback during the beta, are graduation criteria explicit and being applied honestly, will participants want to join the next beta? If yes to all of those, the beta is real. If no to any, the gap is where the beta will fail to convert participation into learning.