How to write a product requirements document when you’re not a PM

A founder we work with sent us a fourteen-page PRD last summer. Cover sheet, glossary, OKRs, three personas, sprint slicing, success metrics, a Figma prototype the team had not actually built, and a section called “non-functional requirements” that read like it had been copied from an enterprise template the night before. The team they were briefing was three engineers and a half-time designer at a shop they had never worked with. The first call about scope ran for two hours and resolved nothing.

That document was not a product requirements document. It was a PM artifact written in a vacuum, by a founder who had read enough Atlassian and Notion guides to know what the section headers should be, and not enough about her own constraints to know which of those sections she actually needed.

If you are searching for how to write a product requirements document, you are almost certainly in one of two situations. You are a product manager at a company that already has an engineering team, in which case the existing guides on the internet are written for you. Or you are a non-technical founder briefing a developer, a small studio, or your first engineering hire, and the existing guides assume a context you do not have. This piece is for the second group.

The honest definition of a PRD

A product requirements document is a written agreement between the person who decides what gets built and the people who build it. That is the entire job. Everything else, the personas and the user stories and the analytics dashboards, is supporting evidence. Most PRD guides on the internet inflate the supporting evidence into the document itself, because most PRD guides are written for a context where alignment across a fifteen-person product organization is the actual problem.

Your problem is different. You are not aligning fifteen stakeholders. You are handing a small build team a clear enough picture of what to build and why, so they can make the dozens of small decisions they are about to make in your absence without sending you a Slack message every twenty minutes. The document needs to do two things well: tell them what the customer should be able to do, and tell them which trade-offs you have already decided so they do not surprise you later.

That is a much smaller document than the templates suggest. Most non-technical founders we work with end up at four to seven pages, not twenty. The document gets shorter when you understand which sections earn their place.

Six sections that earn their place

Every founder PRD we have seen work in the last three years has these six pieces, in roughly this order. Headers can be renamed. The substance has to be there.

1. The customer and the moment

One paragraph, no more. Who is the user, and what are they doing in the thirty seconds before they encounter your product. Not a persona deck. A scene.

A solo bookkeeper at a small accounting firm has just received fourteen client invoices for the month, each in a different format. She needs to record them all in QuickBooks before her end-of-week reconciliation. Today this takes her three hours. She is at her desk with the invoices open in fourteen browser tabs.

That paragraph does more work than three pages of personas. The team building the product now knows what kind of friction matters and what does not. Speed of upload matters. Pretty animations do not. The bookkeeper is not going to forward the product to a friend on a feature comparison spreadsheet, so a polished marketing surface is not the priority for v1.

2. The decision you have already made

Founders skip this section because it feels obvious to them. It is not obvious to the build team. State it plainly: what is the build, what is not the build, and what are the assumptions that will fail if anyone changes them.

If you are paying a vendor, every assumption you do not write down becomes a question they ask you later, which becomes a delay, which becomes a re-scope. Writing the assumptions is cheaper than relitigating them.

A clean version reads like this: we are building a web app, not a mobile app, because our users sit at desks. We are integrating with QuickBooks Online only, not Xero, not Sage, because eighty percent of our pipeline is QBO. We are not building a billing system in v1; we will charge invoices manually for the first six months. We are targeting Chrome and Safari on desktop. Mobile and Edge are not v1.

That paragraph saves four hours of meetings.

3. The smallest version that earns money or learning

This is what real product people call the MVP, and it is the part most founders get wrong. A v1 is not “everything in the long-term vision but smaller.” A v1 is the minimum surface area that lets you charge a real customer or kill the idea. Most things you want to put in v1 are not in v1.

Write this section as a list of user-visible jobs that the v1 must complete end to end. Not features. Jobs. “Upload an invoice and have it appear in QuickBooks five minutes later” is a job. “Drag-and-drop file uploader” is a feature. The build team can pick the right feature to deliver the job. They cannot pick the right job to deliver, because they do not know which jobs your customers will pay for.

A pre-seed v1 usually has between three and six jobs. If your list is twelve, you are not writing a v1; you are writing a wish list. Cut.

4. The trade-offs you are not going to argue about later

Engineers make hundreds of small decisions during a build. Most of them are invisible to you. A few of them are not, and the ones that are not will become arguments if you do not write them down up front.

Three trade-offs come up on almost every build:

The first is scope versus polish. You can have a thin slice that does ten things passably, or two things beautifully. Pick. Your build team will pick for you if you do not, and they will not pick what you would pick.

The second is speed versus durability. You can ship something held together with duct tape in four weeks, or something maintainable in eight. Pick. We have seen founders insist on the four-week version, then sprint to ship a fundraise demo, then spend the next twelve months apologizing to engineers for the duct tape. Decide which mistake you would rather make.

The third is custom versus off-the-shelf. Every build has parts that should be bought, not built. Auth is the obvious one; nobody should be building login screens from scratch in 2026. Less obvious examples: file storage, transactional email, payments, search. Tell the build team which boundaries you want them to draw, or they will draw them in places that surprise you.

5. What success looks like in week eight

Pick one observable outcome that means the v1 worked. Not a KPI dashboard. One sentence.

A real one from a fintech we worked with last year: “By week eight, three paying customers have completed at least one full month-end close using the product, end to end, without our support team intervening.” That sentence is a contract. Everyone on the build team can hold it in their head and use it to settle scope arguments. “Does this feature help us hit the close-without-support metric?” If yes, build it. If no, defer it.

Most founder PRDs we read do not have this section. They have a metrics dashboard with twelve KPIs and a vague aspiration. That is not a target; it is wishful bookkeeping.

6. What’s out of scope, and why

