MVP PRD Example for a Two-Person SaaS Team
Illustrative editorial examples. The company and numbers are fictional; these are not customer outcomes or claims of validated demand.
A complete MVP specification
This editorial example describes CoachSlot, a fictional scheduling SaaS. It demonstrates a reviewable PRD; it is not a generated customer document or proof of market validation. The proposed team consists of one product-oriented founder and one engineer. Dates, costs, and demand remain to be established.
1. Problem and goal
Independent fitness coaches coordinate recurring appointments through messages. The first release should let a coach publish available slots and let a client book one without exchanging scheduling messages. The goal is to complete this workflow reliably, not build a complete coaching platform.
2. Users and permissions
A coach owns their availability and bookings. A client can book an available slot and manage that booking using a time-limited link. One coach cannot inspect another coach's bookings or client details. Support access must be deliberate and logged.
3. Core workflow
The coach signs in, sets a time zone, defines availability, and shares a booking link. The client chooses a slot and enters the minimum contact details. The system atomically reserves the slot and sends a confirmation. The coach can view and cancel the booking. Clients can cancel through their management link.
4. User stories
As a coach, I want to define my weekly availability so clients can book without contacting me. As a client, I want times shown in my time zone so I arrive at the correct time. As a coach, I want canceled slots released so another client can use them. As a client, I want a confirmation even if I close the browser after booking.
5. Acceptance criteria
| Scenario | Given / When | Expected result |
|---|---|---|
| First booking | An available slot; a client submits valid details | One booking exists and the slot becomes unavailable |
| Race condition | Two clients submit the same slot concurrently | Exactly one succeeds; the other is offered alternatives |
| Time zones | Coach and client use different time zones | Both see the same instant with their local time-zone label |
| Cancellation | A valid management link is used | The booking is canceled once and the slot is released |
| Notification failure | Delivery fails after a successful booking | The booking remains valid; delivery is retried and visible to support |
| Unauthorized access | A different coach requests booking details | Access is denied without exposing client information |
6. Functional scope
Include coach sign-in, availability editing, booking, cancellation, confirmation email, and a simple booking list. Start with one appointment duration. Define booking lead time and cancellation rules explicitly. Avoid adding optional form fields unless they are needed for the appointment.
7. Out of scope
Defer group sessions, subscriptions billed to clients, workout plans, video calls, team calendars, mobile apps, and AI coaching. Put each deferred request in a backlog with the evidence that would justify revisiting it. Do not add a feature solely because an established competitor has it.
8. Technical considerations
Use a transactional database constraint or equivalent concurrency control to prevent double booking. Store instants consistently and retain the relevant time-zone identifier. Keep email delivery separate from the booking transaction. Enforce ownership on the server. Define backup recovery and remove unnecessary personal information from logs.
9. Metrics and validation
Count activated coaches who publish availability and receive a real booking. Track booking completion, failures, and repeat weekly use. Interview pilot users about scheduling effort. A successful usability test is not a successful demand test; measure paid adoption separately.
10. Release checklist
Test the happy path, simultaneous booking, invalid links, time-zone transitions, email failure, ownership checks, and small-screen layouts. Before launch, assign an owner for support and a procedure for restoring bookings if an incident occurs. Run the first pilot with a small number of coaches before expanding.
11. Open questions
Can clients cancel at any time? Are recurring sessions required for initial value? Which regions and languages are in scope? What constitutes acceptable notification latency? Resolve these questions with pilot users and the implementation team rather than letting code silently decide them.
Use this structure
Replace the fictional scenario with your product. Keep the acceptance criteria observable, the exclusions explicit, and the open questions visible. A free outline provides the structure; Pro can draft a detailed PRD using your evaluation.