How to write a product brief with AI

What is a product brief, and why write one before a PRD?

A product brief is the document that decides whether a PRD gets written. It carries four sections: the problem, the evidence that it is real, the direction you recommend, and the specific decision you need from the reader. Everything else that feels like it belongs in the brief, the requirements, the edge cases, the rollout plan, belongs in the PRD template that comes after.

That ordering is not bureaucracy. Marty Cagan's framing of the four big risks that kill products, value, usability, feasibility and business viability, is useful here because a brief only has to clear the first and the last. Does anyone want this, and does it make sense for the business to build it? Usability and feasibility are questions for design and engineering once someone has agreed the problem deserves a team. A brief that starts arguing about implementation has skipped ahead to a question nobody has earned the right to ask yet.

Write it in one page. A problem that needs three pages to state is usually two problems wearing one name.

Why does an AI draft of a brief read better than it deserves to?

Because a language model writes the evidence section with the same fluency whether you handed it twelve support tickets or a single sentence of intuition. Ask for a brief about "users struggling to find their invoices" and you will get back a paragraph naming a segment, a frequency, and a business cost, all phrased like measurements. None of it is flagged as invented, because from the model's side nothing was invented: it produced the most plausible completion of a brief-shaped document.

This is a specific failure, not general unreliability. The model is good at structure and bad at knowing what you actually observed. A brief is the one document where that split matters most, because its entire job is to establish that a problem is real. A PRD written on a shaky premise produces a well-organised feature nobody needed; a brief written on a shaky premise produces the roadmap slot that funds it.

The tell is uniform confidence. Read your draft and look for sentences where the certainty level does not vary. Real evidence is lumpy: you know the ticket count precisely, you know the revenue impact roughly, and you do not know the segment breakdown at all. A draft where every claim lands with equal weight has been smoothed, and the smoothing is where the guessing went.

How do you draft a brief with AI without inheriting its confidence?

Change the order of operations. Most people describe the idea and ask for a brief. Instead, paste the raw material first, the tickets, the interview notes, the funnel drop-off numbers, the sales call summary, and ask the model to write only what that material supports, marking every claim it cannot trace back to a line you gave it.

Then run three passes that are genuinely worth the tokens:

• The provenance pass. Ask the model to annotate each sentence in the evidence section with the specific input it came from, and to list the sentences with no source. Delete that list or go find the data.
• The objection pass. Ask for the strongest case against the brief from the person who has to give up the roadmap slot. A model is unusually good at this because it has no stake in your idea, and the best objection almost always belongs in the brief itself rather than being discovered in the meeting.
• The compression pass. Ask it to cut the draft by forty percent without losing a claim. What survives is close to the real brief, and what it cuts first is usually the padding you wrote to sound sure.

Notice that none of those three asks the model for an opinion about whether the idea is good. That question has no grounding in anything it can check, and the answer will be agreeable.

What does the brief decide that the PRD cannot?

Whether to spend the team. A PRD assumes the answer is yes and gets specific about scope; the brief is where no is still available and cheap. That makes the "what we are not doing instead" line the most load-bearing sentence in the document, and the one people leave out most often, because naming the thing you are displacing turns a pleasant conversation into a real trade.

The same discipline runs through Builders Camp's Product Strategy bootcamp, which spends its live sessions on strategic choices and trade-offs rather than on documentation, and whose practical challenge hands you a founding team split three ways on a Series B decision with 14 days on the clock. There is no format fix for that situation. Somebody has to write down which bet they recommend and what it costs to be wrong.

Where does an AI brief actually save you time?

On the second draft, not the first. The first draft is where the judgement lives and where a model's guesses are most expensive. The second draft is mechanical: tightening a paragraph, finding the four sentences that say the same thing, rewriting the ask so a VP reading it on a phone gets the decision in the first line. That work is real and a model does it faster than you do.

It also helps in a way people underuse: reading the brief back as a specific hostile reader. Give it the role, the incentive, and the thing that reader is protecting, then ask what they push back on. The output is not a prediction of the meeting. It is a list of the places your argument is thin, arriving a day earlier than it otherwise would.

Who this is for, and who it is not for

This fits a product manager who has to win a roadmap slot before writing requirements, the situation Builders Camp's Product Manager Foundations bootcamp covers across 2 weeks and 4 live sessions, from framing a problem and sizing the opportunity through to shipping and iterating. Its practical challenge runs six connected steps that produce six artifacts in sequence, a problem statement, a research summary, a prototype brief, a PRD, a metrics framework and a growth plan, which is the same ordering this page argues for: the brief earns the PRD, not the other way round. People newer to product usually meet it as part of the Product Management Starter Track, which sequences foundations alongside discovery and communication.

It is a weaker fit if you already have sign-off and a deadline. At that point the brief is a formality and your time goes into the PRD and the user stories underneath it. It is also the wrong document for pitching to a room rather than a person: that is a one-pager, which optimises for persuasion in a meeting rather than for a written decision you can point at three months later.

Write the brief, then decide whether the PRD is worth writing

Set the test before you draft: name the one fact that, if false, kills the idea. Then write the brief so that fact is the most heavily evidenced line on the page, and let the AI pass do everything except supply it. Most briefs that fail review do not fail on prose quality. They fail because that line was never identified, so nobody noticed it was missing.

See the Product Manager Foundations bootcamp

For the document the brief hands off to, see the PRD template. For the sequenced path through discovery, strategy and delivery, see the Product Management Starter Track, and for the planning artifact the brief eventually feeds, the product roadmap template.