How to Write a One-Page PRD and User Stories with Acceptance Criteria

A dental clinic's front desk spends most mornings on the phone rescheduling appointments. The product manager writes a four-page document describing a "patient portal", and three weeks later the engineers ask the first question that matters: can a patient move an appointment that is tomorrow? Nobody knows, because the document describes a vision and not the rules. A product requirements document earns its keep when it settles exactly those questions on one page, before code is written.

What a PRD is for

A PRD (product requirements document) is a shared reference that explains why you are building something, what success looks like, what is in and out of scope, and how the team will know when it is done. It is not a contract and it is not a specification for every pixel. Its main reader is an engineer who wants to start building, and its main purpose is to surface disagreements while they are cheap to resolve.

One page is a discipline, not a rule. Long documents hide the key decisions and nobody reads them twice. If a section needs more room, link to a separate design file or research note and keep the page itself short enough to read in five minutes.

The one-page template

TITLE:            <feature or project name>
OWNER / DATE:     <product manager>, <last updated>
STATUS:           Draft | In review | Approved

1. PROBLEM
   Who has the problem, in what situation, and what does it cost them?
   Evidence: <interview quotes, ticket counts, links>

2. GOAL AND SUCCESS METRIC
   Goal: <one sentence outcome>
   Primary metric: <name, current value, target, date>
   Guardrail metric: <what must not get worse>

3. NON-GOALS
   - <things people may assume are included but are not>

4. USERS AND STORIES
   Story 1: As a <user>, I want <action> so that <benefit>.
     Acceptance criteria: Given / When / Then ...
   Story 2: ...

5. REQUIREMENTS AND RULES
   - Business rules the system must enforce
   - Edge cases decided (and who decided)

6. DESIGN AND DEPENDENCIES
   Link to designs. Other teams or systems this relies on.

7. RISKS AND OPEN QUESTIONS
   - <question> | owner | answer needed by <date>

8. ROLLOUT
   How it ships (flag, pilot group, full), and what happens if it fails.

A filled example: self-serve rescheduling

OWNER / DATE:  Product, 12 March | STATUS: In review

1. PROBLEM
   Patients who need to move an appointment must phone the front desk,
   which is only staffed 9-5. Reception reports that rescheduling calls
   take up much of the morning, and patients tell us they "gave up and
   just did not come". Evidence: 7 patient interviews, reception log.

2. GOAL AND SUCCESS METRIC
   Goal: let patients move an appointment without phoning.
   Primary metric: share of reschedules completed online (today 0%,
   target 40% within 3 months of launch).
   Guardrail: no-show rate must not rise.

3. NON-GOALS
   - Booking a first-time appointment online.
   - Changing the dentist or the treatment type.
   - Payments or insurance changes.

4. USERS AND STORIES
   Story 1: As a returning patient, I want to move my appointment to a
   different free slot, so that I do not need to phone during office hours.
     AC1  Given I have a confirmed appointment more than 24 hours away,
          when I choose a new free slot with the same dentist, then the
          appointment moves and I see a confirmation.
     AC2  Given my appointment is less than 24 hours away, when I open
          it, then I see the clinic phone number and no reschedule button.
     AC3  Given I confirm a new slot, when someone else has just taken
          it, then I am shown the next free slots and nothing changes.

   Story 2: As a receptionist, I want to be told when a patient moves
   an appointment, so that I can keep the daily schedule accurate.
     AC1  Given a patient reschedules, when it completes, then the old
          slot shows as free and the new one as booked within one minute.

5. REQUIREMENTS AND RULES
   - Maximum 2 online reschedules per appointment (clinic decision).
   - Confirmation sent by SMS and email.

6. DESIGN AND DEPENDENCIES
   Figma link. Depends on the scheduling system's slot API.

7. RISKS AND OPEN QUESTIONS
   - Can emergency slots be offered online? | clinic manager | 20 March
   - Do we need patient consent text for SMS? | legal | 25 March

8. ROLLOUT
   Feature flag on for two clinics for 2 weeks, then all clinics.
   Turn-off plan: flag off, front desk resumes phone-only.

Notice what the example does. The 24-hour rule and the two-reschedule limit are written as rules. The non-goals stop scope creep before it starts. The open questions have owners and dates, so they will not sit forever. And each story has criteria that a tester could check.

Writing user stories that survive contact with engineers

The classic format is "As a <user>, I want <action> so that <benefit>". The "so that" clause matters most: it tells the engineer what the user is really trying to achieve, which lets them propose a simpler way. A story missing it is just a task.

A good story is independent, negotiable, valuable, estimable, small and testable. Together these are known as INVEST. If engineers cannot estimate a story, it is too vague. If it takes more than a few days, it is too big and should be split, for example by user type, by rule, or by a happy path first and edge cases second.

Acceptance criteria in Given, When, Then

Acceptance criteria describe observable behaviour that must hold for the story to count as done. Given/When/Then keeps each one short: Given a starting state, When the user does something, Then the system responds in a specific way. Each criterion should be checkable by someone who has not read your mind.

Reviewing the PRD with your team

Do not email the document and wait. Walk the engineers and the designer through it in a short meeting and ask them to read it as sceptics. A useful prompt is: "If you had to start building tomorrow, what is the first question you would ask me?" Every answer is a gap in the page. Fix the gap in the document itself, not in a chat thread, so the next reader sees the decision.

Expect pushback on scope and ask for it. An engineer who says "the 24-hour rule means we need a clock check on the server, not the phone" has just saved you a bug that would have appeared in testing. Record the change with a date and the name of the person who decided, and move the status from Draft to Approved only when the open questions that block building have answers.

Common mistakes

• Writing the solution as the requirement. Symptom: engineers build exactly the button you described and miss a cheaper option. Describe the outcome and let the team propose the how.
• No non-goals. Symptom: mid-sprint requests such as "can it also book new patients?" Write what is out of scope.
• Unmeasurable criteria. Symptom: QA and the PM disagree about whether it is done. Use numbers, states and specific messages.
• A PRD no one updates. Symptom: the document says one thing and the product does another. Keep a changelog line at the top and update it when decisions change.
• Skipping open questions. Symptom: the team stops in week two to wait for an answer from legal. List questions up front with an owner and a date.

How this shows up in real projects and interviews

Real teams vary widely. Some use short PRDs, some use tickets with acceptance criteria, some rely on design files and conversation. Whatever the format, engineers want the same answers: what problem, what is in scope, what are the rules, and how will we know it works. Learn the template, then shorten it to what your team will actually read.

In product manager interviews you may be asked to write a user story or acceptance criteria on the spot. Interviewers look for a clear user, a benefit, and at least one edge case you thought of without being prompted. Clear writing helps a great deal here; the Clear Workplace Writing lesson covers the habits that carry over.