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.

---

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.
• Anti-positioning. What this is NOT, what it does not try to do. Prevents over-promising.

The most common positioning failure is a vague target user. "It is for PMs" is not a target. "It is for B2B SaaS PMs at companies with 50 to 500 customers who need to coordinate roadmap discussions across engineering and customer success" is a target. The specificity is what lets sales, marketing, and support speak the same language about who this is for.

Detail in references/positioning-canvas.md.

---

Pre-launch: internal alignment

Stakeholders who need to know before launch.

• Engineering leadership. Capacity for follow-ups, support escalations, post-launch fixes.
• Sales leadership. Revenue forecast updates, deal coaching, pipeline impact.
• Customer success leadership. Proactive customer notifications, deal saves at risk, expansion conversations.
• Marketing leadership. Paid spend coordination, blog calendar, social timing.
• Support leadership. Training, FAQ, escalation paths.
• Executive sponsor. Visibility, public messaging, investor or board reporting.

The discipline. A single internal launch brief, distributed two to four weeks before launch (Tier 1) or one week before (Tier 2). The brief contains a one-page summary, an FAQ, a decision log of choices already made, and the launch calendar. The brief should answer "what do I need to do differently because of this launch."

The most common internal alignment failure: launching without sales knowing. Sales finds out from a customer asking about it. Trust erodes for the next launch. The fix is the launch brief plus a sales-specific briefing one to two weeks before customer-facing launch.

Detail in references/internal-alignment-checklist.md.

---

Pre-launch: customer comms plan

Channels and decision factors.

• In-app. Highest reach for active users; right for product-internal features. Tooltips, banners, modals.
• Email (transactional or campaign). High reach across active and inactive users; right for material changes that affect existing workflows.
• Blog post. SEO plus lead gen plus narrative; right for Tier 1 launches with external story.
• Release notes. Discoverable, archived, queryable; right for every Tier 2 and above. Often the canonical reference customers find later.
• Social (LinkedIn, X, Bluesky). Reach beyond existing customers; right when launch has external narrative or competitive angle.
• Webinar or customer call. Depth for enterprise customers; right for Tier 1 with material customer impact.
• Sales-led briefing. High-touch for top accounts; right when launch affects pricing, contracts, or strategic positioning.

For each channel: who drafts, who approves, what is the timing, what is the call to action.

The comms calendar pattern. A single document with all channels and dates, distributed in the internal launch brief. Prevents the "blog post went out before sales got the briefing" failure. Ordering typically goes: sales briefing first, support training second, customer success outreach to top accounts third, public comms fourth.

Detail in references/customer-comms-playbook.md.

---

Pre-launch: sales enablement (B2B)

For B2B products, sales enablement is not optional for Tier 1 and most Tier 2 launches. The deliverables.

• One-page battlecard. Positioning, target customer, top objections, proof points. Sales can read it in two minutes and pitch the feature in five.
• Demo script and recorded demo. A repeatable demo the rep can run with a customer; the recorded version is the fallback for reps who join after the launch.
• Pricing change documentation if applicable. Sales reps cannot answer pricing questions accurately without explicit guidance.
• Deal coaching guide. Which deals does this unblock, which does it complicate. Specific named accounts where appropriate.
• Internal training session live or recorded, with Q&A archived. Sales reps need the chance to ask questions before they take the feature to a customer.

The "shadow launch" failure. Feature ships, sales hears about it from product team Slack, no battlecard, sales reps either ignore it or misrepresent it to customers. Customers churn because the feature was promised in a way that did not match reality.

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.

Detail in references/sales-enablement-template.md.

---

Pre-launch: support readiness

Support is often the first to encounter the failure modes of a new feature. They need.

• Training live or recorded, with Q&A. The same content as the sales training adapted to support workflows.
• FAQ document covering known questions, known limitations, and known bugs at launch. The FAQ updates daily during the first week as new questions surface.
• Escalation path for issues that need engineering or PM. Named owners and turnaround time commitments.
• Monitoring access or a way to ask for it. Support reps should be able to verify whether a customer's issue is feature-specific.

The discipline. The support team's confusion is the test customer's confusion. If support does not understand the feature, neither will customers. Train support before customer-facing launch comms go out.

Detail in references/support-readiness-checklist.md.

---

Launch day: rollout strategy

Four common patterns matched to feature type.

All-at-once (big bang). Zero to 100 percent in a single deploy. Right for marketing-coordinated launches where the announcement IS the rollout. Risky for anything where bugs would affect a meaningful customer base. Use sparingly.

Gradual percentage rollout. 1 percent, then 10 percent, then 25 percent, then 50 percent, then 100 percent over hours or days, monitored at each step. Right for most feature launches; the default unless there is a reason to deviate.

Flag-gated cohort rollout. Targeted to specific user segments. Free tier first, then paid. Small accounts first, then enterprise. Right for features with cohort-specific risk profiles.

Phased launch (multi-week). Launch to a subset of users, regions, or customers; gather feedback; iterate; expand. Right for Tier 1 launches with high uncertainty about user reception.

The decision framework. Feature blast radius times confidence in correctness times external commitments.

• High blast radius plus low confidence plus no external commitment: phased.
• Low blast radius plus high confidence plus external launch date: all-at-once.
• The middle (most launches): gradual percentage rollout.

Detail in references/rollout-strategy-patterns.md.

---

Launch day: monitoring

Pre-launch, define what you will monitor and what alerts you. Common dimensions.

• Error rates. Overall plus feature-specific.
• Latency. Overall plus feature-specific.
• Feature usage rate. People who SHOULD use it actually do.
• Funnel completion. Users complete the new flow.
• Support ticket volume. Especially feature-specific tags.
• Customer satisfaction signals. NPS comments, feedback widget mentions.

Define the rollback trigger explicitly before launch. Examples.

• "Error rate above 1 percent sustained for 5 minutes triggers rollback."
• "Support tickets mentioning the feature exceed 50 in the first hour triggers escalation."
• "Funnel completion drops below 50 percent of pre-launch baseline for any cohort triggers paused rollout."

The "no rollback trigger" failure. Launch goes sideways. The team debates whether to roll back for an hour while the issue compounds. Pre-defined triggers remove the debate; the rule fires automatically and the team executes the rollback.

Detail in references/monitoring-readiness-checklist.md.

---

Launch day: comms execution

The comms calendar from the customer comms section executes on launch day. Each channel has a clear owner, a clear time, and a clear sequence.

• In-app banner activates when rollout reaches X percent.
• Email sends after a 4-hour stability check.
• Blog post publishes at the time announced internally.
• Sales briefing happens one day before public comms.
• Support training happens one week before launch.

The "comms misfire" failure. Blog post auto-publishes at the scheduled time, but the rollout was paused two hours earlier due to an issue. Customers click through to a feature that is behind a flag for them. They lose trust; the launch story breaks.

The fix. Make external comms manually triggered, gated on a rollout health check. The comms timing in the calendar is the planned timing; the actual fire is conditional on the rollout passing the health check.

---

Post-launch: measurement against spec hypotheses

The spec (per pm-spec-writing) should have stated explicit hypotheses about what the feature would change. The launch measurement plan validates or invalidates each.

Four measurement dimensions.

1. Adoption. Did the right users actually use it? The reach question. Is the feature visible to the target segment, and are they trying it.
2. Engagement. Did users who tried it come back? The stickiness question. First use is necessary but not sufficient.
3. Outcome. Did the metric the spec said this would move actually move? The effect question. The hypothesis the spec made.
4. Side effects. Did any other metric move that was not supposed to? The safety question. Sometimes the feature works but breaks something else.

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.

The "no measurement plan" failure. Feature ships; the team moves on; six months later nobody knows if it worked. The feature becomes maintenance debt; the team cannot decide whether to invest in it further.

Detail in references/post-launch-measurement-framework.md.

---

Post-launch: iteration and follow-ups

Within the first four weeks post-launch, expect.

• Bug discoveries that did not surface in QA or limited rollout.
• Usability issues that did not surface in user research.
• Adoption gaps in cohorts you did not expect to under-adopt.
• Feature requests for adjacent capabilities.

The discipline. Document every issue, triage weekly, prioritize fixes against the original measurement plan.

If adoption is below target, the question is. Is it a marketing problem (users do not know about the feature)? A usability problem (users try the feature and bounce)? A value problem (users try the feature and do not see value)? A wrong-segment problem (the target was not who we thought)?

Each diagnosis maps to a different fix.

• Marketing problem: more comms, repeat comms, sales reactivation.
• Usability problem: design or onboarding fix.
• Value problem: feature redesign or repositioning.
• Wrong-segment problem: re-target the comms to a different audience.

The "we declared victory" failure. The launch metric hits target in week 1 (often due to the launch announcement spike); the team moves on; the metric falls back to baseline by week 4. The launch was reported as successful but the feature did not actually land.

The fix. Declare success or failure based on a stable post-launch trend, not the launch-week spike. Most launches need at least a four-week stable trend before the success or failure call is reliable.

---

Common failure modes

Twelve patterns recur across feature launches. Detail in references/common-launch-failures.md.