The things you are not building deserve their own section, because they will otherwise creep back in during the build. Write them down. Write them with the reason. “Mobile app: no, because users sit at desks.” “Multi-currency support: no, because v1 customers are US-only.” “SSO: no, because v1 customers are sole proprietors.”

Future-you will thank present-you for this section in week six, when an investor asks why you do not have a mobile app and you can answer in a sentence instead of going back to the document.

Six sections that should not be in your founder PRD

These belong in PRDs written for established product orgs. They do not belong in a non-technical founder’s brief. Putting them in is the most reliable way to spend three weeks writing a document and still not have a buildable plan.

A glossary. If you need a glossary, you have not pruned the document hard enough. The build team should not need to look up a term. Use the words their engineers and your customers actually use.

Personas. Personas are a tool for prioritizing across many user types. At pre-seed, you have one user type, and you should know them by name. Write the customer-and-moment paragraph instead.

OKRs. OKRs are an org-alignment tool. A founder briefing a four-person team does not need them. The “what success looks like in week eight” sentence does the same job.

A roadmap beyond v1. Roadmaps after v1 are speculation. Any vendor or hire who treats your post-v1 roadmap as a real plan is not paying attention. Keep the roadmap out of the PRD; what is in v1 is the plan, what is after v1 is a hypothesis.

Detailed user stories with acceptance criteria. Acceptance criteria are how PMs translate a roadmap to a tracker. A small build team does not need them up front; they will write the acceptance criteria themselves, against your six sections, and ask you when something is ambiguous. That is faster.

Wireframes the team did not draw. If you sketched the screens in Figma yourself, do not put them in the PRD. The build team will redraw them, and they should. Showing your sketch tends to anchor everyone to a layout that may not survive contact with the actual implementation. Describe the user’s job; let the team design the screen.

A worked example: what one founder PRD looked like

The bookkeeping example above belonged to a real founder. Her v1 PRD, after we cut it down, was five pages. The structure was exactly the six sections above. Three jobs in the v1 list: upload invoices, see them in QuickBooks within five minutes, send the bookkeeper a Slack message when something fails. Two trade-offs decided up front: ship in six weeks instead of three, hold the line on a single QBO integration. One success metric: ten paying firms doing month-end close without support by week ten.

The build took eight weeks instead of six. One job slipped to a v1.5 (failure notifications). Ten paying firms hit the metric by week twelve. The PRD held up. The fourteen-page version we replaced it with would not have, because too many of its sections were arguments waiting to happen.

That is the test of a good founder PRD: did it survive contact with the build, and did anyone need to relitigate its assumptions in the middle of week four. If yes, the document was too long, too vague, or both.

When to write more, and when to write less

The six-section template is not a hard rule. Two situations call for a longer document.

The first is regulated industries. If you are building in healthtech, fintech, or anywhere a compliance team is going to look at the system, you will need a separate document for that team and a section in the PRD that says “compliance review is in scope, see appendix.” Do not skip this; the cost of finding a compliance gap in week six is much higher than the cost of writing it in week zero.

The second is when you are paying a fixed-price vendor. Fixed-price contracts force every ambiguity into the contract negotiation, because the vendor will charge for anything not specified. In that case, the PRD becomes a contract document, and you write it longer because each unwritten line is a future change order. We generally recommend founders avoid fixed-price contracts at this stage for exactly this reason; build with a partner who works on time-and-materials, and the PRD can stay short.

Two situations call for a shorter document. If you are working with an engineer you trust and have shipped with before, a one-page brief with three jobs and one success metric is enough. The trust does the work the document would otherwise do. And if your v1 is genuinely a prototype, not a product, write a paragraph and a sketch and ship in two weeks. Calling that a PRD is theater.

The version you write in week one is not the version that ships

The hardest thing about writing a PRD as a non-technical founder is accepting that the document will change. The PMs writing the guides on Atlassian and Notion know this; their teams change PRDs in flight every day. Founders writing their first PRD often treat it as a one-shot deliverable, hand it over, and feel betrayed when reality forces an edit.

Write the document with one assumption: it will be wrong somewhere by the end of week two. The build team will discover something that breaks an assumption. The PRD’s job is not to be right; it is to be specific enough that being wrong shows up clearly, fast. A vague document is wrong silently. A specific document is wrong loudly, which is the kind of wrong you can fix.

If you have not written one of these before, the first version will feel uncomfortably opinionated. Good. The opposite of opinionated is “everyone has a different reading of what we are building,” which is the failure mode the document exists to prevent.

FAQ

What’s the difference between a PRD and a product brief?

In most non-technical founder contexts there is no useful difference. PMs sometimes use “product brief” for a one-page early-stage document and “PRD” for the longer version. Pick one term and stick with it; the document does the same job either way.

How long should a founder’s PRD be?

Four to seven pages for a v1 in our experience. If yours is twenty pages, the build team will not read it; they will skim the first three pages and ask you about the rest in calls.

Should I use a PRD template?

Templates are a starting structure, not a finished document. The danger is that templates lead you to fill every section, including the ones you do not need. Use the six sections above as a checklist; treat any section a template tells you to fill that is not on this list as optional.

Is AI useful for writing a PRD?

For drafting language, yes. For deciding what belongs in your v1, no. The decisions in sections two through six are yours and only yours; an LLM can help you write them down faster, but it cannot pick which trade-offs are right for your business. Use AI on the typing, not the thinking.

What if my engineer asks for more detail than the PRD provides?

Answer the question, and decide whether it belongs in the document. If it is a recurring question that another engineer will ask later, write it down. If it is a one-time clarification, answer it in Slack and move on. The PRD is a working document, not a contract.