Run the Enablement Content Factory

Workflow area: Launch & GTM · Tier: Foundation · Hands-on time: ~30 minutes

Enablement content is the classic PM tax: high volume, formulaic structure, and it all derives from source material you already wrote. That makes it nearly ideal AI work — the structure is known, the facts are supplied, the voice is learnable. The failure mode is equally predictable: generated enablement drifts from what the product actually does, sales repeats the drift to a prospect, and you spend a quarter walking back a capability you never built. The factory produces volume; the SME gate produces truth.

When to use — and when not to

• Use it at every launch that touches sales or supportthe field needs one-pagers, macros, and scripts on day one, and they never get them on day one when a human writes each from scratch.
• Use it to refresh stale enablementfeed the current one-pager plus the last three releases and ask what's now wrong with it. Outdated enablement is worse than none.
• Use it when the same story needs five formatsone-pager, macro, quiz, demo script, and objection-handling doc are the same facts wearing different clothes; that transformation is the factory's whole job.
• Skip it for pricing and legal-adjacent claimsdiscount policy, compliance posture, SLAs, security questionnaires. Those words are contractual; they come from legal and finance verbatim, never generated.
• Skip it when there's no SME hour availablean unreviewed factory is a misinformation factory with your name on the commit. If nobody will review, don't generate.

The recipe

1. 1.

   Build the source pack. The PRD (or its summary), the demo recording transcript, the known limitations list, and — critically — the "do not promise" list: roadmap items, unsupported configurations, competitor comparisons you won't stand behind. The factory is only as honest as this pack.

2. 2.

   Set up the factory prompt with a claims rule. In Claude or a Claude Project:

   Copy

   You are generating sales and support enablement from source
   material. Hard rules:
   - Every capability claim must be supported by the source pack.
     If it isn't there, leave it out.
   - Never mention roadmap or timing.
   - Known limitations must appear in every artifact that a customer
     could act on.
   - Mark any claim you are unsure is supported with [SME-CHECK].
   
   Source pack:
   [PRD SUMMARY]
   [DEMO TRANSCRIPT]
   [LIMITATIONS + DO-NOT-PROMISE LIST]
   
   Artifact 1 — Sales one-pager: problem (2 sentences), what it does
   (3 bullets), who it's for, differentiator (only if source-backed),
   limitations (honest), one discovery question a rep can ask.
   

3. 3.

   Generate the rest of the set in the same conversation. The context carries; ask for each artifact in turn:

   Copy

   Artifact 2 — Support macros: the 6 most likely tickets after this
   launch, each with a customer-ready reply under 120 words and an
   internal note on when to escalate.
   
   Artifact 3 — Demo script: 5-minute walkthrough with exact click
   path from the transcript, the "wow moment" called out, and the
   two questions to ask the audience.
   
   Artifact 4 — Training quiz: 8 questions testing what reps most
   often get wrong (limitations, who it's NOT for, escalation path),
   with answers and one-line explanations.
   

   A healthy macro looks like:

   Copy

   TICKET: "Can I export the new dashboard to CSV?"
   REPLY: Not yet — the dashboard view doesn't support CSV export in
   this release. You can export the underlying table from Reports →
   Raw Data. [SME-CHECK: confirm Raw Data path unchanged]
   INTERNAL: If the customer needs scheduled exports, escalate to
   the product team — do not suggest a timeline.
   

4. 4.

   Run the SME review as a diff, not a read. Send each artifact to the owning expert — sales engineer for the one-pager, senior support agent for macros, you for the demo script — with one instruction: mark every claim that is wrong, unverifiable, or over-promised, and resolve every [SME-CHECK] tag. A twenty-minute markup beats a "looks good" every time. Track corrections; they're your factory's error rate.

5. 5.

   Publish to one home with a version stamp. Guru, Notion, or the sales wiki — one canonical location, each artifact stamped with product version and review date. Enablement that lives in six Slack threads is already stale. Record a Loom walkthrough of the demo script so the field hears tone, not just words.

Make it yours

• Voice-match the field: paste two of your best rep's actual call snippets (with permission) and ask the model to match that register — enablement that sounds like marketing gets ignored; enablement that sounds like the floor gets used.
• The objection bank: feed lost-deal notes from your CRM and generate an objection-handling addendum — the objection, the honest response, the trap answer to avoid. Review with sales leadership before distribution.
• Per-segment splits: run the one-pager prompt once per segment (enterprise, mid-market, India pricing tier) with segment context added — the facts stay constant, the emphasis and examples shift.

Quality check

• Zero unsupported capability claimsspot-check every "it can" statement in the one-pager against the PRD; the model's default failure is rounding "planned" up to "shipped."
• All [SME-CHECK] tags resolved by a named expertan artifact still carrying tags is a draft, not enablement.
• Limitations survived formattinggenerated enthusiasm tends to bury the honest caveats; confirm each artifact still says what the product doesn't do.
• The quiz tests failure points, not triviaif a rep can pass it without knowing the limitations and the escalation path, regenerate it.
• One canonical home, version-stampedand the previous version is archived, not lingering in search results.