writing-prds

name: writing-prds description: Help users transform abstract ideas into actionable project specs that align engineering and design teams on the problem and success metrics.

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.

Templates & Frameworks

• Lenny's 1-Pager Template (Examples and templates of 1-Pagers and PRDs) - Lenny's personal template used anytime he starts a new project
• 5 Elements of a Great 1-Pager/PRD (Examples and templates of 1-Pagers and PRDs) - An evaluation rubric for what makes a product spec effective, used both for writing and reviewing PRDs
• AI Prompt: Write a PRD (Product manager is an unfair role. So work unfairly.) - A ChatGPT prompt template (GPT-4o and up) for drafting a PRD by dictating context via speech-to-text.
• Breadboarding and Fat Marker Sketching (Ryan Singer) - Two collaboration techniques for shaping sessions that are more detailed than wireframes but less polished than Figma — designed to communicate the idea clearly
• Technical PM Questions for PRDs and Feature Work (Become a more technical product manager) - Questions PMs should ask when writing PRDs or working on features to demonstrate technical awareness and improve collaboration
• Five Attributes of a Strong Problem Statement (A Three-Step Framework For Solving Problems 👌) - Criteria for evaluating whether a problem statement is well-crafted, used when writing the Problem section of the 1-pager.
• PRD Review Checklist (derived from Lenny's critiques) (Examples and templates of 1-Pagers and PRDs) - A checklist derived from Lenny's evaluation of the four real-world examples, identifying common pitfalls to check for
• Duolingo One-Pager Template (How Duolingo builds product) - The template Duolingo uses for early-stage product review one-pagers to get feedback on feature ideas

See references/artifacts.md for the full list with details.

Questions to Help Users

• "What is the single most important problem this project is solving for the user?"
• "What specific metrics will we use to determine if this project is a success?"
• "Which features or tasks are explicitly out of scope for this version?"
• "Have we gathered feedback from engineering on the technical constraints yet?"
• "How much time are we willing to spend on this problem before we move on?"
• "Is this document brief enough that the entire team will actually read it?"

Common Mistakes to Flag

• Using the word just - It undermines the expertise of engineers and risks burning them out on unrealistic promises of quick fixes.
• Premature high fidelity mocks - It anchors the team to a specific solution before they have fully explored the problem space or technical constraints.
• Ignoring non-goals - Failing to establish what you are not building leads to scope creep and loss of focus on the primary problem.
• Waterfall handoffs - Excluding designers and engineers from early planning creates inefficiencies and misses opportunities for innovation.

Deep Dive

For all 24 sourced insights from 14 guests, see references/guest-insights.md

Related Skills

• Shipping Velocity
• Ai Assisted Prototyping
• Building With Ai Agents
• Product Tool Stack