skills/speaking-proposal/SKILL.mdView on GitHub
This applies the day a prior show ends and whenever an organizer opens a call. It produces a proposal that gets accepted because it is about the audience’s problem, not the product.
Before you start
This skill works on its own. If the person has their own marketing brain (or any folder of context files about their company), read the files listed under reads in the header first and cite them for every fact. If they do not have one, do not look for one: ask for the two or three facts this play needs and go on. Never invent a fact; a blank is a question for the person.
Tools: this play speaks in verbs (check the CRM, pull the call, schedule the post). TOOLS.md at the root of this repo lists the tools recommended for each verb. The company’s own 1-context/stack.md wins when it exists. No tool is required; a spreadsheet and a mail client cover most of it.
The play
- Read the context (see Before you start). Record the deadline in the events system of record the day it is known.
- Pick the topic from the audience’s problem: an industry shift, a workflow the audience fights with, a case a customer can co-present. The product appears as the example, not the subject.
- Pick the speaker: the founder for point-of-view talks, the product or success lead for workflow talks, a customer as co-presenter where one is cleared and willing. A customer on stage is the strongest proposal.
- Write the proposal in the organizer’s format: title, abstract, learning objectives, speaker bios, audience level. Keep the abstract concrete; one named outcome the audience leaves with.
- Clear any customer, claim or figure in the abstract through
permission-check. - Build the deck outline on acceptance: the audience’s problem first, the approach, the case, what to do Monday. No product demo slides unless the organizer asked for a vendor session.
- Tie the session to the show plan: a session leads to the booth, a dinner or a meeting block;
event-outreachnames it. - If rejected, ask why and file the answer for next year’s proposal.
What good looks like
- The best operator submits the day the prior show ends and proposes a customer co-presenter. Most rejections are late submissions and vendor pitches.
- The mediocre version proposes a product overview and misses the deadline by a week.
- Good output is a proposal an organizer can accept without editing, a speaker who is ready, and a deck that an attendee would recommend.
Rules
- MUST record the deadline the day it is known and submit before it.
- MUST make the audience’s problem the subject, not the product.
- NEVER name a customer co-presenter without their agreement and the permission check.
- NEVER promise a demo of an unreleased feature on stage.