How to write a product one pager with AI

What is a product one pager for, and who is actually reading it?

A one pager exists to get a decision out of someone who has not been thinking about your problem. That reader is choosing between your idea and several others, has less context than you, and will give the document somewhere between ninety seconds and five minutes. Everything about how you write it follows from those two facts, which is why it is a different craft from the one pager template's structure: the sections tell you what goes where, and this page is about how to make the argument land once it is there.

Amazon's version of this document, the PR/FAQ, is disciplined about length for a reason Bryar and Carr state directly: the press release section runs to less than one page, the FAQ to five pages or less, and the limit is described as a forcing function that develops better thinkers, not as a formatting rule. The failure they name is the one every product manager recognises, attaching page after page so the writer never has to decide what matters and the group does it instead.

That is the whole game. A one pager is a decision about what to leave out, written down.

Why does the tenth draft matter more than the first?

Because the first draft is where you write what you already think, and the tenth is where you find out what you actually believe. Amazon teams routinely write ten drafts or more and meet with senior leaders five times or more before the review, which sounds absurd until you notice the drafts are doing the thinking rather than recording it.

This is the exact place AI changes the economics. Producing draft seven used to cost an hour you did not have, so most one pagers ship at draft two. With a model doing the mechanical rewriting, the marginal cost of another pass drops to minutes, and the constraint moves from your typing speed to your judgement about which version is better. That is a real improvement and it is worth naming precisely, because it is narrower than "AI writes your one pager for you." The model does not know which draft is right. It makes producing candidates cheap enough that you can see the difference.

Keep a record of what you cut between drafts. The cuts are usually more informative than the final document, and they are the answer when someone asks why you did not consider the obvious alternative.

How do you use AI on a one pager without flattening it?

Give the model the constraints first, then the content. A useful prompt names the reader by role, names what that reader is accountable for, names the decision you want, and states the one fact you are least sure of. Without those, the model writes to a generic executive, which is how you end up with a document that could be about any product once you swap three nouns.

Then run the passes that pay, in this order:

• Five openings, then pick one. Ask for five different first paragraphs, each leading with a different element: the cost of doing nothing, the customer's own words, the number that changed, the competitor move, the deadline. Read them cold. The one you would keep reading is usually not the one you would have written.
• The "so what" pass. Amazon reviewers ask exactly this question of a press release: if the product is not meaningfully better, faster, easier or cheaper than what exists, it is not worth building. Have the model ask "so what" after every claim in your draft and answer each one, then delete the claims that have no answer.
• The hostile read. Give the model the specific reader, their incentive, and what they are protecting, and ask what they object to. The output is not a prediction of the meeting; it is the list of places your argument is thin, a day early.

Do not ask the model whether the idea is good. It has nothing to check that against, and it will be pleasant about it.

What does an AI draft do to the shape of your argument?

It rounds the corners. Models produce the most plausible version of a pitch-shaped document, and the most plausible pitch is the one your reviewer declined last quarter. Builders Camp's Product Storytelling bootcamp builds its practical challenge around exactly this failure mode: three product managers pitch the same async voice tool to the same investor, and all three walk out without a term sheet for different reasons. One buries the reader in architecture, one pitches a feeling with no evidence, and one lands the manager's actual problem with a number attached. The exercise is to work out which failure is which, then write the version that works.

Read your AI-assisted draft against that test. If the specifics that only you know, the exact quote, the exact number, the thing a customer did that surprised you, have been replaced by smoother general statements, the model has quietly moved your pitch toward the version that fails.

How do you test a one pager before you send it?

Give it to someone who has not been in the conversation and ask them three questions: what am I asking you to approve, what does it cost, and what happens if we do nothing. If they cannot answer all three from the page, the document is not finished no matter how good the prose is. This is a cheaper test than it looks, takes four minutes, and catches the failure that kills most one pagers, which is that the ask was implied rather than written.

A second test worth running: hand the page to the model as if it were the reader, and ask what decision it thinks it is being asked to make. When the answer comes back vague, the ask is buried.

Who this is for, and who it is not for

This fits a product manager who needs a yes from someone senior before any building starts, which is the persuasion skill Builders Camp's Product Storytelling bootcamp teaches across 1 week and 2 live sessions, covering narrative structure, stakeholder objections and turning trade-offs into something a room can decide on. If your pitch is really a strategic bet rather than a single feature, Product Strategy covers the choices underneath it, including how to write and present a strategy in a way that reduces debate rather than extending it. If the gap is the underlying product process rather than the writing, Product Manager Foundations covers the end-to-end path from problem to launch.

It is the wrong document once the decision has already been made. At that point you need the PRD and the sequencing that goes in a product roadmap, and a second persuasive page just delays the build. It is also the wrong document when your real problem is that you do not yet know whether the problem is real, which is a discovery interview away, not a rewrite away.

Write the ask first, then everything above it

Try the inversion on your next one: write the final line, the specific decision you need and by when, before you write anything else. Then write the page that earns it, and delete every sentence that does not move a reader toward that line. It is an uncomfortable way to start, and it surfaces the most common defect in these documents within about five minutes, which is that you were hoping for general enthusiasm rather than a decision you could name.

See the Product Storytelling bootcamp

For the section structure this workflow fills in, see the one pager template. For the strategy work behind a bigger bet, see the Product Strategy bootcamp, and for what you write once the answer is yes, the PRD template.