• "We shipped it but nothing happened." Unlaunched. No comms plan, no internal alignment, no measurement.
• "Sales is confused and selling it wrong." No enablement. Battlecard, demo, training were skipped or rushed.
• "Support is overwhelmed." No training, no FAQ. Support is encountering the feature for the first time when customers ask.
• "We rolled out and immediately rolled back." No rollout strategy, no health check. The big-bang deploy hit production and broke.
• "The blog post went out but the feature is broken." Comms misfire. The comms were not gated on rollout health.
• "Adoption was great in week 1, now it is flat." Declared victory on the launch spike. The metric reverted to baseline.
• "We do not know if it worked." No measurement plan tied to spec hypotheses.
• "Customers say we did not tell them." Comms did not reach the right segments. Email went to active users only; inactive users were not notified.
• "Enterprise customers found out from their account manager three days late." No high-touch tier in comms. Top accounts deserve sales-led briefing before public comms.
• "Our metric moved but it was actually because of a different launch that week." No isolation. Cannot attribute the metric movement to this launch versus other concurrent changes.
• "We launched the wrong feature." Positioning unclear. Customers expected something different from what shipped; the gap between expectation and reality reads as a failed launch even though the feature works.
• "It worked but nobody knew about it internally." No internal alignment. Sales did not capitalize on the feature in deals; customer success did not save accounts that were churning over the gap this feature now closes.

---

The framework: 12 considerations for a real launch

When planning a launch, walk these 12 considerations. Skipping any of them produces one of the failure modes above.

1. Tier the launch. Tier 1, Tier 2, or Tier 3. Match the effort to the feature.
2. Position it. Target user, problem, promise, proof points, anti-positioning.
3. Align internally. Single launch brief, distributed two to four weeks before launch.
4. Plan customer comms. Channel mix, calendar, owners, gates.
5. Enable sales. Battlecard, demo, training, deal coaching (B2B only).
6. Ready support. Training, FAQ, escalation paths, monitoring access.
7. Pick a rollout strategy. All-at-once, gradual, flag-gated, or phased.
8. Define monitoring. Metrics, alerts, rollback triggers. Pre-defined, not in-the-moment.
9. Sequence comms execution. Gated on health checks. Never auto-fire if the rollout is paused.
10. Tie measurement to spec hypotheses. Adoption, engagement, outcome, side effects.
11. Iterate post-launch. Weekly triage. Distinguish marketing, usability, value, and segment problems.
12. Declare success or failure on a stable trend. Not the launch-week spike.

The output of the framework is a launch plan document. The positioning canvas, the internal launch brief, the comms calendar, the rollout strategy with health-check gates, the monitoring spec with rollback triggers, and the post-launch measurement plan tied to the spec hypotheses. The plan is reviewed two weeks before launch; gaps are filled before the launch date.

---

Reference files

• references/launch-tier-decision.md - Tier 1, 2, 3 decision framework with worked examples.
• references/positioning-canvas.md - One-page positioning template with B2B SaaS, B2C, and developer feature examples.
• references/internal-alignment-checklist.md - Stakeholders, brief structure, distribution timing by tier.
• references/customer-comms-playbook.md - Channels, calendar, owners, gates.
• references/sales-enablement-template.md - Battlecard, demo, deal coaching, training (B2B). Skip note for B2C and PLG.
• references/support-readiness-checklist.md - Training, FAQ, escalation, monitoring access.
• references/rollout-strategy-patterns.md - Four patterns matched to feature types. Decision framework: blast radius times confidence times external commitments.
• references/monitoring-readiness-checklist.md - Metrics dimensions, alert thresholds, pre-defined rollback triggers.
• references/post-launch-measurement-framework.md - Adoption, engagement, outcome, side effects. Time horizons. Tying back to spec hypotheses.
• references/common-launch-failures.md - Twelve failure patterns with diagnoses and fixes.

---

Closing: most failed launches are unlaunched

When a feature "fails," the most common diagnosis is not that the feature was wrong. It is that the launch was incomplete. Sales did not know. Customers were not told. Support could not help. The metric did not move because the launch did not reach the people who would have moved it.

Before declaring a feature failed, audit the launch against this playbook. Half the time the feature was fine; the launch never happened.

The discipline of separating shipping from releasing from launching is the single most useful PM vocabulary upgrade. Use it explicitly. Use it in stand-ups, in roadmap reviews, in launch retrospectives. The team that uses precise language about what has happened catches unlaunched features before declaring them failed and reallocates the engineering investment toward features that would actually capture value.

When in doubt about whether a launch is ready, ask: is the launch brief written and distributed? Has sales seen the battlecard? Does support have the FAQ? Is the rollout strategy chosen and the rollback trigger defined? Are the comms gated on a health check? Is the measurement plan tied to the spec hypotheses?

If any of those answers is no, the launch is not ready. Delaying the launch by a week to close the gaps is cheaper than launching incomplete and capturing a fraction of the value the feature could have delivered.

---

Supporting file: references/common-launch-failures.md

Common launch failures

Twelve patterns that recur across feature launches. For each: name, symptom, root cause, fix, prevention. Cross-references to other reference files.

---

1. We shipped it but nothing happened

Symptom. The team reports "we shipped feature X." Three weeks later, nobody is using it. The metric the spec said this would move has not moved. Internal stakeholders ask if the feature is live; nobody is sure.

Root cause. Unlaunched. Engineering completed the work; the team did not execute the launch. No comms plan, no internal alignment, no measurement plan tied to spec hypotheses.

Fix. Treat it as a re-launch. Audit against the playbook: positioning, internal alignment, customer comms, sales enablement, support readiness, measurement plan. Distribute the launch brief. Sequence comms. Re-measure at the four-week checkpoint.

Prevention. The launch brief is the artifact that prevents this. Without a brief, the launch defaults to engineering completion plus silence. With a brief, the launch has a calendar, owners, and measurement.

See: internal-alignment-checklist.md, customer-comms-playbook.md, post-launch-measurement-framework.md.

---

2. Sales is confused and selling it wrong

Symptom. Customers ask sales questions sales cannot answer. Reps over-promise capabilities the feature does not have. Customers churn because the feature was sold wrong.

Root cause. No sales enablement. Battlecard, demo, training were skipped or rushed. Reps are improvising in front of customers.

Fix. Pause the launch (pause public comms; let in-app and release notes continue). Run the sales enablement playbook in compressed form: write the battlecard, record the demo, hold the training. Resume public comms after sales is enabled.

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.

See: sales-enablement-template.md.

---

3. Support is overwhelmed

Symptom. Support ticket volume doubles or triples on launch day. Tickets pile up. Customer wait times balloon. Support reps escalate everything to the PM.

Root cause. No training, no FAQ, or both. Support is encountering the feature for the first time when customers ask about it. They cannot answer questions; they escalate; the queue grows.

Fix. Emergency FAQ. PM and support lead spend 4 hours documenting every question that has come in. FAQ updates push to support immediately. Re-train if needed (a short refresher).

Prevention. Support training one week before launch. FAQ written before launch, not during. Estimate support volume realistically; staff for elevated volume.

See: support-readiness-checklist.md.

---

4. We rolled out and immediately rolled back

Symptom. Big-bang deploy hit production. Within minutes, error rate was up. The team rolled back. Customers experienced a broken feature for 30 minutes; some saw error states.

Root cause. Wrong rollout strategy. All-at-once was used when gradual was the right pattern.

Fix. Audit the rollback. What was the bug; what would have caught it earlier in a gradual rollout. Pre-mortem the next launch.

Prevention. Default to gradual percentage rollout for most launches. Use all-at-once only when the marketing-coordinated launch makes it unavoidable, AND the team has high confidence in correctness, AND the blast radius is low.

See: rollout-strategy-patterns.md.

---

5. The blog post went out but the feature is broken

Symptom. Blog post auto-published at the announced time. Rollout had been paused two hours earlier due to an issue. Customers click through; 75 percent of them do not have the feature; they report "broken" feature that is actually a paused rollout.

Root cause. Comms not gated on rollout health. Auto-fire schedule executed regardless of rollout state.

Fix. Pull or update the blog post. Communicate transparently: "We hit an issue in our rollout; the feature is paused while we resolve. Your account will get access once we resume."

Prevention. Make external comms manually triggered, gated on health check. Auto-fire is convenient but brittle.

See: customer-comms-playbook.md.

---

6. Adoption was great in week 1, now it is flat

Symptom. The launch announcement drove a spike of users trying the feature. By week 4, adoption has dropped back to near-baseline. The team had declared victory in week 1.

Root cause. Declared victory on the launch spike. The metric reverted because the launch announcement was the only driver of usage; users tried the feature once but did not come back.

Fix. Re-evaluate as if the launch is unfinished. Diagnose: was it an awareness problem (users forgot the feature exists), a usability problem (users tried and bounced), a value problem (users tried and did not see value), a wrong-segment problem (the audience was wrong). Iterate based on the diagnosis.

Prevention. Declare success or failure on the stable post-launch trend, not the launch-week spike. Minimum measurement window is four weeks.

See: post-launch-measurement-framework.md.

---

7. We do not know if it worked

Symptom. Six months after launch, the team cannot answer "did feature X work?" Nobody measured. The feature is now maintenance debt.

Root cause. No measurement plan tied to spec hypotheses. The launch did not commit to specific metrics with specific decision rules.

Fix. Retroactive measurement. Pull the data; compare to a pre-launch baseline (if one exists); compute the lift. The retroactive measurement is less rigorous than a planned one but better than nothing.

Prevention. Every launch has a measurement plan. The plan is part of the launch brief. A launch without a measurement plan does not get scheduled.

See: post-launch-measurement-framework.md.

---

8. Customers say we did not tell them

Symptom. A customer reaches out asking why nobody told them about a feature that has been live for two months. The customer was on the email list; the email was sent; the customer missed it.

