product-launch-enablement

Product launch enablement

Prepare each affected revenue role to explain a launch accurately and handle the customer situations it creates.

A launch package tells each role what changed, what did not, and what they should stop saying. If the user only wants a Slack or email update from the notes, use release-notes-to-seller-updates.

Ready. "From 20 August, AEs can mention Escalation Rules 2.0 to Pro and Enterprise buyers who inspect overdue handoffs. Existing rules keep running. Do not say migration is automatic."

Release note. "We shipped conditional triggers, team escalation, and audit history. Please share with your teams."

Make clear what each affected role must change in its customer work.

Inputs

Reuse supplied context first. If a missing company fact would change the result, check the relevant sections of .enablement/context.md when available. Preserve source dates and approval limits.

Ask only for the inputs that change readiness:

1. What changed, and why the field should care
2. Who must change behavior
3. Known dates, rollout model, and approvals
4. Approved claims and named claim owners
5. Real delivery and manager capacity

If a date, eligibility rule, or claim is missing, leave it unknown. Do not invent launch dates, availability, or capacity.

Supporting material

Read references/launch-readiness-framework.md for tiering, gate evidence, and the first decision window. Read references/source-system-guide.md when the plan has to land in docs, Slack, an LMS, or a tracker.

Procedure

1. Name the change and the non-change. One sentence for what is new. One for what still works the old way. One for the line sellers must retire. Done when all three are specific enough to inspect.
2. Classify the launch from consequence, not breadth. Tier 1: optional awareness. Tier 2: a bounded behavior or handoff change that needs practice. Tier 3: pricing, contracts, regulation, customer transition, or hard-to-reverse ops. Breadth scales delivery; it does not promote a low-risk update. Done when you can say why this tier in one sentence.
3. Test the capacity envelope. Compare audience demand to facilitator, manager, and constrained-owner time. Return fits, reduce, sequence, or blocked. Done when the binding constraint has an owner.
4. Write the field message by role. What changed. Why it matters. When to use it. What not to say. Done when AE, SE, CS, and manager each have a different next action, or you can say why they share one.
5. Build only the kit this tier needs. FAQ, talk-track change, objection notes, proof with source. Add runnable practice when Tier 2 or 3 requires it. Route a full spoken track to talk-track-builder.
6. Set evidence-backed go/no-go gates. Check product truth, approved claims, eligibility, field readiness, and support. Demonstrate the changed task and verify the handoff with the responsible owner. Mark simulated tests as such. A gate needs evidence of a working path; document approval or attendance alone is insufficient.
7. Map handoffs. PMM, enablement, sales, CS, RevOps, support. Done when a seller knows who to ping for eligibility, proof, pricing, and custom work.
8. Set the first post-launch decision window. Use confirmed cadence. If unknown, label it proposed and name who confirms it. Do not invent numeric thresholds.