Skip to main content

Good PRD Examples (Small → Medium → High Complexity)

Goal: provide real references so programmers can convert requirements into implementation without ambiguity.

🔹 1) SMALL PROJECT — Internal Notes App​

Summary​

Internal team notes app (CRUD + tags + search).

Scope​

  • Auth login/logout
  • Create/edit/delete notes
  • Tagging
  • Search note title

Sample PRD​

### FR-SM-001: Create Note
- Goal: users can save quick notes.
- Actor: authenticated user
- Trigger: click "New Note" button
- Input: title, content, tags[]
- Output: new note saved and shown in list
- Acceptance Criteria:
  - [ ] title is required
  - [ ] note saved in < 1 second
  - [ ] note appears in list without full reload
- Edge Cases:
  - empty title -> 422
  - duplicate tags -> system deduplicates
- Impact Area: API, DB, UI notes list
- Risk: low

🔸 2) MEDIUM PROJECT — Approval Workflow (2-level)​

Summary​

Documents require level-1 and level-2 approval before final status.

Flow diagram​

Sample PRD​

### FR-MD-010: Two Level Approval
- Goal: ensure requests are validated in multiple layers.
- Actors: requester, approver_l1, approver_l2
- Trigger: requester submits request
- Input: request payload + approval config
- Output: status lifecycle (submitted, l1_approved, approved/rejected)
- Acceptance Criteria:
  - [ ] approver_l1 cannot be approver_l2 for the same request
  - [ ] audit trail records all approval actions
  - [ ] notification is sent to next approver on status change
- Edge Cases:
  - approver on leave -> fallback approver
  - request edited after submit -> reset approval
- Impact Area: API, DB workflow tables, notification, activity log
- Risk: medium

🔺 3) HIGH / VERY COMPLEX — Multi-tenant Procurement Platform​

Summary​

Multi-tenant procurement platform with vendor management, tenders, dynamic approval matrix, budget control, and compliance audit.

Flow diagram (summary)​

Sample PRD​

### FR-HX-120: Dynamic Approval Matrix by Amount + Department + Risk
- Goal: automatic approval based on complex cross-tenant rules.
- Actors: requester, finance, procurement, legal, approvers
- Trigger: PR submit / amount change / risk category change
- Input:
  - tenant_id
  - department_id
  - amount
  - risk_level
  - category
- Output:
  - generated approval chain
  - SLA timeline per approval stage
  - immutable audit record
- Acceptance Criteria:
  - [ ] matrix generator is deterministic (same input => same output chain)
  - [ ] SLA breach triggers escalation
  - [ ] every chain change is recorded with before/after diff
  - [ ] simulation mode is available before submit
- Edge Cases:
  - policy rule conflict -> resolve by priority
  - approver role revoked during progress -> auto reroute
  - tenant custom override -> fallback to global policy when invalid
- Impact Area:
  - Rule engine
  - Workflow API
  - DB policy + history + audit
  - Notification/event bus
  - Reporting
- Risk: high

✅ Important notes​

As project complexity grows:

  1. split requirements per module,
  2. avoid one giant PRD,
  3. create FR per capability, and
  4. include flow diagram + data impact for each module.