Root cause. Comms did not reach the right segments. Email went to active users only; inactive users were not notified. Or the email subject line was generic and customers archived without reading.

Fix. Re-send to the cohort that missed it. Use a different channel (in-app banner, account-manager outreach for top accounts). Improve the discoverability for new visitors (pricing page mention, feature-tour highlight).

Prevention. Channel-mix analysis. For each launch, plan which channels will reach which cohorts. Inactive users need a different reach plan than active users.

See: customer-comms-playbook.md.

---

9. Enterprise customers found out from their account manager three days late

Symptom. Enterprise customer hears about a launch from their account manager three days after public comms went out. The customer is annoyed; their AM is embarrassed; trust erodes.

Root cause. No high-touch tier in comms. Public comms hit before account managers had been briefed.

Fix. Apologize to the affected customer. Brief their AM immediately with the full context. Adjust process for the next launch.

Prevention. Sales-led briefing for top accounts before public comms. Account managers should know about the feature one to three days before customers do, with talking points for the customer conversation.

See: customer-comms-playbook.md, sales-enablement-template.md.

---

10. Metric moved but it was actually because of a different launch that week

Symptom. Outcome metric is up 8 percent in the four weeks post-launch. Team celebrates. Then someone notices a different launch happened the same week, and a price test concluded, and a marketing campaign ran. The 8 percent cannot be attributed to this specific feature launch.

Root cause. No isolation. Multiple changes hit production in the same window; effects are confounded; the team cannot tell which change drove which metric.

Fix. Run a follow-up isolated test. Roll back the feature for a cohort; measure the gap. If the gap is large, the feature was driving the metric. If the gap is small, other concurrent changes were the driver.

Prevention. Stagger launches. Major launches should not coincide with each other; at minimum two weeks of separation for measurement isolation. For experiments, use the warehouse-native experimentation framework to isolate.

See: data-warehouse-experimentation skill.

---

11. We launched the wrong feature

Symptom. The launch goes out. Customers respond with "this is great but it does not solve the problem we asked you to solve." The feature works; it just was not what customers expected.

Root cause. Positioning unclear. The customer expected something different from what shipped because the spec, the comms, or both implied a different scope.

Fix. Re-position. Re-write the comms to match what the feature actually does. Acknowledge the gap to customers who feel misled. Plan a follow-up that addresses the original ask.

Prevention. The positioning canvas plus anti-positioning section forces explicit definition of what the feature is and is not. Review the canvas with sales and customer success before launch; their pushback often catches the positioning gap.

See: positioning-canvas.md.

---

12. It worked but nobody knew about it internally

Symptom. The metric moved. Customer adoption was strong. The launch was a success. Six weeks later, sales is not pitching the feature, customer success is not using it as a save argument, and the executive team has forgotten about it.

Root cause. No sustained internal awareness. The launch hit; the team moved to the next thing; internal momentum did not carry.

Fix. Re-brief internal stakeholders at the four-week checkpoint. Share the metrics. Highlight customer use cases. Make the feature part of the next sales kickoff or company all-hands.

Prevention. Internal launch is not a one-time event. After the four-week measurement, revisit. Share the win story. Update the sales playbook. The launch is not over until the feature is part of the team's vocabulary for at least a quarter.

See: internal-alignment-checklist.md.

---

The pattern across all twelve

Most launch failures share one root cause. The team treated the launch as a single event (the day the feature ships) rather than a multi-week discipline (the period when the feature lands).

The shipping vs releasing vs launching distinction names this. Shipping is a moment; releasing is a moment; launching is a discipline that spans the four to eight weeks before and after. Teams that invest in the discipline catch most failure modes early; teams that treat the launch as a moment hit failure modes late or never.

The fix at the meta level. Pre-launch checklist. Launch-day standup. Post-launch measurement at four-week and eight-week checkpoints. The discipline is the only thing that produces consistent launches across many features.

---

Supporting file: references/customer-comms-playbook.md

Customer comms playbook

Channels, decision factors, calendar template, comms misfire failure mode.

The principle. Every channel has a different reach, latency, and cost. Pick the channels that match the feature's audience and tier; sequence them so the highest-touch channels fire first and the highest-reach channels fire last.

---

Channel-by-channel

In-app

Reach. Active users only. Highest engagement among the people who already use the product.

Latency. Real-time once the rollout reaches them.

Right for. Product-internal features. Tooltips, banners, modals. Discoverability prompts.

Decision factors. Are users active enough to encounter the in-app surface within the launch window? If your DAU is 10 percent of MAU, in-app reaches one in ten users in the first week.

Anti-pattern. Modal interrupting the user mid-task. Use banners, tooltips, or empty-state prompts that the user notices but does not have to dismiss.

Email (transactional or campaign)

Reach. All users who opted in. Higher than in-app for inactive users.

Latency. Hours from send to read. Delays for users who batch-read email.

Right for. Material changes that affect existing workflows. Pricing changes. Breaking changes that need user awareness.

Decision factors. Is the change material enough to justify an email? If the user can discover the feature on their next visit, email may be unnecessary. If the change affects their billing or their workflow, email is the right channel.

Anti-pattern. Sending email for every release. Customers unsubscribe; the channel decays.

Blog post

Reach. External traffic plus existing customers who read the blog. Best for SEO, lead gen, narrative.

Latency. Hours to days from publish to traffic peak.

Right for. Tier 1 launches with external story. Competitive positioning announcements. Major narrative shifts.

Decision factors. Is there a story worth telling beyond "we shipped a feature"? Blog posts about feature ships read as marketing churn; blog posts about category narrative shifts read as substantive.

Release notes

Reach. Customers who actively check release notes. Discoverable later via search.

Latency. Real-time on publish; the long-tail value comes from search-engine and customer-search traffic over the following months.

Right for. Every Tier 2 and above. The canonical reference customers find later when they encounter the feature in the wild.

Decision factors. Always. Release notes are the cheapest comms channel; the cost of writing one is small; the long-tail value is real.

Social (LinkedIn, X, Bluesky)

Reach. Beyond existing customers. Mostly other PMs, engineers, prospects.

Latency. Hours to days from post to engagement.

Right for. Launches with external narrative or competitive angle. Founder-led marketing.

Decision factors. Does the launch have a story that a non-customer would care about? If no, social is filler. If yes, social can drive net-new pipeline.

Webinar or customer call

Reach. Limited to attendees, but high engagement per attendee.

Latency. Days to weeks from announcement to event.

Right for. Tier 1 launches with material customer impact. Enterprise customers who need depth.

Decision factors. Does the feature need explanation that a blog post or email cannot deliver? If yes, webinar. If the feature is self-evident, skip.

Sales-led briefing

Reach. Top accounts only. Highest-touch channel.

Latency. Days from scheduling to delivery.

Right for. Launches affecting pricing, contracts, or strategic positioning. Top accounts hear about the feature from their account executive before they hear from any other channel.

Decision factors. Does the launch affect the top 10 to 20 accounts in a way that requires a personal conversation? If yes, sales-led briefing is non-negotiable.

---

The comms calendar

A single document with all channels and dates. Distributed in the internal launch brief.

The calendar names every channel, every date, every owner. Gaps in the calendar signal channels that are not covered (intentionally or accidentally).

---

Sequencing principles

Highest-touch first. Sales-led briefing for top accounts before public comms. The top customer hearing about a feature from their account manager before they hear from a blog post is a trust win; the inverse is a trust loss.

Internal before external. Sales training before sales is asked customer questions. Support training before customers ask support questions. Internal launch brief before any customer-facing channel fires.

Health-check gates on auto-fire channels. In-app banners, scheduled emails, scheduled blog posts should be gated on a rollout health check. Manual triggers preferred for any channel that would be embarrassing if the rollout is paused.

Lower-reach to higher-reach. Release notes and in-app first; email second; blog and social last. The lower-reach channels catch initial issues; the higher-reach channels amplify after stability.

---

The comms misfire failure

The most common comms execution failure.

The setup. The blog post is scheduled to auto-publish at the announced launch time. The rollout starts at 9 AM. At 11 AM, an issue is detected and the rollout is paused at 25 percent. The blog post auto-publishes at noon as scheduled.

The result. Customers click through to the new feature page. 75 percent of them do not see the feature (the rollout has not reached them). They report bugs that are actually rollout-paused state. The launch story breaks.

The fix. Make external comms manually triggered, gated on a rollout health check. The comms timing in the calendar is the planned timing; the actual fire is conditional on the rollout passing the health check.

The pattern. Auto-fire is convenient but brittle. Manual triggers are slightly more work but catch issues that auto-fire cannot.

---

Channel-mix rules of thumb by feature type

The pattern. The channel mix is not "all channels" by default. It is the subset of channels that match the audience and the tier. Skipping the wrong channel hurts; firing on the wrong channel also hurts.

---

Supporting file: references/internal-alignment-checklist.md

Internal alignment checklist

Stakeholders, brief structure, distribution timing. The launch brief is the single document that aligns everyone before customer comms go out.

The principle. Internal alignment fails silently. The team does not know they are misaligned until a customer asks sales a question that sales cannot answer, or a customer escalates an issue support did not know existed. The launch brief catches misalignment before customers do.

---

Stakeholders by org type

Small startup (under 50 employees)

• Engineering lead. Capacity for fixes, support escalation handling.
• Sales lead (if B2B). Pipeline impact, deal coaching.
• Customer success / support lead. Often the same person at this size.
• Marketing or content lead (if exists). Comms execution.
• Executive sponsor. Usually CEO at this size.

