AI for product presentations: structure first, slides second

Why does an AI deck outline collapse under the first question?

Ask a model for a deck about a pricing change and you get twelve slides: agenda, context, market overview, problem, solution, benefits, timeline, risks, next steps, thank you. Every slide is defensible on its own and the sequence makes no argument at all. Nobody in the room learns what you want decided until slide nine, and by then two people have started debating the market overview.

The failure is structural, not stylistic. A model asked for a presentation produces the shape of a presentation, because that shape is what it has seen most. A decision meeting is a different object: a room of people who have to say yes or no to a specific thing within the hour. Give the model that object, and it fills it competently. Give it a topic, and it gives you a topic.

Nine slides, and the ask is slide one

This is the structure worth handing to a model, and worth defending when someone asks you to add a market overview back in.

1. The ask. One sentence with a verb and a date. "Approve moving the team to usage-based pricing for new accounts from 1 November."
2. The three numbers. One sizes the problem, one shows what changed since the last time this was discussed, one prices the decision.
3. What changed. The new information that makes this a decision now rather than in March.
4. The options. Three at most, with your recommendation named on this slide, not withheld for drama.
5. Why not the others. One line each. A reason, not a dismissal.
6. What it costs. Engineering weeks, money, and the thing you stop doing to make room.
7. The strongest objection. Stated in the words the person who holds it would use, then answered.
8. What would make this wrong. The signal you will watch for, and the date you will look at it.
9. The decision and the owner. Who says yes, by when, and what happens if they say nothing.

Slides 7 and 8 are the ones that get cut under time pressure and the ones that decide whether the room trusts you. A deck that names its own kill signal reads as a proposal from someone who has thought about being wrong.

What do you give the model before it writes anything?

The single biggest quality jump comes from feeding the model the source document rather than the subject. Anthropic's guidance on context engineering makes the general case: the useful unit is the smallest set of high-signal material that actually determines the answer, not a broad description of the area. For a deck that means the one-pager or memo the decision came out of, the three numbers with their definitions, the names and roles of the people in the room, and the decision sentence you wrote yourself.

Write the decision sentence by hand. It is 20 words, it is the only part of the deck a model genuinely cannot produce, and every other slide is downstream of it. If you cannot write it, the deck is not the problem. If you have a one-pager already, how to write a one-pager with AI is the upstream artefact this structure compresses.

A prompt that works, once you have those inputs:

Here is the memo, the three numbers with definitions, and the decision sentence. Build a nine slide deck in this exact order: ask, numbers, what changed, options with my recommendation named, why not the others, cost, strongest objection in the words the sales lead would use, kill signal with a review date, decision and owner. One idea per slide. No agenda slide, no thank you slide. Where the memo does not support a slide, write MISSING and say what you need.

That last instruction is what turns a confident draft into a useful one. A model asked to flag gaps will flag them. A model not asked will fill them with something plausible.

One slide title, before and after

The model's draft, from a real shape of request:

Slide 4: Strategic Options for Pricing Evolution We evaluated several approaches to align pricing with customer value. Each option presents distinct trade-offs across revenue, adoption, and implementation complexity.

Nothing there is false and nothing there is a claim. The edit:

Slide 4: Three options. We recommend usage-based for new accounts only. Usage-based for new accounts, usage-based for everyone, or no change. We recommend the first: it tests the model on 400 accounts a quarter without touching the 3,000 existing contracts that renew in Q1.

The title now carries the recommendation, so a reader who only looks at titles still gets the argument. The body gives a number the room can push on. "Distinct trade-offs" gave them nothing to push on, which feels safe and is the reason the meeting runs long.

The five edits a model will not make on its own

A model editing its own draft will tighten sentences and leave the argument exactly where it was. These five are yours:

• Delete the agenda slide and the thank you slide, then check the deck still opens with the ask.
• Cut the numbers down to three, and for each survivor write the definition you will say out loud when someone questions it.
• Move the recommendation onto the options slide, in the title, not the body.
• Rewrite the objection slide in the objector's voice. If the sales lead would say "this punishes our best customers", write that, not "some stakeholders may have concerns about customer impact".
• Name one person as the decision owner, with a date. A deck that ends on "next steps" ends on nobody.

None of these require judgment about design. All of them require judgment about the room, which is the part the model does not have.

When should you not build a deck at all?

When the decision is reversible and cheap, a deck is a way of spending four people's hours to confirm something you could have shipped and measured. When the decision is genuinely contested, the deck is worth building and the conversation should happen before the meeting, one person at a time, so the meeting ratifies rather than discovers. The deck you present in a room where the outcome is already agreed is doing its actual job: creating a record of what was decided and why.

The honest limitation of using a model here: it will never tell you the meeting should not happen. Asked to build a deck, it builds one, with the same enthusiasm for a decision worth 40 engineering weeks and a decision worth an afternoon. That judgment sits with you, and it is the judgment that saves the most time.

Who this fits, and what comes after

This structure is aimed at a PM who already has the analysis and keeps losing the room. If the harder problem is that you do not yet have a defensible recommendation, the sequencing and bet-selection work in Product Strategy is upstream of anything a deck can fix, and the stakeholder and hard-call material in Head of Product is the layer above that. Product Storytelling is the direct match: narrative structure, framing risks, and handling objections, in 1 week with 2 live sessions and 7 microlessons.

See the Product Storytelling bootcamp

For the numbers on those three slides, data storytelling covers turning a metric into a claim someone can act on, and Claude Code roadmap synthesis covers the step before the deck, where a quarter of scattered inputs becomes the memo you feed the model. The deck is the last artefact in that chain, and it is the one that fails loudest when the chain above it is thin.