Lean PRD Template

A Lean PRD is the short form: one team, one clear job to be done, shipped without a phased rollout or another team's roadmap moving. You write one when the feature is small enough that the real risk is not a missing section — it is the thinking a short document makes easy to skip.

When you need one

Reach for Lean when a single team owns the build end to end, the user stories fit on one screen, and nothing is waiting on another team's timeline. If the feature needs a UX flow diagram to explain, a business rule with an ID, or more than two rollout phases, it has outgrown Lean — use the Standard PRD template instead. The tell is not size, it is shape: a feature can touch thousands of users and still be lean if the logic is simple, and a feature can affect a dozen people and still need the Standard template if it is legally or technically tangled.

The template

# [Feature name] — Lean PRD
Owner: [name] · Status: [draft/review/approved]

## TL;DR
[2-3 sentences: what ships, for whom, why now.]

## Problem alignment
[The problem as a user or business outcome. Evidence: cite it. Who is affected, how often.]

## User stories
- As a [role], I can [action], so that [outcome].
- As a [role], I can [action], so that [outcome].
- As a [role], I can [action], so that [outcome].

## Goals
Narrative: [one paragraph on what this achieves and why it matters now]
Measurable goals:
- [Goal 1, tied to a metric below]
- [Goal 2, tied to a metric below]

## Success metrics
| Metric | Baseline | Target |
| --- | --- | --- |
| [metric] | [current value, or [TBD: reason, date]] | [target by date] |

## Scope
In scope: [list]
Out of scope: [list]
Assumptions: [what you are taking as given]

## Key features
- [Feature 1 — one line]
- [Feature 2 — one line]
- [Feature 3 — one line]

## Launch plan
Phase 1 — [name]: [scope]. Exit criteria: [measurable condition].
Phase 2 (if any) — [name]: [scope]. Exit criteria: [measurable condition].

Section by section

TL;DR

The only section a reader skims by default, so it has to carry the actual decision, not a preview of it.

Problem alignment

Lean compresses this to one section instead of five, which raises the risk that the compression deletes the evidence along with the length.

User stories

Three jobs to be done, minimum. Fewer than that and the template cannot tell whether you have thought about who this is for, or just about what it does.

Goals and success metrics

This is where "lean" most often becomes an excuse. A short goals section is fine. A goals section with no baseline metric is not lean, it is unfinished.

Scope

In lean form this is one paragraph, not three, so every line in it is load-bearing.

Key features

Three to five, not eight. If the list runs longer, the feature has outgrown the template, not the list.

Launch plan

One or two phases, each with a condition that ends it, not a date that ends it.

Worked example

Here are three sections from a small, single-team feature: letting a user schedule one saved report to auto-export as CSV on a recurring cadence.

Success metrics

| Metric | Baseline | Target | | --- | --- | --- | | Reports with a recurring export scheduled | 0% (feature does not exist) | 12% of weekly-active report viewers within 6 weeks | | Manual "export now" clicks on reports later scheduled | 4.1 per user per month | Below 1 per user per month for scheduled reports |

Scope

In scope: one schedule per report, daily/weekly/monthly cadence, CSV only. Out of scope: multiple schedules per report, PDF export, Slack delivery. Assumptions: users who schedule an export already have "export now" enabled on that report — if that is not true for a meaningful share of users, the entitlement check needs its own ticket.

Launch plan

Phase 1 — internal dogfood: ship to the reporting team's own workspace. Exit criteria: 15 schedules created with zero delivery failures over 5 business days. Phase 2 — general availability: ship to all workspaces. Exit criteria: phase 1 passes and the export queue's failure rate stays under 1%.

The deliberate weakness: phase 1's exit criteria asks for zero delivery failures over five business days, a bar CSV export infrastructure will not reliably clear even when the feature works correctly — one transient storage timeout and the phase never exits on its own terms. The honest fix is not to soften it to "no failures we do not understand," it is to name a rate: [TBD: confirm acceptable failure rate against existing export-now error budget, currently 0.3%, sign off with infra by 6 Aug]. Zero is not a threshold, it is a wish.

Common mistakes

• A goals section with no measurable rows behind it. "Improve the export experience" is not a goal until a metric can prove or disprove it.
• Padding to look thorough. A two-phase launch plan for a feature that ships to everyone on day one. If phase 2 is "wait a week, then turn it on for everyone," it is not a phase.
• User stories that are the same story twice. Two stories that differ only in phrasing do not show three distinct jobs to be done — they show one job, restated.
• Scope with an empty out-of-scope list. If nothing is explicitly excluded, the reader assumes everything adjacent is included, and that assumption is usually wrong.
• Success metrics with a target and no baseline. The single most common reason a lean PRD gets sent back — see the Standard PRD template for how a stated known-unknown is supposed to look.

Run it through a review

Lean does not mean unreviewed. Thinkr's critique runs the same eleven passes against a short PRD as a long one — a missing baseline gets flagged whether the document is two pages or twenty.