Pitch

Prepare a presentation the user can say aloud, so the audience understands the product, assesses the evidence and chooses a specific next step. Preserve the user's requested language and deliverable.

The guidance draws on analysis of startup pitches, demos and launch presentations. See source notes for observations and research limits, and structures when choosing a narrative. These examples offer options, not a universal success formula. Repeating the source research is not a prerequisite for ordinary pitch preparation.

Establish the presentation's job

Infer the audience, duration, language, current product status, evidence and desired decision from the conversation and supplied material. If essential information is missing, ask at most three critical questions in one short round. Don't make the user repeat known information or turn a simple revision into an interview. While waiting, review available sources and the draft; don't invent facts that depend on the answer.

State the audience's intended decision in one sentence:

• Investor: a follow-up meeting or a specified investment request; economics, growth and why this team.
• Jury or grant panel: criteria, feasibility, novelty, implementation plan and current evidence. Preserve mandatory formats.
• Customer: using the product for a specific job or evaluating a pilot; practical results, transition effort and trust.
• Launch: understanding and trying the product; demonstrable benefits and access conditions.

Don't add an investment amount, free pilot, discount, delivery promise or contractual terms unless the user requests them. Improving a presentation doesn't authorize changing product strategy.

Build the narrative

1. Make the product understandable early. The opening should establish what it does and for whom. If the audience doesn't know the terminology, use a person → their job → current difficulty → observable result, then connect it to the product. Avoid a history of the entire industry.
2. Choose one main idea. Decide which sentence the audience should be able to repeat afterward. The opening and close express the same idea in different words; the evidence between them supports it.
3. Order the evidence for the situation. Strong usage or commercial evidence can come early (GitLab). For an unfamiliar category, use a concrete example → before/after → mechanism (Retool). When motion explains the value, move quickly to the demo (Dropbox, Scrub Daddy). Select a suitable structure rather than combining every pattern.
4. Explain the causal chain. Feature → what it enables → customer result → why it is credible. For example, explain which production or distribution advantage open source creates; the label alone doesn't establish a benefit.
5. Address the main objection. Use evidence to answer the question most likely to stop the audience. Move secondary objections into Q&A rather than crowding the script.
6. Ground the vision. Explain the mechanism connecting today's work to a broader goal. Don't transplant an established brand's long anticipation sequence into a short jury pitch or assume its stage privileges apply to an early product.
7. Close with a next step. Recall the main result and state the single action the user has chosen. If the ask is unknown, use a neutral close or identify the missing input.

Separate the slide's job from the script's job

Give each slide a claim and a supporting image or figure. The script explains its meaning and reasoning. Preserve the existing design, template and required page count. Derive slide count from narrative sections, not a list of topic headings.

Connect these elements for each section:

Where possible, use a headline that states the slide's conclusion rather than a folder label such as "Problem / Solution / Market." For every figure, explain the unit, period, base and measurement. Avoid asking the audience to read a chart while the speaker clicks through an interface and introduces dense new information.

Write a demo

• Choose one customer job. Establish starting conditions → action → visible result → meaning of that result.
• Before clicking, say what the audience will see. When the output appears, identify where to look and leave a short reading pause.
• Match evidence to the claim: the same measured task for speed, expected versus actual results for accuracy, actual steps for ease of use. Decorative animation doesn't establish correctness.
• Layer the technical explanation: benefit and observable result first, then the mechanism. Give technical audiences useful detail; don't assume a jury has specialist knowledge.
• Limit the feature tour to steps that advance the same story. Don't present separate experiments as one mature product or copy the prototype overload in the Figma retrospective.
• Prepare a short fallback for a live demo: an approved recording or clearly labeled saved output. If interrupted, give one explanation, switch once and return to the story. Don't describe a recording as live.

Speaking and rehearsal

Write for speech: clear subjects, direct verbs and one thought per sentence. Break breathless lists and chains of abstract nouns. Preserve the user's voice instead of imitating a famous founder's personality.

Transitions should explain why the next section follows. Use natural questions such as "How does this work?" where helpful, without repeating the same transition on every slide. Keep delivery cues sparse: [brief pause], [show output], [slow down on main figure]. Allow processing time after claims and numbers. Use humor only when it suits the user and setting.

Estimate duration as word count / speaking rate + demo actions, pauses and transitions that don't overlap with speech. Prefer the speaker's measured rate. Otherwise, use an initial assumption of 120–140 words/minute for English; adapt for the language and speaker. These are rehearsal assumptions, not research findings or measured personal rates. Don't count speech during a demo both as speaking time and separate demo time. Give a range labeled estimated rather than promising it fits. Identify what to cut if time runs short, preserving the product definition, evidence and close.

If a recording exists, inspect actual duration and stumbling points. Without one, don't claim to have observed voice, gestures, pace or audience reactions. Distinguish a rehearsal plan from a completed rehearsal.

Evidence discipline

For each substantial claim, retain its source, date, unit/period, scope and intended wording. User-provided information may be labeled "user statement"; don't label it independently verified external data.

Explain each relevant uncertainty once in the main script, where it affects the decision. Move repeats into Q&A or preparation notes. Keep attention on the demonstrated work and available evidence instead of repeatedly listing what isn't claimed. Don't present a proposed measurement as an achieved result or an approved plan.

• Visitors, registered accounts, active users, pilots, customers and revenue are different measures. Transaction volume, sales generated for customers and company revenue are also distinct.
• State whether growth is daily, monthly or annual. Don't infer a base from a percentage without start and end values, or generalize one customer's result to all customers.
• A pilot's potential value is not collected revenue or ARR. Preserve live, beta and planned status.
• Figures in source pitches are the presenters' historical claims. This research didn't establish their accuracy or a causal relationship to later success.
• When evidence is limited, use a concrete demo, the current product or feedback with its scope explained. Don't invent numbers, logos, quotes, founder anecdotes or success stories.
• Read the project's current instructions, product plan and evidence. Product scope and pricing are not fixed in this skill. Don't narrow the user's product to an example company's category.

Deliver and review

Deliver the requested scope. For a full package, include the narrative choice, spoken script, section-by-section slide/demo mapping, estimated timing and cuts, important Q&A answers, and claim sources or missing inputs. If the request is only an opening, assessment or slide, don't generate the entire package. In Q&A, answer directly first, then give evidence or limits, followed by a next step if needed.

Check:

• Can someone unfamiliar with the category explain the product and its use after the opening?
• Does the main claim have visible evidence, with examples separated from generalizations?
• Does every slide advance the story, with speech matched to what is shown?
• Does technical detail help the audience decide?
• Does the estimate include demo actions and pauses, with the right label if no spoken rehearsal occurred?
• Does the ask fit the user's goal and authority, without adding unknown commercial terms?

For critique, use section → specific problem → audience impact → correction instead of abstract scores or "make it more impressive." Don't infer body language from text.

Using this skill doesn't itself authorize external messages, publication, edits to a live deck or paid media production. Follow the user's scope and permissions. When a presentation file is requested, use an appropriate available presentation tool; this skill supplies the narrative and delivery notes.