How to write a one-page PRD for your AI product

A product requirements document has a bad reputation — founders picture a fifty-page spec nobody reads. That version deserves the reputation. But a one-page PRD is a different tool: a forcing function that turns a fuzzy idea into something a designer or engineer can start on tomorrow. If you can't fit your product on one page, you don't yet understand it well enough to build it.

What a one-page PRD is actually for

It's not documentation. It's a decision. The value isn't the artifact; it's the arguments you're forced to settle while writing it — who this is for, what it does first, what it deliberately won't do. A good PRD is mostly cuts.

Keep it to a single page on purpose. The constraint is the point: it stops you hiding a vague idea behind volume, and it keeps everyone pointed at the same small target.

The structure

Problem. One or two sentences: what painful, specific problem does this solve, for whom? If it reads like a category ("productivity for teams"), it's too vague. Name the person and the pain.

Target users. Who feels this most acutely? Narrow it until it's almost uncomfortable. "Med students revising for board exams" beats "students." The narrower the user, the sharper every downstream decision.

The core loop. The single sequence the user repeats to get value: discover → decide → act. This is the spine of the product. If you can't name it in one line, stop and figure it out before writing anything else — it's the core loop that decides whether your MVP ships.

MVP scope. Two short lists: Build now (the few things needed to complete the loop once, for real) and Later (everything else, parked without guilt). Be ruthless — most of your instincts belong in "Later."

Key risks. The two or three things that could sink this — the riskiest assumption, the hardest technical unknown, the place the AI is most likely to be wrong. Naming them beats pretending they aren't there.

Success signal. One metric that tells you the loop is working — not vanity numbers, but the behaviour that proves value (e.g. "60% of users who run it once come back within a week").

Write it specific, or don't bother

The failure mode of every PRD is abstraction. "Users can manage their content" tells a builder nothing. "A user pastes a draft, gets three rewrite suggestions, and accepts or edits one" tells them exactly what to make. Write at the level of concrete actions, not capabilities.

For an AI product, add one more discipline: say what the AI does and what happens when it's wrong. "Suggests answers" is half a spec. "Suggests answers, flags low confidence, and lets the user edit before saving" is the real one. The error path is part of the product, not an afterthought — design for the model being wrong from the start.

Common mistakes

The three that show up most: a problem statement that's really a solution in disguise; an MVP scope with more than a handful of "Build now" items; and no named risks, which always means the risks are just hidden. If your "Build now" list has ten things, you haven't scoped an MVP — you've written a wish list.

The point

A one-page PRD won't capture everything, and it isn't meant to. It's meant to make the handful of decisions that matter impossible to dodge, and to fit them somewhere everyone can see. Get that right and the build has a spine. Skip it and you'll discover the missing decisions the expensive way — halfway through development.

Want a structured draft in two minutes? The free Idea → one-page PRD tool turns a few sentences into a real brief — problem, users, core loop, scope, and risks. When you're ready to pressure-test and build it, that's where AI Product Strategy comes in.