The brief is shorter at this size; the meeting is faster; but the discipline still matters. The "small team did not need a launch brief" assumption is a frequent source of small-launch failures.

Mid-size (50 to 500 employees)

• Engineering leadership.
• Sales leadership and at least one regional sales lead.
• Customer success leadership.
• Marketing leadership.
• Support leadership.
• Executive sponsor (VP-level for most launches; C-level for Tier 1).

The brief is longer. The launch meeting includes a Q&A. Decision log captures the questions and answers; the log is part of the brief.

Enterprise (500+ employees)

• Engineering leadership.
• Sales leadership across regions and segments.
• Customer success leadership.
• Marketing leadership including PMM (product marketing manager).
• Support leadership.
• Legal, security, and compliance (for features touching pricing, data, or regulated workflows).
• Executive sponsor (C-level for Tier 1).

At this size, the launch brief is a formal document with sections owned by different functions. PMM often co-owns the brief with the PM.

---

The launch brief

A single document distributed two to four weeks before Tier 1 launch, one week before Tier 2 launch.

Section 1: one-page summary

Top of the brief. The PM writes it. The reader should be able to answer "what is launching, when, who is it for, why now" after one minute.

Section 2: positioning

The positioning canvas (from the positioning-canvas reference) embedded directly. Target user, problem, current alternative, user-visible promise, proof points, anti-positioning.

Section 3: launch calendar

Every channel and every date. In-app banner activation, email send, blog post publish, social post times, sales briefing, support training, customer success outreach windows. Owners named for each.

Section 4: what each function needs to do differently

The most important section for the readers. Each function gets a paragraph.

• Sales. Battlecard link. Demo recording link. Top objections and answers. Deals to revisit. Training session date.
• Customer success. Top accounts to brief. Talking points for the briefing. Escalation contact during launch week.
• Support. Training session date. FAQ link. Escalation path. Ticket tagging convention.
• Marketing. Channel list, dates, message variants by channel.
• Engineering. On-call coverage during launch. Rollback authority. Health-check dashboard link.

If a function does not have a paragraph, the launch was not designed with that function in mind; revisit before distributing.

Section 5: FAQ

The questions that have already come up internally, with answers. The FAQ updates daily during the first week of distribution as new questions surface.

Section 6: decision log

Choices already made. Includes the rationale for non-obvious decisions. Future questions ("why did we pick that rollout strategy?") get answered by reading the log instead of re-litigating the decision.

---

Distribution timing

The pattern. Launch brief lands first. Sales briefing, support training, customer success outreach all happen after the brief lands and before the public comms fire.

---

The pre-launch meeting

For Tier 1 launches, hold a 30-minute pre-launch meeting one week before launch.

Agenda.

1. PM walks through the positioning canvas and the calendar (10 minutes).
2. Each function lead confirms their readiness (10 minutes).
3. Open Q&A captured in the decision log (10 minutes).

The meeting is not for re-litigating the launch. It is for confirming readiness and catching last-minute gaps. If functions are not ready, the launch is delayed. The PM has authority to delay; the executive sponsor confirms.

---

The launch-day standup

For Tier 1 launches, hold a brief launch-day standup at the start of launch day. Five to ten minutes.

Agenda.

1. Confirm rollout health check is green.
2. Confirm comms are gated on the health check (the social post will not auto-fire if the rollout is paused).
3. Confirm support is staffed for the launch window.
4. Confirm escalation contacts are reachable.
5. Open the post-launch monitoring channel.

The launch-day standup catches "the marketing person took the day off and the social post is set to auto-fire" the morning of launch instead of in the moment.

---

Common internal alignment failures

• Launching without sales knowing. Sales finds out from a customer. Trust erodes for the next launch. Fix: launch brief plus sales-specific briefing one to two weeks before public comms.
• Sales briefing is the launch brief. Sales reads a 12-page document. Their actual takeaway is partial. Fix: separate one-pager for sales (the battlecard) plus the full brief for reference.
• Support is trained the day of launch. Support cannot internalize a new feature in one morning. Fix: train support one week before customer-facing launch.
• Customer success outreach happens after public comms. Top accounts hear about the feature from the email blast like everyone else. Fix: customer success briefs top accounts one to three days before public comms.
• Executive sponsor is surprised on launch day. The executive read the brief but did not internalize it; on launch day they see press coverage and ask the team questions that should have been answered in the brief. Fix: brief executives in person, not just via document.

---

When the brief reveals misalignment

The brief is the artifact that surfaces misalignment. Common signals.

• The positioning canvas does not match how sales describes the customer profile. Misalignment between PM and sales on who the customer is.
• The launch calendar does not give sales enough time. Misalignment on what enablement requires.
• The FAQ has questions nobody can answer. Misalignment on what the feature actually does.

The pattern. Surface misalignment before launch; resolve before launch. The brief is the tool that forces the conversation. A team that drafts the brief carefully and finds it easy to write probably has no misalignment. A team that struggles to write the brief has misalignment that the brief is now revealing; resolve it before customer comms go out.

---

Supporting file: references/launch-tier-decision.md

Launch tier decision

Tier 1 / Tier 2 / Tier 3 decision framework. Worked examples. Anti-patterns on both sides.

The principle. Match launch effort to feature scope. Treating every release as Tier 1 produces comms fatigue; treating every release as Tier 3 produces unlaunched features.

---

The tiers

Tier 1: full launch

Scope. Net-new product, major feature reshaping the product narrative, pricing change, breaking change.

Effort. Full playbook. Positioning, all comms channels, sales enablement (B2B), customer success briefing, dedicated post-launch measurement, executive announcement. Two to four weeks of pre-launch work; four to eight weeks of post-launch monitoring.

Examples.

• A new product surface (Slack adds Canvas; Figma adds FigJam; Notion adds Sites).
• A pricing model change (per-seat to consumption; introducing a new tier).
• A foundational replatforming with user-visible impact (a new UI architecture, a new permissions model).
• A flagship competitive feature (the thing the sales team has been asking for, the thing the analyst report compared you on).

Tier 2: focused launch

Scope. Meaningful improvement that materially affects user value or competitive positioning.

Effort. Subset of the playbook. In-app comms, blog post or detailed release note, support readiness, rollout strategy, post-launch measurement. One to two weeks of pre-launch work; two to four weeks of post-launch monitoring.

Examples.

• A new export format that customers have been requesting.
• A redesigned core flow (e.g., a new onboarding experience).
• An integration with a major third-party (Slack notifications, Salesforce sync).
• A meaningful performance improvement (page loads twice as fast on a flagship surface).

Tier 3: release note

Scope. Incremental improvement, bug fix made positive, polish.

Effort. Minimal. Changelog entry, release note, light monitoring. Hours of pre-launch work; passive monitoring post-launch.

Examples.

• A new keyboard shortcut.
• A small UI polish (better empty states, refined typography).
• A minor configuration option (toggle to disable a non-default behavior).
• A bug fix that improves reliability for a small cohort.

---

Decision framework

When unsure between two tiers, ask three questions.

1. Will sales need to talk about this? If yes, at least Tier 2. If sales is selling against this gap today, Tier 1.
2. Will customers be confused if we do not tell them? If yes, at least Tier 2.
3. Will the metric this is meant to move show up in board reporting? If yes, Tier 1. If yes but only at the team level, Tier 2.

If all three answers are no, the feature is Tier 3.

---

Worked examples

Example 1: a new export-to-PDF capability

A B2B SaaS product adds export-to-PDF to its reporting feature.

• Will sales talk about this? Yes; this has been a top sales objection.
• Will customers be confused without comms? No; the feature is discoverable in the existing UI.
• Will the metric move at board level? Probably not directly; might unblock some deals.

Tier 2. Sales enablement (battlecard plus a one-paragraph deal-coaching note). Blog post. Release note. In-app banner on the reporting page. Light monitoring.

Example 2: a new pricing tier with consumption-based billing

A SaaS company adds a usage-based tier alongside its existing per-seat plans.

• Will sales talk about this? Yes; pricing changes always involve sales.
• Will customers be confused without comms? Yes; existing customers will wonder if they should switch.
• Will the metric move at board level? Yes; revenue mix and ARR composition are board-level.

Tier 1. Full positioning canvas. Internal launch brief 4 weeks ahead. Sales enablement including pricing change documentation. Email to existing customers explaining what is and is not changing for them. Blog post. Webinar for top accounts. Phased rollout starting with new customers, then existing customer opt-in.

Example 3: a keyboard shortcut for a power-user action

A consumer app adds Cmd+K for quick navigation.

• Will sales talk about this? No; consumer product, no sales motion.
• Will customers be confused without comms? No; the feature is purely additive and discoverable.
• Will the metric move at board level? No; small UX improvement.

Tier 3. Changelog entry. Maybe a tweet from the product team. No further work.

Example 4: an enterprise SSO integration

A B2B SaaS adds SAML SSO support.

• Will sales talk about this? Yes; SSO is a hard requirement for many enterprise deals.
• Will customers be confused without comms? Existing self-service customers no; enterprise prospects yes.
• Will the metric move at board level? Indirectly; SSO unblocks enterprise deals worth real ARR.

Tier 1 if SSO unlocks the enterprise segment for the first time, otherwise Tier 2. Sales enablement is the highest-impact piece (the deal-coaching note for previously SSO-blocked accounts). Customer success outreach to top enterprise prospects. Blog post focused on the security and IT audience. Quiet rollout for self-service customers (changelog only).

---

Anti-pattern: everything is Tier 1

