Writing Prds

Writing Product Requirement Documents

Define clear problems and bounded solutions to maximize team velocity and creative output.

Help the user with writing product requirement documents using insights from 14 guests and posts across Lenny's Podcast and Newsletter.

How to Help

1. Drafting the core problem - Assist in articulating a concise problem statement that is agnostic of any specific solution.
2. Establishing success metrics - Help define specific, measurable outcomes that will act as a filter for future feature requests.
3. Defining project boundaries - Guide the user through narrowing fuzzy requests into a bounded concept using shaping techniques.
4. Reviewing for clarity - Audit existing drafts for brevity, readability, and technical awareness to prevent micromanagement.

Core Principles

Design for functional prototyping

Jenny Wen: "We used to go off and make this two-year, five-year, 10-year vision even. Now it becomes a vision that's three to six months out, and isn't necessarily creating this beautiful deck, sometimes just creating a prototype that points people in the right direction."

Design should focus on short term functional prototyping rather than static long term planning to keep up with AI driven engineering speeds.

Shape project boundaries early

Ryan Singer: "What we need to do in a shaping session is we come out with some kind of diagram where engineers, product and design, they're saying, "We understand that." So the first thing is we are not going to start something unless we can see the end from the beginning."

Use high intensity collaborative sessions with design and engineering to create a shared understanding of boundaries before development begins.

Center documents on the problem

From "Examples and templates of 1-Pagers and PRDs": "Problem-oriented: They crystallize the problem being solved in a few strong sentences—ideally near the top of the document—to focus the brainpower of every teammate in the same direction."

A successful PRD starts with a clearly defined problem and specific success metrics to ensure the team aligns on the why before the what.

Force clarity through brevity

From "My favorite product management templates": "A reminder of how valuable it is to keep these to one page, at least to start"

Limiting initial project documents to a single page forces the team to stay focused on core goals and helps prevent early complexity.

Document to move from chaos to clarity

Melanie Perkins: "So we have this concept of chaos to clarity and every idea starts in the chaos side, and then you have to work all the way to the other side, which is clarity. And so chaos can be an idea, it can be a problem, it can be a philosophy or a belief."

Writing down abstract ideas is the essential first step to transforming amorphous concepts into actionable projects.

Avoid creative micromanagement

From "Five habits of highly annoying product managers": "There’s a fine line between articulating the important details of a project spec and spending three pages explaining one button. This annoying habit can apply to both the beginning of a project, telling designers and engineers exactly how a feature needs to work, and also at the end when you spec out each feature for days."

Over specifying features stifles the creativity of engineers and designers. Documentation should facilitate conversation rather than replace it.

Automate technical writing with AI

From "How AI will impact product management": "Describe what you want in human language, get an 80% complete draft, refine it, and then ship. This is already happening with tools like ChatPRD."

Use AI tools to generate the majority of technical documentation so product managers can focus on the final refinement and strategic nuance.