MVP PRD Example for a Two-Person SaaS Team

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.