Symptom. Every release gets a blog post, an email, a sales briefing. Customers tune out the announcement firehose. Real Tier 1 launches lose signal in the noise. Sales reps stop reading the briefings because they assume every one is minor.

Fix. Be honest about which features are major. If you ship five "major" launches per quarter, three of them are Tier 2 or Tier 3 in disguise. The Tier 1 budget should be one to three per quarter for most companies.

---

Anti-pattern: everything is Tier 3

Symptom. Features ship without comms. Sales does not know what is new. Customers are surprised when they discover a feature six months after launch. Metrics do not move because users do not know the feature exists.

Fix. Tier honestly. Most B2B SaaS releases are Tier 2; defaulting them to Tier 3 leaves value on the table. The minimum Tier 2 effort (release note plus in-app banner plus support FAQ) is small; the marginal value capture is large.

---

How tier affects the rest of the playbook

The pattern. Tier 1 is the full playbook. Tier 2 is the playbook compressed. Tier 3 is the changelog plus passive monitoring. Each section's depth scales with tier.

---

Supporting file: references/monitoring-readiness-checklist.md

Monitoring readiness checklist

Metrics dimensions, alert thresholds, pre-defined rollback triggers. The "no rollback trigger" failure mode.

The principle. Monitoring catches launch issues before they compound into customer pain. The discipline is defining what to watch and what to do BEFORE launch, so the team executes rather than debates during the launch window.

---

What to monitor

Six dimensions for most launches.

1. Error rates

• Overall error rate. The baseline. Has the deploy increased errors across the application.
• Feature-specific error rate. Errors in code paths the new feature touches. Often the first signal of a feature-specific bug.
• Per-cohort error rate. Errors broken down by user segment, plan, region. Catches cohort-specific bugs.

2. Latency

• Overall P50, P95, P99. Has the deploy slowed the application.
• Feature-specific latency. New code paths often have unoptimized queries; latency tracking catches them.
• Database query latency. New features often add new queries; database load can spike.

3. Feature usage rate

• Reach. Of users in the rollout cohort, how many actually trigger the feature within their first session post-rollout.
• Frequency. Of users who used the feature once, how many used it again.
• The expected vs actual gap. Pre-launch projections vs actual numbers. Large gaps in either direction need investigation.

4. Funnel completion

• End-to-end completion of the workflow the feature is part of. Did users complete the flow at the same rate as pre-launch.
• Step-by-step drop-off. Where in the flow are users abandoning. Compare pre-launch to post-launch step-by-step.
• Per-cohort completion. Cohort-specific drop-off can hide in aggregate metrics.

5. Support ticket volume

• Overall ticket volume. Has the team's support load increased.
• Feature-tagged tickets. Tickets where the customer mentions the feature.
• Ticket sentiment. Frustrated tickets vs informational tickets vs positive tickets.

6. Customer satisfaction signals

• NPS comments. Mentions of the feature in NPS responses.
• Feedback widget. In-product feedback explicitly about the feature.
• Social mentions. Twitter or LinkedIn posts about the launch.

---

Alert thresholds

For each dimension, pre-defined thresholds that fire alerts.

Error rates

• Yellow. Overall error rate up by more than 25 percent vs pre-launch baseline. Investigate without escalation.
• Orange. Overall error rate up by more than 50 percent vs baseline. Escalate to PM and engineering on-call.
• Red. Overall error rate above 1 percent absolute. Trigger rollback.

Latency

• Yellow. P95 up by 25 percent vs baseline. Investigate.
• Orange. P95 up by 50 percent. Escalate.
• Red. P95 doubled or worse. Trigger rollback if sustained for 10 minutes.

Feature usage rate

• Yellow. Below 50 percent of pre-launch projection. Investigate (probably comms or discovery problem).
• Orange. Below 25 percent of projection. Escalate; the launch may not be reaching users.
• Red. Near zero usage. Likely an instrumentation bug; the feature is not firing or the metric is not capturing.

Funnel completion

• Yellow. Down by 10 percent from pre-launch baseline. Investigate.
• Orange. Down by 25 percent. Escalate; the feature may be breaking the flow.
• Red. Down by 50 percent for any cohort. Trigger rollback for that cohort or pause the rollout.

Support volume

• Yellow. Feature-tagged tickets exceed 10 in the first hour. Investigate.
• Orange. Feature-tagged tickets exceed 50 in the first hour. Escalate.
• Red. Feature-tagged tickets exceed 100 in the first hour. Trigger rollback or pause; the feature has a real problem.

The numbers above are illustrative. Calibrate to the team's actual support volume and the feature's expected reach.

---

Pre-defined rollback triggers

A rollback trigger is a rule that fires automatically. The team executes the rollback without re-litigating whether to.

Examples

For a feature touching the checkout flow.

• Error rate above 1 percent sustained for 5 minutes.
• Funnel completion drops below 50 percent of pre-launch baseline.
• Stripe API errors increase by 100 percent.

For a new internal tool.

• Error rate above 5 percent sustained for 5 minutes (higher tolerance because internal users provide more context).
• Adoption near zero after 24 hours (instrumentation bug or feature not deployed).

For a pricing change.

• Subscription cancellation rate increase by 50 percent in the first 48 hours.
• Customer service contact rate about pricing increase by 200 percent.
• Revenue forecast adjustment indicates a 10 percent quarterly miss.

The pattern. Each rollback trigger names a specific metric, a specific threshold, and a specific time window. The team rehearses what to do when the trigger fires.

What rollback means

Rollback can be one of several things.

• Full rollback. Flag off, code reverted, user-visible state returns to pre-launch.
• Pause at current rollout percentage. Flag stays on for users who already have it; no new users get the feature.
• Cohort-specific rollback. Flag off for the cohort showing issues; flag on for cohorts that look healthy.
• Fix-forward. A small fix is deployed; rollout continues at the previous percentage. Risky; only use when the fix is high-confidence.

The team should know which rollback path applies to which trigger before launch.

---

The on-call rotation

For Tier 1 launches, the on-call rotation should include.

• Primary engineering on-call. Standard rotation. Receives alerts, executes rollbacks.
• Secondary engineering on-call. Backup if primary is unreachable.
• PM contact. The PM who owns the launch is reachable during the launch window.
• Support escalation contact. The support lead responsible for routing customer issues to the right team.
• Marketing contact. For comms decisions if the rollout pauses.

Reachability hours for Tier 1 launches: 24/7 for the first 48 hours, business hours plus on-call after that.

---

The "no rollback trigger" failure

The pattern.

• Launch goes sideways. Error rate is up; support volume is high; engineering is investigating.
• The team debates whether to roll back. The debate takes an hour.
• During the debate hour, more users encounter the issue. Support tickets pile up. The press notices. Trust erodes.
• The team eventually rolls back, but the recovery is now harder than it would have been one hour earlier.

The fix. Pre-define the rollback triggers. Write them down. Get team agreement before launch. When a trigger fires, execute the rollback. Debate the appropriateness of the trigger after the rollback, not during the incident.

The discipline. The cost of a wrong rollback (the team rolls back when the feature was actually fine) is small (a paused launch and a re-rollout). The cost of a delayed rollback (the team debates while the issue compounds) is large (customer impact, reputation, recovery cost). Bias toward fast rollback.

---

Post-rollback retrospective

After any rollback, hold a retrospective within 48 hours.

Agenda.

1. What was the trigger that fired.
2. What was the actual problem.
3. Was the rollback the right call (almost always yes; even false positives that catch nothing teach the team about the system).
4. What is the path to re-launch (fix the bug, test it, validate the test, schedule a new rollout).
5. What did we learn that updates the next launch's monitoring.

The retrospective is not a blame session. It is an investment in the next launch's monitoring quality.

---

Health check before each rollout step

For gradual percentage rollouts, define a health check that gates each step.

The health check passes when.

• All Yellow thresholds clear for the prior percentage step's full duration.
• No Orange or Red alerts in the prior step.
• Support volume stable.
• Customer feedback (NPS, social) neutral or positive.

The health check fails when any of the above conditions does not hold. The rollout pauses at the current step until the health check passes.

The pattern. The rollout proceeds when the system is healthy; it does not proceed on a schedule. Schedule-driven rollouts that ignore health checks are how launches go sideways.

---

Supporting file: references/positioning-canvas.md

Positioning canvas

The one-page positioning template. Worked examples for B2B SaaS, B2C, and developer features. The vague-target-user failure mode.

The principle. Positioning is the foundation of the launch. Without it, comms drift, sales improvise, and customers come away with a different understanding of the feature than the team intended. Filled out before any comms drafting; reviewed by sales, support, and an executive sponsor before launch.

---

The canvas

One page. Six sections. Filled out by the PM with input from sales, customer success, and design.

1. Target user

Segment. What kind of company or individual.

Role. What is their job title or function.

Jobs-to-be-done. What is the user trying to accomplish in their work or life that this feature serves.

Specificity test. Could a sales rep describe the customer profile in one sentence? Could marketing target ads at this segment? If no to either, the target user is too vague.

2. Problem it solves

The current pain. In the user's words. What is hard, slow, error-prone, or impossible today.

The cost of the pain. Time, money, errors, missed opportunities. Quantified where possible.

Specificity test. Is the problem stated in concrete terms or in abstract language? "Productivity is low" is abstract. "The customer support manager spends 3 hours per day triaging tickets that an automated system could route" is concrete.

3. Current alternative

What users do today without this. The status quo, the workaround, the competing product, the manual process, the spreadsheet.

The status quo is the real competition. A feature that is better than nothing but worse than the user's existing workaround does not get adopted.

