Make your pitch make sense without you.

You send the deck after a promising call. Someone forwards it to a partner who has never met you. The partner opens slide one. Your explanation, the demo you showed and the answers you gave on the call are all missing.

That is a useful editing condition. Can the deck explain the business to a reader who has only the slides? Start there before choosing a template or changing the colours.

Start with a sentence someone can repeat.

A cover can carry an ambitious line, but it also needs to place the company. Give the reader a product, a customer and a recognisable job. Leave the technical mechanism for the moment it becomes useful.

The second version gives the next slide something to work with. A reader can picture the team, the questions and the data. You can now explain why answering those questions is difficult, how your product helps and what evidence you have.

Michael Seibel’s YC guide to pitching also begins with a plain explanation of what the company does. Use that as a comprehension check, rather than a requirement to squeeze the whole business into the cover.

Write the argument before laying out the slides.

Open a blank document and write one sentence for each thing the reader needs to understand. Keep the sentences specific enough that they could be wrong. “Our market is large” gives you little to prove. “Independent clinics spend six hours a week reconciling bookings” tells you what evidence to look for.

Read the sentences in sequence. Does one create a reason to read the next? If a sentence depends on an unexplained term or an assumption you only mention in conversation, fix that dependency.

A fictional analytics company might build this sequence:

1. Finance teams wait on analysts for routine revenue questions.
2. The delay matters during weekly planning, when the numbers keep changing.
3. The product lets those teams ask questions against a governed dataset.
4. Early customers return each week, and some pay for continued access.
5. The round funds a test of whether that demand repeats beyond the founders’ network.

Each sentence creates an evidence requirement. The problem needs an observed workflow. The product needs an example. Returning customers need a definition and a time period. The expansion plan needs a test someone can evaluate.

Give the strongest proof room to work.

You do not have to start with several slides about a broad industry trend. If you have a particularly relevant customer result, a working product or a hard-earned technical breakthrough, consider introducing it early. Then supply the context the reader needs to judge it.

Keep the distinction between a claim and its support visible. “Customers use us every week” is a claim. A cohort chart, with dates, a definition of activity and the number of customers in each group, lets the reader examine it. A large number floating beside a screenshot leaves those questions unanswered.

Choose the evidence for the claim you are making. A quote can show that someone recognises a painful workflow. It cannot establish how often every customer uses the product. A usage chart can show repeated behaviour. It cannot explain what a buyer has agreed to pay.

Choose what belongs in this version.

A deck you present can rely on your voice to explain a transition or a chart. A deck sent ahead has to carry more of that explanation. Keep the same facts across both versions, and adjust how much context appears on the page.

Use the appendix for material that helps answer a follow-up: calculation details, metric definitions, technical architecture or a fuller customer example. If the main story requires a fact to make sense, keep that fact in the main story. Making a slide cleaner by hiding its essential explanation creates work for the reader.

Try a cold read.

Give the deck to someone who has not heard your pitch. Kevin Hale proposes a useful slide-level test in his YC guide to deck design: can a stranger identify the idea you meant to communicate? Try the same test across the deck. Let the reader finish without interruption, then ask what the company sells, who buys it, what evidence seems strongest and what remains uncertain. Record the words they use.

If they describe a different customer or product, return to the relevant slide. If they understand the business but doubt a claim, examine the evidence behind it. Those are different editing jobs.

Finish by reading only your slide headlines, in order. They should describe a business and a reason to keep learning about it. When that sequence holds, layout and visual emphasis have a clear job: help the reader see the argument you have already built.

Name one person and one moment.

For the problem slide, describe a task a specific customer is trying to complete. Show what happens today, where the task breaks down and why that matters. A broad industry trend rarely gives the reader enough detail to picture the customer’s day.

Use an observed workflow when you have one. Keep a customer quote, the frequency of the task and the cost of the delay distinct: each supports a different part of the explanation.

This example names an ops team, a routine question and the delay before an answer. Check whether your problem slide is equally concrete.

Open this slide in the full example deck