Release Notes To Seller Updates

Turn product release details into seller updates that clarify why the change matters, who it matters to, and how to use it in the field.

Confirm Inputs First

• If a current revenue-enablement-context exists, use it first for segment language, persona emphasis, and approved claim boundaries.
• Confirm the source material: release notes, changelog, product spec, internal memo, or engineering update.
• Confirm the audience: AEs, SDRs, SEs, managers, CS, or a mixed revenue audience.
• Confirm whether the change is net-new capability, iteration, packaging change, bug fix, or deprecation.
• Confirm known target segments, affected use cases, and likely field questions.
• Confirm whether the user needs a quick summary, talk-track update, FAQ update, or manager briefing.

If inputs are incomplete, ask for only the highest-impact gaps. If the user prefers speed, proceed with labeled assumptions.

Default Workflow

1. Read the source notes and separate technical changes from seller-relevant implications.
2. Identify who should care, what customer problem changed, and what behavior should change in the field.
3. Translate the release into practical seller language: customer impact, qualification triggers, proof points, landmines, and likely objections or FAQs.
4. Separate what changed from what did not change so the update does not create accidental confusion.
5. Select output variant(s) needed: Slack update, email digest, wiki/changelog entry, or manager briefing notes.
6. Package the output for the requested audience and urgency level.
7. Return a concise update that sales or enablement can distribute with minimal editing.

Read The Right Reference

• Read references/release-transformation-guide.md for transformation rules and seller-language guardrails.
• Read references/source-system-guide.md when the source or distribution layer depends on shared docs, Slack, or enablement platforms.

Tool Notes

• Keep the workflow tool-agnostic by default.
• Use references/source-system-guide.md for channel selection, minimum pull guidance, and safe distribution boundaries.
• Treat those systems as accelerators, not hard dependencies.
• If the change is still ambiguous or the source notes are incomplete, preserve uncertainty instead of over-translating.

Output Contract

• Default to these deliverables unless the user asks for a narrower output:
• Seller summary with customer impact
• Audience and use-case guidance
• Talk-track changes or talking points
• FAQ or objection notes
• Risks, caveats, and what still needs clarification
• Variant-ready copies for requested channels: Slack, email, wiki, or manager briefing

What To Avoid

• Translating technical changes without stating customer-facing impact.
• Mixing internal uncertainty with confident seller guidance.
• Publishing one format and expecting it to work for every channel.

Quality Bar

• Updates are short enough to use quickly and specific enough to change field behavior.
• Customer impact is clearer than feature mechanics.
• Talk-track guidance is accurate and avoids overstating the change.
• Unknowns and caveats are labeled instead of guessed.
• Output helps revenue teams act, not just stay informed.