4. User-visible promise

One sentence. The promise the user will hear when they encounter the feature.

Specificity test. Can sales repeat it without changing words? Can support repeat it without paraphrasing? If no, it is too long or too abstract.

5. Proof points

Three to five specific capabilities or outcomes. Concrete, not adjectives.

Examples of bad proof points: "fast," "easy," "secure," "intelligent." These are claims, not proof.

Examples of good proof points: "exports a 200-page report in under 5 seconds," "supports 14 languages including right-to-left," "SOC 2 Type II audited by Deloitte 2025."

6. Anti-positioning

What this is NOT. What it does not try to do.

Anti-positioning prevents over-promising. If the feature does not handle enterprise scale, say so. If it does not work offline, say so. If it does not replace the customer's existing tool, say so.

The anti-positioning protects the team from sales reps who hear about the feature and embellish. It protects support from customers who expected something the feature does not do.

---

Worked example 1: B2B SaaS feature

A B2B project management tool ships a new automated routing feature.

The anti-positioning protects the team from sales reps who would otherwise pitch this as "AI customer support."

---

Worked example 2: B2C feature

A consumer note-taking app ships AI-generated summaries.

---

Worked example 3: developer feature

A developer tools company ships a new CLI command.

---

The vague-target-user failure mode

The most common positioning failure. The PM writes "It is for PMs" or "It is for engineers" or "It is for marketers."

Why it fails. Different PMs, engineers, and marketers have different jobs. A B2B PM at a 50-person startup has a different job from a B2C PM at a 5,000-person company. A backend engineer has a different job from a frontend engineer. The vague target prevents sales from filtering, prevents marketing from targeting ads, prevents support from anticipating questions.

The fix. Specificity layers.

• Industry or company type. (B2B SaaS at 50 to 500 customers.)
• Role and function. (Customer support manager, not just "support.")
• Jobs-to-be-done. (Triage incoming tickets, not "improve productivity.")

Three layers of specificity move the target from useless to actionable. If you cannot fill in all three, the team has not yet decided who the feature is for.

---

Reviewing the canvas

Before launch, review the positioning canvas with three audiences.

1. Sales review. Can sales pitch this in 30 seconds? Does the language match how customers ask about the problem?
2. Support review. Can support answer the obvious questions (what does it cost, how do I turn it on, what are the limits) using only the canvas?
3. Executive review. Does the positioning fit the company narrative? Will it confuse customers who are mid-purchase on a different feature?

If any of the three review groups push back, fix the canvas before launch comms drafting begins. Drafting comms on top of weak positioning produces comms that look fine in isolation but contradict each other across channels.

---

Supporting file: references/post-launch-measurement-framework.md

Post-launch measurement framework

Adoption, engagement, outcome, side effects. Time horizons. Tying back to spec hypotheses. The "declared victory on launch spike" failure mode.

The principle. The launch measurement plan answers "did this work." Without it, the team moves on without knowing.

---

Four measurement dimensions

1. Adoption (the reach question)

Did the right users actually use the feature.

Metrics.

• Reach: of users in the rollout cohort, what fraction has tried the feature.
• Time to first use: of users who tried the feature, how long after rollout.
• Distribution by cohort: are the right segments (per the positioning canvas) the ones using the feature.

Signal interpretation.

• High reach plus right cohorts: the launch reached the target audience.
• High reach plus wrong cohorts: the launch reached the wrong audience; positioning or comms missed the target.
• Low reach: comms problem or discovery problem. Investigate which channel users would have learned about the feature from.

2. Engagement (the stickiness question)

Did users who tried the feature come back.

Metrics.

• Retention: of users who tried the feature once, what fraction used it again within 7, 14, 30 days.
• Frequency: how many times per week did adopters use the feature.
• Depth: did adopters use the full feature or only the first step.

Signal interpretation.

• High first-time use plus high retention: the feature is delivering value.
• High first-time use plus low retention: the feature failed to deliver on the first-use experience. Usability or value-prop problem.
• Low first-time use plus high retention among the few who tried: the feature is valuable to a niche; reach the niche better, or accept that it serves a smaller audience.

3. Outcome (the effect question)

Did the metric the spec said this would move actually move.

Metrics.

• The primary metric from the spec. Usually a business metric (revenue, retention, support deflection, conversion rate).
• The lift relative to a pre-launch baseline.
• The statistical significance of the lift, if a controlled comparison is available.

Signal interpretation.

• Metric moved as predicted: the feature delivered the value the team committed to.
• Metric moved less than predicted: partial success; the feature works but did not have the size of impact the team expected. Investigate why (smaller cohort than expected, smaller per-user impact, or simply optimistic projection).
• Metric did not move: the launch did not deliver the promised value. Investigate before declaring failure (could be measurement timeline, isolation issues, or the feature genuinely failing).

4. Side effects (the safety question)

Did any other metric move that was not supposed to.

Metrics.

• Cohorts adjacent to the target: did the feature affect users it was not designed for.
• Adjacent metrics: did related metrics move (positively or negatively).
• Support volume on adjacent topics: did the feature confuse customers about other parts of the product.

Signal interpretation.

• No side effects: clean launch.
• Positive side effects: the feature delivered value beyond the target. Document for the next iteration.
• Negative side effects: the feature broke something else. Triage urgently; this is a launch quality issue regardless of whether the primary metric moved.

---

Time horizons

Different signals stabilize at different times.

The rule. Do not declare success or failure on the outcome metric before week 4. The launch-week spike is unrepresentative; the metric needs time to stabilize at its post-launch level.

---

Tying back to spec hypotheses

The spec (per pm-spec-writing) should have stated explicit hypotheses. The launch measurement plan validates each.

Example hypotheses from a hypothetical spec.

• "We expect this feature to be used by 40 percent of paid users within 30 days of rollout." (Adoption hypothesis.)
• "Of users who try the feature, we expect 60 percent to use it again within 7 days." (Engagement hypothesis.)
• "We expect this feature to reduce support tickets in the X category by 25 percent." (Outcome hypothesis.)
• "We do not expect this feature to affect billing-related support volume." (Side-effect hypothesis.)

The measurement plan validates each.

The measurement plan is written before launch. The decision rules are pre-committed; the team does not move the goalposts after seeing the data.

---

The "declared victory on launch spike" failure

The pattern.

• Week 1: adoption is high. The team announced the feature; users tried it; the metric is up.
• Week 2: adoption flat. The launch announcement spike has passed; the new users have tried the feature.
• Week 3: adoption declining. Users who tried the feature once are not coming back.
• Week 4: adoption near pre-launch baseline. The metric has reverted.
• The team had already declared the launch a success in week 1 and moved on.

The cost. The team's roadmap is now built on a launch that did not actually work. The next quarter's plan assumes the metric is at the elevated level; when it does not stay there, the plan does not deliver.

The fix. Declare success or failure based on the stable post-launch trend, not the launch-week spike. The minimum measurement window is four weeks; for retention or LTV signals, eight to twelve weeks.

The discipline. The four-week checkpoint is on the calendar before launch. The team holds itself accountable to revisit; the executive sponsor holds the team accountable to revisit. Launches that are reported as successful in week 1 and never revisited are silent failures.

---

The "no measurement plan" failure

The pattern.

• Feature ships.
• Team moves on to the next feature.
• Six months later, someone asks "did feature X work?" Nobody knows.
• The feature becomes maintenance debt; the team cannot decide whether to invest in iteration.

The cost. The team accumulates features whose value is unknown. Roadmap decisions get harder because the historical track record is opaque. Engineering investment is wasted on features that did not work; the team does not learn from them because they did not measure.

The fix. Every launch has a measurement plan. The plan is short (one page); it names the four dimensions, the metrics, the time horizons, and the decision rules. The plan is reviewed at week 4 and again at week 8 or 12 depending on the signal.

The discipline. The measurement plan is part of the launch brief. A launch without a measurement plan does not get scheduled.

---

When the metric did not move

If the outcome metric did not move at week 4, the next investigation.

1. Is adoption strong? If adoption is below target, the launch may be a comms or discovery problem, not a feature problem.
2. Is engagement strong? If engagement is below target among adopters, the value is not landing for the right reasons.
3. Is the metric correctly attributed? Did another concurrent change interfere with the measurement.
4. Did the side-effects analysis catch a counterweight? A negative side effect could be cancelling the positive primary effect.

Each diagnosis maps to a different fix.

• Adoption problem: more comms, repeat comms, deeper sales reactivation, in-app discovery surface.
• Engagement problem: usability or value-prop iteration. The feature may need redesign.
• Attribution problem: re-run measurement after the concurrent change has been accounted for.
• Side-effect counterweight: fix the side effect, then re-measure the primary.

---

When the launch worked but quietly

Sometimes the launch works at every level (adoption strong, engagement strong, outcome metric moved) but the team does not feel like it succeeded. Usually the gap is internal awareness.

Signs.

• Sales is not using the feature in pitches.
• Customer success is not mentioning it in customer calls.
• The product narrative has not updated to include the feature.

The fix. Internal launch effectiveness is part of the launch playbook. Even successful feature launches need ongoing internal advocacy.

The discipline. After the four-week checkpoint, briefly re-engage internal stakeholders. Share the metrics. Highlight customer use cases. The internal awareness is not a one-time event at launch; it is sustained for a quarter or more.

---

Supporting file: references/rollout-strategy-patterns.md

Rollout strategy patterns

Four rollout patterns matched to feature types. Decision framework: blast radius times confidence times external commitments.

