Build it in stages, not one shot

Here is the thing almost everyone does with a big piece of work. They open a chat, describe the deck they need, attach a folder of material, and ask for it. What comes back is confident, well formatted, structurally plausible and quietly wrong in a way that takes an hour to find.

The instinct is then to blame the model. The actual problem is that you asked one question to cover four decisions: what the evidence is, what the argument should be, how it should be structured, and how it should read. Bundle those together and you get a document where a weak argument is hidden under good formatting, which is the most expensive kind of draft to receive.

So stop asking for the finished thing. Build it in stages, and put a checkpoint between each one.

Stage 1. Prepare the sources

Before anything gets written, get the inputs straight. Not "here is a folder", but an actual inventory: what you have, what is current, what is out of date, and what is missing.

Ask for exactly that. Give it the brief, the rate cards, the research, last campaign's numbers, and ask it to tell you what it is looking at, what contradicts what, and what it would need that it has not been given.

This stage regularly saves the whole project, because the answer is often "the brief says one market, the plan covers three" or "these two documents give different budgets". Finding that in stage one costs a minute. Finding it in the review costs a rebuild. A clean source packet beats a confident guess every time.

Stage 2. Agree the structure before anything is built

Next, the argument. In plain English, before a single slide exists: who the audience is, what decision you want out of them, and what they have to believe to make it.

Then the skeleton. A list of sections, each with a headline that states the claim rather than naming the topic. "Market overview" is a topic. "The category is growing but our share of voice is falling" is a claim. If the headlines only name topics, you have an outline with no argument, and you will not find that out until the end.

Read the skeleton. Argue with it. Move things. Kill a section. This is the cheapest possible moment to change your mind, and it is the step people skip because it does not feel like progress.

Stage 3. Build inside constraints

Only now do you build, and you build from the approved structure and the prepared sources, not from a fresh description of what you want.

For anything substantial, do it in two passes. First the argument in full sentences, no formatting, no design, just the case being made section by section. Read it as prose. A weak argument is obvious in plain text and nearly invisible once it is in a deck with a nice layout.

Then render it. Slides, document, whatever the format is. By this point the thinking is settled and you are only making it presentable, which is the part that genuinely benefits from speed.

Stage 4. Let something hostile read it

The optional stage, and the one that has saved me the most embarrassment.

Open a fresh chat, one with none of the context and none of the investment, and hand it the finished thing with instructions to attack it. Not to improve it. To find the unsupported claim, the number that appears in two places with two values, the recommendation that does not follow from the evidence, the slide that would get you asked a question you cannot answer.

The reason this works is that the chat that helped you build something is a poor judge of it. It has been agreeing with you for an hour. A fresh one has no such loyalty.

Why this is the important chapter

Every other chapter in this playbook makes a single step faster. This one changes what you are doing, from asking a machine for a document to running a process with checkpoints in it, where the machine does the labour and you keep the judgment.

It is also slower on the first attempt and faster on everything after, which is why people abandon it in the first hour. Stay with it through one real deck.