# Feature launch playbook Human Guide ## What This Is For A veteran PM-leader's playbook for launching features well, not just shipping them. It gives the agent a clearer input/output frame for growth marketing: what context to ask for, what decisions to make, and what usable artifact to return. Use this as a human-readable version of the Feature launch playbook agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions. ## When To Use This - Use this when you need a repeatable process for feature launch playbook. - Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt. - Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact. ## When Not To Use This - Do not use this when you only need a quick factual answer. - Do not use this when the work depends on private data you cannot share with the assistant. - Do not use this as a replacement for legal, compliance, financial, or medical review. ## What You Need Before Starting - The goal or business outcome you want. - The audience, customer segment, or market context. - Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance. - Constraints such as tone, length, channel, deadline, region, or approval requirements. - A clear definition of what a good final answer should look like. ## Step-By-Step Workflow 1. State the job clearly: "Use the Feature launch playbook guide to help me with..." 2. Add context: audience, goal, offer, channel, source material, and constraints. 3. Ask the assistant to identify missing inputs before producing the final output. 4. Have the assistant follow the skill-specific guidance below. 5. Review the result against the final checklist and ask for revisions where needed. ## Skill-Specific Guidance - `pm-spec-writing` defines the launch hypotheses; this skill validates them. - `roadmap-planning` provides the launch context (what came before, what comes next). - `product-analytics-setup` is the instrumentation prerequisite; without it you cannot measure the launch. - `experiment-design` and `data-warehouse-experimentation` provide the methodology for testing whether the launch worked. - `feature-flagging` provides the rollout infrastructure this skill depends on. - Treating every release as Tier 1 produces comms fatigue. Customers tune out the announcement firehose; your real Tier 1 launches lose signal in the noise. - Treating every release as Tier 3 produces unlaunched features. The feature ships, the metric does not move, the team concludes "users do not want this" when the actual cause is "users were not told." - **Target user.** Segment, role, jobs-to-be-done. Specific enough that a sales rep could describe the customer profile in one sentence. - **Problem it solves.** Specifically, in user words. Not "we improve productivity"; instead "the customer support manager who needs to triage 200 tickets a day cannot tell which are urgent without opening each one." - **Current alternative.** What users do today without this. The status quo is the real competition. - **User-visible promise.** One sentence. The promise the user will hear when they encounter the feature in the wild. - **Proof points.** Three to five specific capabilities or outcomes. Concrete, not adjectives. ## Decision Points And Nuance The original skill emphasizes: What this skill is for, Ship vs release vs launch, Launch tiers, Pre-launch: positioning, Pre-launch: internal alignment, Pre-launch: customer comms plan, Pre-launch: sales enablement (B2B), Pre-launch: support readiness, Launch day: rollout strategy, Launch day: monitoring. Use these questions to steer the work: - What is the intended audience or buyer? - What source material must be preserved? - What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion? - What examples represent the desired quality bar? - What should the assistant avoid? ## Common Mistakes - Treating every release as Tier 3 produces unlaunched features. The feature ships, the metric does not move, the team concludes "users do not want this" when the actual cause is "users were not told." - For B2C and PLG products, this section is mostly skipped. The user is the buyer; there is no sales motion. Note this explicitly so PMs in those contexts do not feel they are missing the discipline. - Time horizons. Most launches need two to four weeks of post-launch data for engagement signals, four to eight weeks for outcome signals. Do not declare success or failure too early. - "We do not know if it worked." No measurement plan tied to spec hypotheses. - **Sequence comms execution.** Gated on health checks. Never auto-fire if the rollout is paused. - Before declaring a feature failed, audit the launch against this playbook. Half the time the feature was fine; the launch never happened. - **Prevention.** Sales enablement is mandatory for B2B Tier 1 and Tier 2 launches. Battlecard plus 30-minute training plus recorded demo. The investment is small; skipping it is the largest avoidable launch cost. - 7. We do not know if it worked ## Copy-And-Paste Prompt ```text Use the Feature launch playbook human guide. My goal: [Describe the business outcome] Audience: [Describe who this is for] Context and source material: [Paste notes, examples, links, or existing copy] Constraints: [Tone, length, channel, timeline, must-include items, must-avoid items] Before producing the final output, ask me for any missing information that would materially improve the result. ``` ## Final Checklist - [ ] The output matches the original goal. - [ ] The audience and context are reflected in the answer. - [ ] Important constraints and source material were preserved. - [ ] The assistant made the relevant decisions explicit. - [ ] The final artifact is ready to use, review, or hand to the next person. ## Source This guide was generated from the rampstackco/claude-skills skill entry for `feature-launch-playbook`. ## Source Skill Notes These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic. # Feature Launch Playbook A veteran PM-leader's playbook for launching features well, not just shipping them. Most teams conflate shipping, releasing, and launching. Shipping means engineering work is complete. Releasing means users can access it, even if it is behind a flag at 1 percent. Launching is the discipline of positioning, internal alignment, customer comms, sales enablement, support readiness, rollout strategy, monitoring, and post-launch measurement that turns "feature exists" into "feature lands." A feature that ships without launching costs you the same engineering investment but captures a fraction of the value. Sales does not know how to sell it. Support does not know how to help with it. Customers do not notice it. The metric you said you would move does not move because nobody knows the feature is there. This skill is the operational playbook. It assumes you have already written the spec (`pm-spec-writing`), prioritized it onto the roadmap (`roadmap-planning`), instrumented it (`product-analytics-setup`), and possibly tested it (`experiment-design`). The launch is the next discipline: how to actually get the feature in front of the right users, with the right context, in a way that lets you measure whether it worked. When to use this skill: planning a launch (any size, any segment), auditing an existing launch process, fixing the "we shipped it but the metric did not move" problem, or building a launch checklist for the team. --- ## What this skill is for This skill spans the operational launch discipline. It composes with the rest of the Product skill suite. - `pm-spec-writing` defines the launch hypotheses; this skill validates them. - `roadmap-planning` provides the launch context (what came before, what comes next). - `product-analytics-setup` is the instrumentation prerequisite; without it you cannot measure the launch. - `experiment-design` and `data-warehouse-experimentation` provide the methodology for testing whether the launch worked. - `feature-flagging` provides the rollout infrastructure this skill depends on. This skill does not cover pricing decisions, brand campaigns, or full GTM strategy. Those need a marketing team partner; this is the PM operational playbook for the engineering and product side. The audience is broad: every PM ships features, every PM has launched poorly at least once, every PM benefits from a checklist that stops the worst failure modes from recurring. The voice is veteran PM-leader to PM. Specific, opinionated, honest about what discipline matters at what stage. --- ## Ship vs release vs launch The keystone distinction. Three definitions. **Shipping** means engineering completes the work. Code is on production. No users can access it yet, or only internal users via a flag. The PR is merged and deployed. **Releasing** means users can access it. Could be 1 percent rollout, could be 100 percent. The feature is "live" in some technical sense. The flag is on for at least one user. **Launching** means positioning, internal alignment, customer comms, sales enablement, support readiness, rollout strategy, monitoring, and post-launch measurement are all in flight. The feature has been introduced to the people who would benefit from it, with the context they need to use it. The pathology. PMs report "we shipped feature X" when what happened is engineering completed the work. The feature might be released to 1 percent of users with no announcement, no documentation, no sales enablement, no measurement plan. From a value-capture perspective, that is an unlaunched feature. The discipline. Use precise vocabulary. "Engineering shipped on Tuesday. We are releasing to 25 percent on Thursday. We are launching publicly next month." The vocabulary forces honest accounting of what has and has not happened. Most "feature failed" diagnoses turn out to be "feature was unlaunched." This skill is structured around the launch dimension because that is where most teams under-invest. --- ## Launch tiers Not every feature needs the full playbook. Match the work to the feature. **Tier 1 (full launch).** Net-new product, major feature reshaping the product narrative, pricing change, breaking change. Full playbook: positioning, all comms channels, sales enablement, customer success briefing, dedicated post-launch measurement, executive announcement. **Tier 2 (focused launch).** Meaningful improvement that materially affects user value or competitive positioning. Subset of the playbook: in-app comms, blog post or release note, support readiness, rollout strategy, post-launch measurement. **Tier 3 (release note).** Incremental improvement, bug fix made positive, polish. Minimal: changelog entry, release note, light monitoring. The trap on either side. - Treating every release as Tier 1 produces comms fatigue. Customers tune out the announcement firehose; your real Tier 1 launches lose signal in the noise. - Treating every release as Tier 3 produces unlaunched features. The feature ships, the metric does not move, the team concludes "users do not want this" when the actual cause is "users were not told." Match the tier to the feature. This skill primarily covers Tier 1 and Tier 2. Tier 3 is mostly the changelog discipline; the launch playbook applies but compressed to the changelog entry plus light monitoring. Detail in [`references/launch-tier-decision.md`](references/launch-tier-decision.md). --- ## Pre-launch: positioning Positioning answers: who is this for, what problem does it solve, why now, and what is the user-visible promise. The positioning canvas. One page, filled out before any comms drafting. - **Target user.** Segment, role, jobs-to-be-done. Specific enough that a sales rep could describe the customer profile in one sentence. - **Problem it solves.** Specifically, in user words. Not "we improve productivity"; instead "the customer support manager who needs to triage 200 tickets a day cannot tell which are urgent without opening each one." - **Current alternative.** What users do today without this. The status quo is the real competition. - **User-visible promise.** One sentence. The promise the user will hear when they encounter the feature in the wild. - **Proof points.** Three to five specific capabilities or outcomes. Concrete, not adjectives.