The principle. The rollout is the mechanism by which users actually encounter the feature. The pattern depends on what would happen if the feature breaks, how confident the team is in correctness, and whether external comms are tied to a specific date.

---

Pattern 1: all-at-once (big bang)

Mechanism. Zero to 100 percent of eligible users in a single deploy. No gradual rollout.

Right for.

• Marketing-coordinated launches where the announcement IS the rollout. The press is briefed for a specific date; the feature has to be live for everyone at that moment.
• Low-blast-radius features. The feature affects a small portion of the user experience; even if it breaks, the customer impact is limited.
• High-confidence releases. The feature has been tested thoroughly, used internally, validated with a beta cohort.

Risky for.

• High-traffic critical paths (checkout, login, primary navigation). Any bug affects a meaningful share of users immediately.
• Features without a clean rollback path. If the deploy breaks, recovery is hard.
• Features with cohort-specific risk (works for free users, breaks for enterprise). The cohort variance is not exposed before launch.

Operational shape. One deploy. Health check after deploy. Rollback path ready but rarely used. Monitoring tightens for 24 hours post-deploy.

---

Pattern 2: gradual percentage rollout

Mechanism. 1 percent, then 10 percent, then 25 percent, then 50 percent, then 100 percent over hours or days. Health checks at each step.

Right for.

• Most feature launches. The default unless there is a reason to deviate.
• Features touching critical paths. The 1 percent rollout catches errors before they affect a meaningful share of users.
• Features with uncertain interaction effects. Other systems may behave differently when the feature is on; gradual rollout surfaces interactions safely.

Risky for.

• Marketing-coordinated launches with a fixed announcement date. The press writes about a feature that 90 percent of users do not have yet.

Operational shape.

• 1 percent to 10 percent: 4 to 24 hours. Watch error rates, latency, feature usage rate.
• 10 percent to 25 percent: 24 to 48 hours. Watch the same metrics plus support volume.
• 25 percent to 50 percent: 48 to 72 hours. Watch all metrics plus customer feedback.
• 50 percent to 100 percent: 24 to 72 hours.

The pace is configurable. Faster for low-risk features; slower for high-risk.

The rollback at any step. If a metric breaches a threshold, the rollout pauses. If the issue is severe, rollback to 0 percent. If the issue is minor, fix forward at the current percentage.

---

Pattern 3: flag-gated cohort rollout

Mechanism. Targeted to specific user segments. Free tier first, then paid. Small accounts first, then enterprise. Specific named accounts first, then broad rollout.

Right for.

• Features with cohort-specific risk profiles. A pricing change affects existing customers differently from new customers; roll out to new customers first.
• Features that need cohort-specific configuration. Enterprise customers may need a setup step; roll out to them after they are configured.
• Features where the cost of a bad rollout varies by cohort. Bug in front of a Fortune 500 prospect costs more than a bug in front of a free-tier user.

Operational shape.

• The flag service controls which cohorts have the feature enabled.
• Cohorts are defined explicitly: account tier, account ID list, region, signup date range.
• Each cohort gets its own monitoring slice. Issues affecting one cohort do not pause the rollout to other cohorts.

Risky for.

• Features that interact across cohorts. If enterprise customers can see what free-tier customers create, a partial cohort rollout exposes a feature inconsistency that breaks workflows.

---

Pattern 4: phased launch (multi-week)

Mechanism. Launch to a subset of users, regions, or customers; gather feedback; iterate; expand. Multi-week timeline.

Right for.

• Tier 1 launches with high uncertainty about user reception. Pricing changes often launch this way.
• Major UX redesigns. The team needs to learn what users do with the new design before broader rollout.
• Features that depend on user behavior change. The team needs to see whether users adopt before declaring readiness.

Operational shape.

• Phase 1: limited rollout (5 to 10 percent of eligible users). 1 to 2 weeks. Heavy feedback collection.
• Phase 2: iteration based on phase 1 feedback. Could be days; could be weeks.
• Phase 3: expanded rollout (25 to 50 percent). 1 to 2 weeks.
• Phase 4: general availability.

The total timeline is 4 to 8 weeks for a typical phased launch. Longer for major UX changes; shorter for feature additions.

Risky for.

• Features that need to be all-on for users to encounter them naturally. A change to the homepage hero needs to be either visible or not; phased rollout creates inconsistent experiences across users.

---

The decision framework

Three factors. Pick the rollout that matches.

Factor 1: blast radius

What happens if the feature breaks for a meaningful share of users?

• Low. Optional new tool that users opt into. Bug affects only users who tried the new tool.
• Medium. New surface in an existing flow. Bug affects users mid-flow but not users on other paths.
• High. Critical path change. Bug affects most active users immediately.

Factor 2: confidence in correctness

How confident is the team that the feature works.

• Low. First time the team has built this kind of feature. Edge cases unknown.
• Medium. The team has built similar features before. Most edge cases anticipated.
• High. Iterative refinement of an existing feature. Behavior well-understood.

Factor 3: external commitments

Is the launch date tied to external press, partner coordination, or a public commitment.

• None. Internal team knows the rough timeline; no external coordination.
• Soft. Marketing has scheduled comms but the date can shift by a few days.
• Hard. Press is briefed for a specific day. Partner is coordinating launches. The date is fixed.

The decision matrix

The defaults. Most launches use gradual percentage rollout. The other patterns are for specific situations.

---

Cohort-specific rollout sequencing

When using flag-gated cohort rollout, the sequence matters.

Internal users first. Eat your own dog food. Catch the obvious issues before any external user sees them.

Free or trial users next. Lower-stakes; if the feature has issues, the cost of a bad experience is lower than for paying customers.

Self-service paid users. Customers who use the product without a sales rep. They will encounter the feature naturally; their feedback is high-quality.

Top accounts last (with sales-led briefing first). Top accounts hear about the feature from their account executive before encountering it. By the time they have access, the feature is stable.

Reverse the sequence in specific cases.

• A feature designed specifically for enterprise customers should roll out to those customers first; the feedback is the design feedback.
• A feature gated by configuration that only enterprise customers complete should roll out to them first; otherwise the feature is invisible to the cohort that can use it.

---

What "rollback trigger" means

A pre-defined rule that determines when the team rolls back without further debate.

Examples.

• Error rate above 1 percent sustained for 5 minutes.
• Latency above the pre-launch P95 by 50 percent for 10 minutes.
• Funnel completion drops below 50 percent of pre-launch baseline for any cohort.
• Support tickets mentioning the feature exceed 50 in the first hour.

The trigger fires automatically; the team executes the rollback without re-litigating whether to do it.

The "no rollback trigger" failure. Launch goes sideways. The team debates whether to roll back for an hour while the issue compounds. Pre-defined triggers remove the debate.

The discipline. Define the trigger before launch. Write it down. Rehearse the rollback. Make the trigger automatic where possible (alerting plus on-call paging); make the rollback execution one command, not a multi-step process.

---

Supporting file: references/sales-enablement-template.md

Sales enablement template

Battlecard, demo script, deal coaching, training session structure. For B2B; skip for B2C and PLG.

The principle. Sales reps cannot pitch a feature they were briefed on yesterday. Enablement is the structured way to give sales the language and the mechanics they need to talk about the feature accurately and quickly.

---

When to skip this section

For B2C products and PLG products without a sales motion, this section does not apply. The user is the buyer; there is no rep in the middle. Skip ahead to the support readiness checklist.

For B2B products, this section is non-negotiable for Tier 1 launches and most Tier 2 launches.

---

The battlecard

One page. Sales can read it in two minutes and pitch the feature in five.

Section 1: positioning summary

Two to three sentences. The user-visible promise plus the target customer profile plus the differentiator vs the status quo. Pulled directly from the positioning canvas.

Section 2: target customer profile

The specifics sales needs to qualify. Industry, company size, role of the buyer, role of the user (often different), use case, current pain.

Section 3: top objections and answers

Three to five expected objections with the answer for each. The answers are written, not improvised; reps should be able to quote them back.

Example.

Section 4: proof points

The same proof points from the positioning canvas. Three to five concrete capabilities or outcomes.

Section 5: deal coaching

Specific guidance on how this affects deals.

• Deals to revisit. Customers in the pipeline who were blocked by the gap this feature now closes. Names where appropriate.
• Deals it complicates. Customers on the existing pricing or feature set who may need migration support. Names where appropriate.
• Common pricing questions. What customers ask about cost; the answers reps should give.

Section 6: where to learn more

Links to the demo recording, the full launch brief, the FAQ, the support documentation, and the PM contact for sales questions.

---

The demo script

A repeatable demo the rep can run with a customer.

Structure

Open (1 minute). State the customer's pain in their language. Reference what they told the rep in discovery (use a generic placeholder if the rep is in a first-call demo).

Show the problem (2 minutes). Demonstrate the status quo workflow that the feature replaces. The rep walks through the manual process, naming the friction points.

Show the feature (5 minutes). Walk through the feature solving the same workflow. Highlight the proof points. Pause at the moments where the customer would feel the difference.

Show the safety net (2 minutes). Walk through the failure mode. What happens when the feature does not work perfectly. The customer needs to trust the safety net before they trust the feature.

Close (1 minute). Summarize the value. Ask the customer what they think. Surface objections.

Total. 11 minutes. Demos longer than 15 minutes lose attention; demos shorter than 7 minutes feel rushed.

The recorded demo

For reps who join after the launch or who want a refresher, a recorded version of the demo. Same structure. Annotated with timestamps. Stored where reps can find it (sales enablement platform, shared drive, internal wiki).

