Lean Product Requirements Document (PRD)

Template Overview

Software projects fail when requirements are ambiguous. When product managers write 40-page monolithic specifications that nobody reads, engineers build what they think was asked for, designers design conflicting flows, and the delivered product misses customer expectations.

A Lean Product Requirements Document (PRD) provides relentless clarity. It articulates the core customer problem, establishes measurable success metrics, outlines prioritized user stories with unambiguous acceptance criteria, and explicitly sets out-of-scope boundaries.

This template provides an engineering-aligned PRD framework: executive problem statements, customer persona definition, prioritized user stories, functional specifications, out-of-scope non-goals, and technical open questions.

Markdown Template Structure

Copy the block below or click Download .md File to add this template directly to your personal vault:

---
title: "PRD: [Feature / Product Initiative Name]"
date: [YYYY-MM-DD]
product_manager: "[[Lead Product Manager]]"
lead_engineer: "[[Lead Systems Engineer]]"
lead_designer: "[[Lead Product Designer]]"
target_release_milestone: "v1.5.0 Release"
prd_status: [Draft | In Review | Approved & Locked | In Development]
tags: [prd, product, requirements, specification, engineering, agile]
---

# PRD: [Feature / Product Initiative Name] — [YYYY-MM-DD]

## 1. Problem Statement & Customer Evidence
- **The Core Problem:** Knowledge workers lose valuable hours converting messy meeting notes into structured vault documentation, risking lost decisions and dropped action items.
- **Customer Evidence:** 84% of surveyed engineers in qualitative discovery reported taking manual notes during calls, causing severe cognitive fatigue and missed context.
- **Why Now:** Increasing corporate bans on cloud meeting bots have created urgent demand for private, on-device local documentation tools.

## 2. Measurable Business Goals & Success Metrics
| Metric Type | Target Metric | Baseline | Target Goal | Measurement Mechanism |
| :--- | :--- | :--- | :--- | :--- |
| **North Star** | Weekly Active Vault Template Users | 0 users (New feature) | 5,000 WAU at Day 30 | Local FTS5 usage telemetry (opt-in) |
| **Friction Metric** | Template Copy / Download Completion Rate | N/A | > 85% completion | Web event logging |
| **Quality Metric** | Zero-Egress Network Packet Integrity | 0 violations | 0 bytes external egress | Little Snitch security audit |

## 3. Prioritized User Stories & Acceptance Criteria
### User Story 1: One-Click Template Clipboard Copy (Priority: P0)
- **Story:** As a knowledge worker, I want to copy a formatted Markdown template with a single click, so I can immediately paste it into my existing vault note.
- **Acceptance Criteria:**
  - [x] 'Copy Markdown Template' button copies clean UTF-8 text to system clipboard.
  - [x] Visual feedback updates button text to 'Copied to Clipboard!' for 2.5 seconds.
  - [x] All YAML frontmatter tags and wikilinks preserve formatting.

### User Story 2: Offline Markdown File Download (Priority: P0)
- **Story:** As an Obsidian user, I want to download the template as an individual `.md` file, so I can drag it directly into my vault folder.
- **Acceptance Criteria:**
  - [x] 'Download .md File' button triggers browser file save dialog.
  - [x] Filename adheres to kebab-case convention (`[template-slug]-template.md`).

## 4. Explicit Non-Goals (Out of Scope for v1)
- *Non-Goal 1:* Cloud account synchronization or multi-user web editing.
- *Non-Goal 2:* Proprietary binary template file formats (only plain UTF-8 text allowed).
- *Non-Goal 3:* Automatic template modification without user authorization.

## 5. Technical Constraints & Architecture Dependencies
- Must run as static client-side JavaScript without requiring external API endpoints.
- Must validate against Astro content collections schema and pass all 24 SEO gates.
- Related Technical Specs: [[ADR-0044]], [[RFC-Templates-Gallery]].

Filled Real-World Example

Here is a realistic example demonstrating how this template captures actual deliberations:

---
title: "PRD: Markdown Template Gallery"
date: 2026-10-05
product_manager: "[[David Park]]"
prd_status: Approved & Locked
tags: [prd, product]
---

# PRD: Markdown Template Gallery — October 5, 2026

## 1. Summary
Deliver 120 curated Markdown templates across 12 categories with client-side copy and download buttons.

## 2. Non-Goals
No cloud logins. No telemetry. 100% plain text.

When to Use and When to Avoid

When to Use

• Use at the beginning of any major feature initiative, product release, or user experience overhaul.
• Use to establish a shared contract between product management, engineering, and design teams.
• Use to define explicit acceptance criteria and protect project scope from creeping.

When to Avoid

• Avoid using for quick 2-hour bug fixes or trivial styling refactors.
• Avoid using for pure technical infrastructure decisions without user-facing scope (use [[architecture-decision-record]]).

On-Device AI Integration

Capture PRD specification sessions with Oyma on macOS:

Analyze the product requirements planning meeting transcript:
1. Synthesize the customer problem statement, supporting evidence, and strategic urgency.
2. Build the success metrics table detailing North Star, friction, and quality indicators.
3. Formulate prioritized user stories (P0, P1, P2) with concrete, testable acceptance criteria.
4. Record explicit out-of-scope Non-Goals and technical architectural dependencies.
Output in disciplined, engineering-aligned CommonMark.

Your unreleased feature specifications and proprietary product plans stay safely encrypted on your private Mac.