# Full PRD Template

This Product Requirements Document converts validated intent into a buildable contract. Replace every bracketed field. If something is unknown, write **TBD**, assign an owner, and add a decision date.

[Kit README](README.md) · [Project Overview](Project%20Overview.md) · [PRD](Full%20PRD%20Template.md) · [Master Build Prompt](Master%20Build%20Prompt.md) · [Completion Checklist](Project%20Completion%20Checklist.md)

## 1. Document Control

| Field | Value |
| --- | --- |
| Product | [PROJECT NAME] |
| Owner | [PRODUCT OWNER] |
| Version | [0.1] |
| Status | [Draft / Review / Approved] |
| Last updated | [YYYY-MM-DD] |
| Target release | [DATE OR WINDOW] |

## 2. Product Summary

- **Description:** [PROJECT DESCRIPTION: two sentences explaining user, task, and outcome]
- **Primary user:** [TARGET USERS]
- **Problem:** [MAIN PROBLEM + evidence]
- **Value proposition:** [WHY THIS APPROACH IS BETTER]
- **Business or learning goal:** [GOAL]
- **Non-goals:** [WHAT VERSION 1 WILL NOT DO]

## 3. Evidence and Assumptions

| Statement | Evidence or Assumption | Confidence | Validation Action | Owner / Date |
| --- | --- | --- | --- | --- |
| [STATEMENT] | [SOURCE OR ASSUMPTION] | [L/M/H] | [ACTION] | [OWNER / DATE] |

## 4. Users and Jobs

Prioritize these roles as a starting point: first-time user granting only necessary permissions; daily mobile user working with one hand; returning user reconnecting after offline activity. For each, document trigger, current behavior, desired outcome, environment, permissions, accessibility needs, and why the role belongs in version 1.

## 5. Functional Requirements

### FR-01 — Native-feeling navigation

- **User story:** As [ROLE], when [TRIGGER], I want [BEHAVIOR], so that [OUTCOME].
- **Rules:** [VALIDATION, PERMISSIONS, LIMITS, AND STATE CHANGES]
- **States:** [DEFAULT, LOADING, EMPTY, SUCCESS, ERROR, OFFLINE/STALE IF RELEVANT]
- **Acceptance:** Given [PRECONDITION], when [ACTION], then [OBSERVABLE RESULT].
- **Telemetry:** [EVENT, ALLOWED PROPERTIES, AND PURPOSE]

### FR-02 — Progressive onboarding

- **User story:** As [ROLE], when [TRIGGER], I want [BEHAVIOR], so that [OUTCOME].
- **Rules:** [VALIDATION, PERMISSIONS, LIMITS, AND STATE CHANGES]
- **States:** [DEFAULT, LOADING, EMPTY, SUCCESS, ERROR, OFFLINE/STALE IF RELEVANT]
- **Acceptance:** Given [PRECONDITION], when [ACTION], then [OBSERVABLE RESULT].
- **Telemetry:** [EVENT, ALLOWED PROPERTIES, AND PURPOSE]

### FR-03 — Account or guest mode

- **User story:** As [ROLE], when [TRIGGER], I want [BEHAVIOR], so that [OUTCOME].
- **Rules:** [VALIDATION, PERMISSIONS, LIMITS, AND STATE CHANGES]
- **States:** [DEFAULT, LOADING, EMPTY, SUCCESS, ERROR, OFFLINE/STALE IF RELEVANT]
- **Acceptance:** Given [PRECONDITION], when [ACTION], then [OBSERVABLE RESULT].
- **Telemetry:** [EVENT, ALLOWED PROPERTIES, AND PURPOSE]

### FR-04 — Offline cache and sync queue

- **User story:** As [ROLE], when [TRIGGER], I want [BEHAVIOR], so that [OUTCOME].
- **Rules:** [VALIDATION, PERMISSIONS, LIMITS, AND STATE CHANGES]
- **States:** [DEFAULT, LOADING, EMPTY, SUCCESS, ERROR, OFFLINE/STALE IF RELEVANT]
- **Acceptance:** Given [PRECONDITION], when [ACTION], then [OBSERVABLE RESULT].
- **Telemetry:** [EVENT, ALLOWED PROPERTIES, AND PURPOSE]

### FR-05 — Optional push notifications

- **User story:** As [ROLE], when [TRIGGER], I want [BEHAVIOR], so that [OUTCOME].
- **Rules:** [VALIDATION, PERMISSIONS, LIMITS, AND STATE CHANGES]
- **States:** [DEFAULT, LOADING, EMPTY, SUCCESS, ERROR, OFFLINE/STALE IF RELEVANT]
- **Acceptance:** Given [PRECONDITION], when [ACTION], then [OBSERVABLE RESULT].
- **Telemetry:** [EVENT, ALLOWED PROPERTIES, AND PURPOSE]

### FR-06 — Permission education

- **User story:** As [ROLE], when [TRIGGER], I want [BEHAVIOR], so that [OUTCOME].
- **Rules:** [VALIDATION, PERMISSIONS, LIMITS, AND STATE CHANGES]
- **States:** [DEFAULT, LOADING, EMPTY, SUCCESS, ERROR, OFFLINE/STALE IF RELEVANT]
- **Acceptance:** Given [PRECONDITION], when [ACTION], then [OBSERVABLE RESULT].
- **Telemetry:** [EVENT, ALLOWED PROPERTIES, AND PURPOSE]

