The prompt
Score 10 of 10, Excellent
Use it when You are about to put a new feature in front of a small group of customers and need who to invite, what to ask and when the beta is over.
- {{audience}}
- {{feature}}
- {{learning_goals}}
- {{candidate_customers}}
- {{capacity}}
- {{known_risks}}
Full prompt and why it works
Prompt
Plan a beta program for the feature below, for {{audience}}, so that we learn what we need before a general launch and agree in advance what "ready" means. The feature: """ {{feature}} """ What we most need to learn: {{learning_goals}} Customers we could invite, or the segments we have: {{candidate_customers}} Timeline, and team capacity for supporting beta users: {{capacity}} Known risks or rough edges: {{known_risks}} Use these headings: 1. Goals: up to 3 questions the beta must answer. 2. Who to invite: selection criteria, how many customers (with the reason, given our support capacity), and who to leave out, such as accounts in a renewal negotiation. 3. Invitation: an email under 150 words that says what the feature is, what we ask of them (time, feedback), what could go wrong and how to leave the beta. 4. Feedback plan: when and how we collect feedback (in-product prompt, short survey, calls), with up to 5 survey questions. 5. Measures: what we track in usage data, tied to each goal. 6. Exit criteria: the specific conditions for moving to general launch, extending the beta, or stopping, decided now. For example: "At least 6 of 10 accounts use it weekly in weeks 3 and 4, and no open bug blocks a core task." 7. Timeline: a table with the columns Week, Activity, Owner. Keep the plan under 800 words. Exit criteria must be measurable, with numbers, not "customers are happy". Do not promise beta users discounts, early pricing or features beyond what is described above. Use only customers or segments from my list; if the list is empty, describe the profile to look for instead of naming companies. Where the plan needs a fact I have not given, such as how a customer leaves the beta, write [to confirm] rather than inventing it. If our capacity looks too small for the number of users the goals need, say so and suggest the trade-off.
Variables
- {{audience}}
- Who needs to agree on the plan, for example "product, engineering and the customer success lead".
- {{feature}}
- What the feature does and what state it is in.
- {{learning_goals}}
- What you most need to find out, for example "whether admins can set it up without help".
- {{candidate_customers}}
- Customers or segments you could invite. Write "none chosen yet" if you have no list.
- {{capacity}}
- How long the beta can run and how much time the team has for beta users, for example "6 weeks, one PM and one support person part time".
- {{known_risks}}
- Rough edges and risks you already know about. Write "none known" if there are none.
Why it works
- What good looks like. Exit criteria with numbers are written before the beta starts, so "ready" cannot be redefined once people are attached to a launch date.
- Length. The number of beta customers is tied to the support capacity you give, so the plan does not invite more users than the team can listen to.
- What to avoid. No discounts or extra features promised to beta users, which keeps the invitation from creating commitments nobody approved.