Write a Rollout and Launch Plan Section
Drafts a structured rollout plan with stages, gate criteria, rollback procedures, and communications. Built for PMs launching features that need careful staged deployment.
When to use this prompt
Use this when a feature is high-risk or touches sensitive user flows (billing, auth, data integrity) and needs a careful rollout rather than a full launch on day one. You will need the feature description, the risk assessment, and any known launch constraints (customer events, compliance windows). The prompt is overkill for simple features; use it selectively for launches where the cost of getting it wrong is high. It is especially useful when cross-functional stakeholders (support, sales, finance, legal) need to know when the feature is reaching different audiences.
The Prompt
You are a product manager drafting the rollout and launch plan section of a PRD for a higher-risk feature. The plan must define staged rollout, gate criteria, rollback procedures, and communications for each stage. Feature: {{feature_name}} Risk level: {{risk_level}} Known constraints: {{constraints}} Target launch date: {{launch_date}} Produce a 4-stage rollout plan with this structure for each stage: STAGE 1: INTERNAL DOGFOOD - Audience: [who] - Entry criteria: [what must be true before starting] - Exit criteria: [what signals we are ready for the next stage] - Duration: [days or weeks] - Rollback triggers: [specific conditions that pause or reverse the rollout] - Communications: [who is notified and how] STAGE 2: BETA (5-10 percent) - Same subsections as above. STAGE 3: LIMITED AVAILABILITY (25-50 percent) - Same subsections as above. STAGE 4: GENERAL AVAILABILITY (100 percent) - Same subsections as above. After the stages, produce: 1. ROLLBACK PROCEDURE â Step-by-step: who can pull the trigger, how to revert (feature flag off, DB rollback, etc.), expected time to restore. 2. STAKEHOLDER COMM PLAN â Matrix of Who (team) x When (stage) x What (message format and channel). 3. LAUNCH DEPENDENCIES â External dependencies that must be resolved before each stage (legal review, customer notifications, support training). 4. GO/NO-GO DECISION POINTS â Specific moments where a human decision is required before advancing to the next stage. Do not invent fake criteria. If you do not have enough information, mark sections as TBD and flag them as blockers.
Example Output
STAGE 1: INTERNAL DOGFOOD - Audience: 40 internal employees on beta flag. - Entry criteria: Feature flag is live, internal accounts seeded with test data. - Exit criteria: 3 business days of no P1 bugs and at least 20 active users logging in daily. - Duration: 5 business days. - Rollback triggers: Any P1 bug, or confused feedback from more than 5 employees. - Communications: Slack #product and #support channels, daily standup update. STAGE 2: BETA (5 percent of customers) - Audience: 20 hand-picked customers with strong support relationships. - Entry criteria: Stage 1 passed; customer success has briefed each beta customer. - Exit criteria: No customer escalations for 5 business days; primary metric trending correctly. - Duration: 10 business days. - Rollback triggers: Any customer escalation marked P1; primary metric regression >5 percent. - Communications: Beta customer email on day 1, weekly check-in calls, product Slack update twice a week. STAGE 3: LIMITED (25 percent) â similar structure... STAGE 4: GA (100 percent) â similar structure... ROLLBACK PROCEDURE: On-call engineer flips feature flag off via internal admin panel. ETR under 5 minutes. PM is notified; incident postmortem scheduled within 48 hours. STAKEHOLDER COMM PLAN: | Team | Stage 1 | Stage 2 | Stage 3 | Stage 4 | | Support | Slack briefing | Talking points doc | Full training | Launch FAQ | | Sales | None | Product Slack | Enablement session | GA blog post | GO/NO-GO DECISIONS: PM + EM sign off before each stage advance. Exec sign-off required for Stage 3 to 4 transition.
Recommended Tools
Linear supports the rollout plan as a project with staged milestones and blockers, giving engineering clear handoff points. Productboard ties the rollout back to the PRD and roadmap commitment so execs can track progress in context. Notion is the right home when you want the rollout plan as a living document reviewed cross-functionally. Choose based on whether your team treats the rollout as execution work or communication work.
Frequently Asked Questions
When should I use this prompt?
Use it for launches where the cost of a bad rollout is high: features touching billing, auth, data, or regulated flows. Also use it when the launch is visible to external stakeholders (a press moment, a customer migration, a compliance deadline). Skip it for small UX improvements where a feature flag toggle is sufficient process. The rollout plan adds meaningful overhead, so reserve it for launches where the care is warranted by risk or visibility. A good rule: if a rollback would be visible to customers, the feature needs this prompt.
What is the minimum viable rollout plan?
Every launch needs three elements: a feature flag to kill the feature fast, at least one stage of internal or beta testing, and a rollback procedure that someone besides the PM knows how to execute. If you cannot name who can roll the feature back in under 10 minutes, you do not have a rollout plan; you have a wish. The prompt's 4-stage structure is the comprehensive version; for medium-risk features, collapse Stage 1 and Stage 2 and keep only the gate criteria that matter. Do not collapse the rollback procedure; that stays.