### FR-07 — Touch and accessibility support

- **User story:** As [ROLE], when [TRIGGER], I want [BEHAVIOR], so that [OUTCOME].
- **Rules:** [VALIDATION, PERMISSIONS, LIMITS, AND STATE CHANGES]
- **States:** [DEFAULT, LOADING, EMPTY, SUCCESS, ERROR, OFFLINE/STALE IF RELEVANT]
- **Acceptance:** Given [PRECONDITION], when [ACTION], then [OBSERVABLE RESULT].
- **Telemetry:** [EVENT, ALLOWED PROPERTIES, AND PURPOSE]


## 6. Core User Flow

1. [ENTRY POINT]
2. [IDENTITY, CONTEXT, OR ONBOARDING]
3. [PRIMARY INPUT]
4. [SYSTEM PROCESSING]
5. [USER REVIEWS OR CONFIRMS]
6. [SUCCESS RESULT]
7. [RETURN, SHARE, EXPORT, OR NEXT ACTION]

Define alternate flows for invalid input, permission denial, empty data, dependency timeout, partial success, cancellation, and retry.

## 7. Information and Interface Requirements

- **Navigation:** [TOP-LEVEL AREAS AND ROLE DIFFERENCES]
- **Screens or surfaces:** [LIST WITH PURPOSE]
- **Design style:** [DESIGN STYLE explained through hierarchy, density, type, color, motion, and examples]
- **Accessibility:** keyboard/touch access as applicable, visible focus, semantic names, text alternatives, non-color cues, readable contrast, zoom/reflow, reduced motion.
- **Domain direction:** thumb-reachable actions, 44–48 px minimum targets, safe-area support, platform-aware navigation, clear permission rationale, and resilient offline states.

## 8. Data and API Requirements

Primary records: User, Device, Session, LocalRecord, SyncOperation, NotificationPreference. For each define owner, fields, types, required status, relationships, lifecycle, retention, deletion, sensitivity, and indexes. Candidate interfaces include POST /auth/session; GET /sync/changes; POST /sync/batch; PUT /users/me/notifications; remove any interface not justified by a real client boundary.

## 9. Technical Requirements

- **Preferred stack:** [PREFERRED TECH STACK + reason]
- **Supported environments:** [BROWSERS, DEVICES, OPERATING SYSTEMS, OR CLIENTS]
- **Performance budgets:** [STARTUP/LCP, API P95, BUNDLE, MEMORY, JOB TIME]
- **Availability and recovery:** [TARGET, BACKUP, RESTORE, ROLLBACK]
- **Observability:** [LOGS, METRICS, TRACES, ALERT OWNERS]
- **External dependencies:** [SERVICE, PURPOSE, LIMITS, FALLBACK]

## 10. Security and Privacy

Apply: secure credential storage; permission minimization; certificate-backed HTTPS; local database protection; account deletion flow. Add a data inventory, permission matrix, abuse cases, secrets plan, retention schedule, deletion behavior, incident owner, and approval points for consequential actions.

## 11. MVP and Roadmap

**MVP:** onboarding; core tab navigation; one complete user task; local persistence; authentication if required; offline and error states; test-build distribution. **Deferred:** widgets; wearable support; advanced background sync; deep links; tablet-specific layouts. Each future feature needs new evidence and must not be presented as available before implementation.

## 12. Success Metrics

- onboarding completion: [definition], [baseline], [target], [source], [review cadence].
- core-action completion: [definition], [baseline], [target], [source], [review cadence].
- crash-free sessions: [definition], [baseline], [target], [source], [review cadence].
- sync failure rate: [definition], [baseline], [target], [source], [review cadence].

## 13. Risks

- **asking for permissions too early:** likelihood [L/M/H], impact [L/M/H], prevention [ACTION], detection [SIGNAL], owner [OWNER].
- **data conflicts after offline use:** likelihood [L/M/H], impact [L/M/H], prevention [ACTION], detection [SIGNAL], owner [OWNER].
- **platform-specific layout bugs:** likelihood [L/M/H], impact [L/M/H], prevention [ACTION], detection [SIGNAL], owner [OWNER].
- **store rejection:** likelihood [L/M/H], impact [L/M/H], prevention [ACTION], detection [SIGNAL], owner [OWNER].
- **notification fatigue:** likelihood [L/M/H], impact [L/M/H], prevention [ACTION], detection [SIGNAL], owner [OWNER].

## 14. Release Acceptance

- [ ] All P0 user stories pass in the supported environments.
- [ ] Authorization and data-isolation tests pass.
- [ ] Failure and recovery paths preserve valid work.
- [ ] No fake live data or unfinished interactions are presented as complete.
- [ ] Accessibility and performance budgets pass or have approved exceptions.
- [ ] Deployment, monitoring, backup, rollback, support, and ownership are documented.
- [ ] A final completion report maps every requirement to evidence.