PRD template for an MVP: structure, worked example and mistakes

In short: a PRD (product requirements document) for an MVP needs six things: the problem, the user, a ranked list of requirements, the data model, acceptance criteria written before the build, and an explicit "not in v1" list. Everything else is optional. Below is the template I use, a worked example, and the mistakes that make quotes impossible to compare.

Why an MVP needs a PRD at all

When the brief is a conversation, every vendor quotes the product they imagined. The difference between their imagination and your intent gets settled later, as a change request, at your expense. A written PRD does one job: it lets you put three vendors against the same document so that the difference between their quotes becomes information instead of noise.

It does not need to be long. For an MVP, ten to fifteen pages is usually enough. What matters is that each section can be tested: someone who has never met you should be able to read it and say what will be built and how you will know it works.

The template

1. Problem and context. What does not work today, with a number if you have one (hours lost, orders mislaid, data re-keyed). Two paragraphs maximum.
2. Users and roles. Who uses the product, and what each role is allowed to do. Roles are where hidden scope lives: an admin back-office, a manager view and a customer view are three products' worth of screens.
3. Requirements, ranked. Each requirement as one sentence, classified must-have, should-have or later. The ranking is the part a vendor quotes against, and the part that survives the first budget conversation.
4. Data model. The entities, how they relate, and the fields that matter. Most expensive late changes in a software project are data-model changes dressed as features.
5. Acceptance criteria. For each must-have: the checks that must pass for it to count as done, written so a non-developer can run them.
6. Out of scope for v1. An explicit list. It prevents more disputes than the inclusion list.
7. Constraints and integrations. Existing systems, legal obligations, languages, hosting, availability.
8. Governance. Who decides, how fast vendor questions get answered, how change requests are costed.

A worked example: acceptance criteria

This is an illustrative example for a queue-management app for a medical practice, in the spirit of a platform I delivered (see the Doctifile case study). Compare the weak and the testable version of the same requirement.

Weak: "Patients can check in remotely."

Testable:

• A patient with an appointment can check in from their phone up to 30 minutes before the slot, without creating an account.
• After check-in the patient sees their position in the queue, refreshed without reloading the page.
• If the practice marks the doctor as running late, every checked-in patient receives a notification within one minute.
• A patient who has not checked in 10 minutes after their slot is flagged to the receptionist, not removed from the queue.

The weak version can be "delivered" by a form with one button. The testable version cannot be argued about at acceptance, because each line is a pass or a fail.

What a PRD does to the quotes you receive

One founder I worked with had two quotes for the same mobile app: $18,000 and $47,000. Writing the specification took eight days and showed that the cheaper vendor had scoped no offline mode, no role management and no admin back-office, about 60% of the product by effort. The expensive quote was not expensive; the cheap one was quoting something else. Without the document, the founder would have picked on price.

Five mistakes that make a PRD useless

• Describing the solution instead of the need. "A blue button top-right that exports to Excel" closes the door on a better answer. "The manager can take the filtered list away and work on it offline" leaves it open.
• No acceptance criteria. Written afterwards, they describe whatever was built. Written first, they are a contract.
• Everything is a priority. If no requirement is marked "later", the vendor will price all of it and you will pay for features nobody uses at launch.
• Silence on data. Who migrates the existing records, from where, and who cleans them. This is the most common end-of-project argument.
• No out-of-scope list. What is not written down gets built as a "clarification", then billed.

Standards worth knowing (and how much to follow them)

If you want a formal reference, ISO/IEC/IEEE 29148:2018 defines what a good requirement looks like: necessary, unambiguous, verifiable, feasible. For quality attributes such as performance, security and maintainability, ISO/IEC 25010 gives a vocabulary. You do not need to follow either to the letter for an MVP. The one idea to take from both is verifiable: if a requirement cannot be checked, it cannot be accepted or rejected.

The test before you send it

Give the document to someone outside your business and ask two questions: what has to be built? and how will we know it worked? If they cannot answer the second, the document is not ready.

Want it written for you?

Writing the PRD is a ten-day job in the Technical Specification & PRD offer: ranked requirements, data model, acceptance criteria, a build estimate and a tender-ready package. I write the specification; I do not bid on the build, so the document stays neutral. If you already have a written scope and want it checked, the Delivery Risk Audit is the better fit. For related reading, see How to write a specification for an IT project.