The recorded demo is not a substitute for the live demo with a customer. It is reference material for the rep.

---

Deal coaching guide

Beyond the battlecard's deal-coaching section, a longer-form guide for the top sales scenarios.

Scenario 1: deal blocked by missing capability

The rep has a customer in the pipeline who was blocked by a feature gap that this launch closes. Coaching.

• Confirm the gap was the actual blocker via discovery questions before pitching the new feature.
• Reference the customer's specific pain in the demo.
• If the deal stalled with a competitor, address the competitor head-on with the differentiator section of the battlecard.
• Time the outreach. Reach out one to three days after public launch comms; the customer will already be aware of the announcement.

Scenario 2: existing customer expansion

The rep has an existing customer using a smaller plan; this launch could justify expansion. Coaching.

• The customer success team should brief the customer first if the customer is in a top-account tier.
• The rep follows up with an upgrade conversation tied to the specific value the customer gets from the new feature.
• Pricing change documentation if applicable; reps should not improvise pricing.

Scenario 3: defensive against churn

The rep has a customer at risk of churning to a competitor whose product had the feature this launch adds. Coaching.

• The customer success team should flag the at-risk customer; the rep delivers the briefing in coordination.
• Acknowledge the gap that existed; explain the timeline of the launch; show the feature.
• Offer migration support if the customer was already starting to evaluate the competitor.

Scenario 4: net-new pipeline

The rep is targeting net-new prospects for whom the launch is a relevant capability. Coaching.

• Lead with the launch as the recent product update; reference the blog post or release.
• Tie the feature to the buyer's expected pain.
• The launch announcement is the conversation starter; the demo is the conversion.

---

The training session

Live, 30 minutes, with Q&A. Recorded for reps who cannot attend.

Structure

0 to 5 minutes. PM walks through the positioning canvas. Target user, problem, promise, proof points, anti-positioning.

5 to 15 minutes. PM (or sales-engineering partner) demos the feature using the demo script. Reps see what the rep version of the demo looks like.

15 to 25 minutes. Q&A. Reps ask the questions they expect customers to ask. The answers feed back into the FAQ.

25 to 30 minutes. Coaching on top deal scenarios. Brief discussion of which named accounts in the pipeline are affected.

After the session

• Recording posted to the sales enablement platform.
• Q&A captured in the launch brief's FAQ section.
• Battlecard finalized with any new objections that surfaced.
• Demo script updated with any clarifications from the live demo.

---

What to skip

Do not.

• Hand sales a 12-page document and call it enablement.
• Train sales the morning of public launch.
• Skip the recorded demo because "we can do it live."
• Assume sales will read the launch brief before the customer call.

The discipline. Sales enablement is short, opinionated, and rehearsed. Reps internalize it once and pitch the feature naturally for the rest of the launch period.

---

The "shadow launch" failure

The pattern.

• Feature ships.
• Sales hears about it from product team Slack.
• No battlecard.
• No demo recording.
• Sales reps either ignore the feature in customer conversations (because they cannot pitch it) or misrepresent it (because they are improvising).
• Customers churn or escalate when the feature does not match what they were told.

The cost. Engineering investment is captured at zero or negative value. The next product team launch is met with sales skepticism.

The fix. Sales enablement is mandatory for B2B Tier 1 and Tier 2 launches. The battlecard takes a half day to write. The training session takes 30 minutes. The recorded demo takes an hour. The investment is small relative to the engineering investment behind the feature.

---

Supporting file: references/support-readiness-checklist.md

Support readiness checklist

Training, FAQ, escalation paths, monitoring access. The pattern of training support before customer-facing launch comms.

The principle. Support is the first to encounter the failure modes of a new feature. They need the same context as sales but oriented toward post-purchase questions and incident resolution.

---

The four deliverables

1. Training

Live or recorded, with Q&A.

The same content as the sales training, adapted for support workflows. Differences.

• Sales pitches the feature; support solves problems with it. The training emphasizes how to diagnose customer issues, not how to position the feature.
• Sales sees the happy path; support sees the failure modes. The training includes the FAQ of expected support tickets and the escalation paths for unexpected ones.
• Sales has a 30-minute training; support often has 60 minutes because the breadth of expected questions is larger.

Schedule. Support training one week before customer-facing launch comms. Recorded for reps who cannot attend live.

2. FAQ document

The questions that support expects customers to ask, with the answers.

Categories.

• What does the feature do. The basic explanation. Same content as the user-visible promise plus a short "how it works" paragraph.
• How do I turn it on. Configuration steps. Permissions required. Plan tier required.
• What are the limits. Rate limits, size limits, supported regions, supported plans.
• What if it does not work. Troubleshooting steps. When to escalate.
• How do I turn it off. For users who tried it and want to revert. Often forgotten until the first customer asks.
• Pricing or billing questions. If the feature affects billing, support needs the answer.

The FAQ updates daily during the first week of launch as new questions surface. Support reps add questions they encountered to the FAQ; the PM reviews and approves daily.

3. Escalation path

When support cannot answer a question or solve an issue, who do they escalate to and how fast.

The escalation contract.

• Tier 1 (in-product issue). Support resolves with the customer using the FAQ and product knowledge. Target response: under 1 hour during business hours.
• Tier 2 (product question support cannot answer). Escalate to the PM. Target response from PM: same day during business hours.
• Tier 3 (product is broken for the customer). Escalate to engineering on-call. Target response from engineering: under 2 hours regardless of hours during launch week.

For Tier 1 launches, the on-call rotation should include a launch-week PM contact in addition to the regular engineering on-call.

4. Monitoring access

Support reps should be able to verify whether a customer's issue is feature-specific.

The minimum.

• A dashboard showing feature health (overall error rate, feature-specific error rate, rollout percentage).
• A way to look up whether a specific customer is in the rollout cohort. (For flag-gated rollouts; some customers will not have access to the feature on launch day, and support needs to be able to confirm that.)
• A way to look up the customer's recent feature usage (or the lack thereof).

Without monitoring access, support reps escalate every feature-related ticket to engineering or the PM. The escalation queue gets noisy; real Tier 3 issues get drowned in Tier 2 questions.

---

The training-before-comms rule

The discipline. Support training happens before customer-facing comms launch.

The reason. Customers will start asking support about the feature within minutes of the public announcement. Support needs to be ready before customers ask, not while customers are asking.

The pattern.

• Day T minus 7: support training delivered. FAQ published internally. Escalation paths confirmed.
• Day T minus 1: support team huddle. Last-minute questions. FAQ refresh.
• Day T (launch day): support staffed for elevated volume. PM and engineering on-call paths confirmed open.

The "training day-of" failure. Support is trained the morning of public launch. By the afternoon, they have already encountered three customer questions they cannot answer well. The support team's confidence with the feature degrades; customers feel the rep does not know the product. Trust loss.

---

The "support is overwhelmed" failure

The setup. The launch generates more support volume than the team expected. The feature is novel; customers ask many basic questions; the FAQ does not anticipate the actual questions; support reps escalate everything to the PM.

The signs.

• Support ticket queue length doubles or triples on launch day vs the prior week.
• Tickets tagged with the feature exceed the support team's capacity for new conversations.
• The PM's Slack is full of support questions that should have FAQ answers.

The fix.

• Pre-launch: estimate support volume. Look at ticket volume from prior comparable launches; double the estimate.
• Pre-launch: staff support for the launch window. Pull in cross-functional help if needed.
• Pre-launch: write the FAQ deeper than feels necessary. Most launches have 20 to 30 expected questions; document them all in advance.
• Launch day: PM is available for FAQ updates throughout the day. New questions get answers within an hour and propagate to support.

---

What support needs that sales does not

Two specific differences.

Failure modes documentation. Support needs to know what happens when the feature breaks. The error messages users see, the recovery flows, the limitations. Sales does not need this depth; support requires it.

Customer-facing language for limits. Sales pitches the feature and addresses the limits at the negotiation stage. Support encounters the limits the moment a customer hits them. Support reps need pre-written language for "the feature supports up to X; for higher volumes, contact your account manager."

Without these two, support is improvising at the moment of customer pain. Improvisation produces inconsistent answers across reps; customers compare notes and lose trust.

---

The post-launch FAQ refresh cycle

For two to four weeks post-launch, the FAQ refreshes daily.

• Support reps log new questions they encountered, with the answers they gave.
• PM reviews daily, approves or corrects answers, adds them to the canonical FAQ.
• Support team gets a daily summary of new FAQ entries.

After two to four weeks, the FAQ stabilizes. The refresh moves to weekly, then monthly.

The cost of the daily refresh is small. The benefit is that support builds confidence with the feature in the first month, instead of struggling for the first quarter.

---

When support flags an issue larger than a question

Sometimes the support volume on a feature reveals a real problem with the feature, not just a need for better FAQ.

Signs.

• Many customers ask the same question, and the answer is "the feature does not do that." The customers expected something the feature does not deliver. Positioning was misaligned.
• Many customers report the same bug. The bug is real and affects a meaningful share of users.
• Support tickets cluster on a specific cohort (e.g., users on a specific plan, in a specific region). The feature does not work correctly for that cohort.

The pattern. Support is the early-warning system for launch quality. The PM should review the support ticket digest daily during the first week and at least weekly thereafter. If the support volume reveals a feature problem, the launch may need to pause for a fix before further rollout.

The discipline of treating support as a quality signal is the cheapest way to catch launch problems before they show up in revenue or churn metrics.