references/artifacts.md
# Writing Product Requirement Documents - Frameworks, Templates & Checklists
*66 artifacts extracted from Lenny's Podcast and Newsletter*
## Frameworks
### 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
How it works: 1. Problem-oriented: 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.
2. Clear success criteria: Super-specifically define what success looks like when the product or feature ships. First to make sure it's even worth doing, and later to help everyone make tradeoff decisions throughout the project.
3. Just enough direction: Give the reader (engineers, designers, managers) just enough of an idea of what the project will entail — including requirements and constraints — without eliminating the opportunity for teammates to come up with even better solutions.
4. Urgency: Include a clear (proposed) timeline by which to review, align on, build, and ship the project, to keep the project moving forward and prevent scope explosion.
5. Short and sweet: Keep it brief (that's why Lenny prefers '1-Pager'), clean up formatting and comments anytime it starts to get messy, and put additional context into an appendix at the end.
### 5 Tips for PM-Design Partnership (The PM 🤝 Design Partnership)
Katie Dill's five-part framework for PMs to build effective working relationships with designers, covering trust, coordination, timing, vision, and goal alignment
How it works: 1. Trust the designer's expertise — Give designers uninterrupted time for creative flow. Defer to them on UX decisions when they are well-informed about user, problem, and goals. Use prototypes and qualitative research to de-risk disagreements. Some design choices are simply a matter of taste.
2. Be the conductor — PMs set the foundation by clarifying context: problems, goals, and constraints tied back to business. Facilitate communication across the team like an orchestra conductor who doesn't play all instruments but coordinates the ensemble.
3. Include designers early — Avoid waterfall. Three benefits: (a) Designers inform with voice of the user, (b) Designers catalyze with creative ideas, visual storytelling, and prototypes, (c) Designers gain context for keener intuition and faster, higher-quality execution.
4. Invest in even the smallest of north stars — A north star is a picture of your future product (low or high fidelity). Scope it using four variables: Scope (single screen = 1 day, new product = months), Fidelity (words, journey map, wireframes, or full prototype), Time horizon (near-term has more knowns but less runway), Buy-in (who needs to inform and evangelize). Complexity of the problem determines investment level.
5. Create shared goals — Reframe 'design goals' (consistency, usability, accessibility, delight) as sub-goals of business metrics (use, conversion, loyalty). Discuss how sub-goals relate and sequence them. Allocate quarterly time or a roadmap percentage for UX improvements. Stop saying 'my designer' — say 'my design partner' instead.
### Amazon Internal Press Release (Carilu Dietrich)
Writing a press release before building a product to ensure it has a cohesive, marketable narrative.
How it works: Start with the end in mind to avoid building a 'bag of doorknobs' (disconnected features). Negotiate the product's value proposition upfront between product and marketing before engineering begins.
### Block Brain Diagrams (Bob Baxley)
Extremely low-fidelity wireframes used to force alignment on conceptual models before visual design begins.
How it works: Use big chunky blocks to represent where things might be located. Because it is so low fidelity, stakeholders cannot comment on colors or shapes, forcing them to discuss the core concept and flow.
### 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 enough that builders know what to make.
How it works: Breadboarding: Text-based flow diagrams showing screens/actions/connections. Example: 'Hit this button → go to this screen → this calculation runs → get this answer → choice to go here or here.' Fat Marker Sketching: Rough sketches with thick markers that communicate the core idea. Key principle: Must communicate 'what to build,' not just be a blurry version of Figma. Test: Can an engineer look at this and say 'I know what to go build'?
### Business Problem vs. Customer Problem Distinction (Christopher Miller)
A documentation standard for product specs and experiments to ensure customer-centricity.
How it works: When outlining a problem in a spec, force a qualifier: Is it a business problem or a customer problem? If it's a business problem, ask 'Why hasn't this solved itself?' to uncover the root customer problem. This prevents solving business needs in a customer-hostile way.
### Conversation Over Documentation Principle (Five habits of highly annoying product managers)
A guiding principle for balancing spec detail: use misunderstandings to calibrate what needs to be written vs. discussed verbally.
How it works: Principle: Prioritize conversation over documentation.
When a misunderstanding occurs, don't default to adding more documentation. Instead, use it as a signal to narrow in on:
- What types of nuances need to be clarified in writing (e.g., edge cases, constraints, acceptance criteria)
- What types of nuances are better clarified through discussion (e.g., design intent, user context, tradeoffs)
Benchmark: If your specs are longer than any other PM's you work with, or if designers and engineers don't actually use your documents, you're likely being too prescriptive.
### Design Goals as Business Sub-Goals Hierarchy (The PM 🤝 Design Partnership)
A mental model for reframing 'design goals' as nested sub-goals of business metrics to create shared PM-Design alignment
How it works: Hierarchy example: Consistency (design sub-goal) → Usability (higher-level goal) → Conversion (business goal). Similarly: Accessibility → Use → Revenue. Delight → Loyalty → Retention.
Key insight: Things people call 'design goals' (consistency, usability, accessibility, delight) all drive use, conversion, and loyalty — which are critical business outcomes. The difference between 'design goals' and 'business goals' is just a difference in level of zoom.
Practical recommendation: Many companies set aside time every quarter and/or require a percentage of the roadmap be devoted to UX improvements that contribute indirectly to the bottom line. Getting it right the first time is even better.
### Detail Dial (calibrating shaped output to team seniority) (Ryan Singer)
Adjust the level of implementation guidance in shaped work based on the experience level of the build team — more detail for junior engineers, less for senior ones.
How it works: Junior team: Provide more implementation guidance (e.g., 'I would suggest approaching it like this, this, this'). Prevents junior engineers from hiding that they're stuck. Senior team: Leave more room for them to figure out implementation. High trust, long history = less detail needed. Key principle: If someone feels they should be involved in fundamental approach decisions, bring them into shaping instead. Over time, dial back detail as team members grow.
### Drawing the Perimeter (Kevin Yien)
A mental model for writing PRDs where the PM defines the strict constraints (customer segment, jobs to be done, core principles like speed vs. consistency) to create a sandbox for design and engineering.
How it works: Includes defining customer segments (e.g., sit-down vs. taco truck), jobs to be done, platform availability, and core principles/trade-offs.
### Evergreen Artifact System (replacing PRDs) (How to ship like a startup)
A three-artifact system to replace traditional PRDs with visual, maintainable documents that stay relevant
How it works: Instead of writing PRDs for every feature, invest in three evergreen artifacts:
1. Vision Artifact — Built once up front. Communicates the broader impact you're aiming for. Functions as your pitch deck. Everyone understands the 'why.'
2. Strategy Artifact — Updated each quarter. Shows how near-term work ladders up to the vision. Keeps teams aligned on priorities.
3. Visual Designs — Invest in directional designs that tell the story better than text ever could. Annotate specs inside designer's mocks rather than creating standalone docs.
Additional tips:
- Use design files as the source of truth, not text documents
- Annotate specs inside mocks
- Use FigJam and quick wireframes for lo-fi alignment
- Speed-run option spaces instead of spending weeks writing specs
### Fewer than 10 moving pieces test (Ryan Singer)
A rule of thumb for evaluating whether something is well-shaped: if you can describe the solution in fewer than 10 moving pieces that someone can hold in their head, it's shaped well enough.
How it works: Based on the cognitive science principle of 7±2 (how many things someone can hold in their head at once). If the description requires more than 10 components, it's either too big or not clear enough. Example: Calendar = (1) two-month dot grid, (2) dots indicating events, (3) tap day for agenda view, (4) forward/back navigation, (5) create button ≈ 5 pieces = well-shaped.
### Framing (narrowing the problem before shaping) (Ryan Singer)
Before shaping a solution, narrow down the raw request (e.g., 'build a calendar') into a specific, bounded problem worth solving (e.g., 'users need to see empty spaces in their schedule'). This prevents shaping from becoming an ever-expanding blob.
How it works: Steps: 1) Take the raw request or opportunity. 2) Ask what specific problem customers are actually trying to solve. 3) Negotiate with stakeholders to narrow scope. 4) Arrive at a crisp problem statement that bounds the shaping work. Example: 'Calendar' → 'Users can't see empty spaces where they could book something in the existing agenda view.'
### Helpful Error Message Design (How to accelerate growth by focusing on the features you already have)
Principles for creating error messages that guide users to success rather than creating frustration
How it works: When a user makes a mistake and sees an error message:
1. Focus on what caused the error
2. Do NOT blame the user
3. Most importantly: Tell them how to correct it
Use error states as an opportunity to guide users to a successful outcome, not just report failure.
### PM-Designer Co-Design Model (Ideal sprint length, designer vs. PM roles, running PM team meetings, running post-mortems, best product/executive coaches, and much more)
A framework for delineating PM and Product Designer responsibilities across discovery and delivery phases
How it works: Ownership model:
1. Customer Discovery Phase:
- PM OWNS customer discovery (problem definition, why it matters)
- Design and Engineering play the role of CHECKER
- PM's responsibility: prove this is the most important problem/opportunity to pursue now
- All three (PM, Design, Eng) ride shotgun on discovery sessions when possible
2. Product Discovery / Solution Phase:
- Design OWNS product discovery and the experience of the solution
- Engineering provides options that are feasible (based on constraints)
- PM EVALUATES if the solution is the best way to deliver value to customers
- PM brings context of the problem being solved
3. Key principles:
- Think of it as 'co-design' — roles reverse depending on the stage
- If PM isn't butting heads with Design (and PMM, Eng), something's wrong — it should be the 'leaning in' kind of collision
- PM should NOT be in design tools (Figma) doing anything other than commenting
- Senior designers may spill over into user/market research on bigger/more technical products
- The boundary varies with experience, skillset, interests of the designer, product type, and org scale
### Pre-Technical Conception & Legacy Study Process (This Week #8: Splitting equity with late-joining co-founders, favorite roadmap templates, and small changes that improve your org)
A PM-led process to study legacy products and prepare documentation before developers begin technical conception, dramatically speeding up development
How it works: Steps:
1. Study the legacy product where the team will work — all functional aspects
2. Write documentation to keep track of studies and explain how features & logic work
3. Note all technical aspects you can understand as a PM:
- Database structure of the functional perimeter
- API calls during feature interactions
- Workflow diagrams
- Any leads/suggestions to help developers do Technical Conception faster
4. Share all documentation with developers BEFORE they begin their Technical Conception phase
Result: Development time went 300% faster because developers obtained knowledge in advance and could do very fast Technical Conceptions.
### Quality Equals Meeting Spec (Seth Godin)
A definition of quality that separates it from luxury and perfectionism, providing a clear decision-making rule for when to ship.
How it works: Quality is not luxury. Quality is not perfection. Quality means meeting spec. If you meet spec, you're done—ship it. If you don't think the spec is good enough, make a better spec. Taking something that meets spec and refusing to ship it because you're a perfectionist is hiding, not quality.
### Sharpie Storyboard (Jeff Weinstein)
A low-fidelity, unconstrained visual representation of the perfect solution to a customer problem.
How it works: Drawn with a Sharpie (not Figma). Focuses on the ideal end-state to align stakeholders and secure buy-in before scoping the MVP.
## Templates
### 1-Pager / PRD (Maggie Crowley)
A document to define the problem and align the product triad (PM, design, engineering).
How it works: Sections include: Background and context, The problem, Why this problem matters, Why this problem matters NOW, and a running list of decisions made (what is and isn't being solved).
### 1-Pager Project Template (A Three-Step Framework For Solving Problems 👌)
A Google Doc template for scoping a product project by answering six key questions. Lenny recommends a single person (usually the PM) takes the first pass, then uses it for team and stakeholder alignment.
How it works: Template structure with six sections:
1. **Description: What is it?** — Brief description of the project so readers can quickly understand what it's about. Keep it brief.
2. **Problem: What problem is this solving?** — A single-sentence problem statement that is: (a) Short, (b) Focused on a single clear problem, (c) References an unfulfilled need, (d) Includes a what and a why, (e) Is agnostic of a solution. Include examples of what problem you are NOT solving.
3. **Why: How do we know this is a real problem and worth solving?** — 3-5 strong data points (quantitative and qualitative) that back up the problem hypothesis. Quality over quantity.
4. **Success: How do we know if we've solved this problem?** — Concrete metric with a defined goal (e.g., '10% increase in X', '50% decrease in Y', '20% adoption within 3 months'). Should connect to team KPIs. If no metric applies, describe what the world looks like if this is a big success.
5. **Audience: Who are we building for?** — Specific user segment (new vs returning, casual vs power, mobile vs web, etc.). Should rarely be 'all users.'
6. **What: What does this look like in the product?** — Description of the proposed solution, at whatever level of detail is appropriate. Align with designer(s) on how much detail they need.
Google Doc link: https://docs.google.com/document/d/1541V32QgSwyCFWxtiMIThn-6n-2s7fVWztEWVa970uo/edit
Copy link: https://docs.google.com/document/d/1541V32QgSwyCFWxtiMIThn-6n-2s7fVWztEWVa970uo/copy
### AI Prompt: Write User Stories (Product manager is an unfair role. So work unfairly.)
A ChatGPT prompt template (GPT-4o and up) for writing user stories by describing functionality out loud while looking at Figma prototypes.
How it works: Prompt (send first message):
"You are an expert product manager and product owner. I will describe functionality to you, and you will provide a user story following the user story template that follows, paying close attention to line breaks. Do you understand and are you ready?"
"User Story Template [pick your favorite]:
# Story
As a <type of user>,
I want to <perform some task>,
so that I can <achieve some goal>.
# Objectives
<text>
# Acceptance criteria
1. Given <some context>,
When <some action is carried out>,
Then <a set of observable outcomes should occur>
2. …
# Tech notes
(leave empty)
# Grooming Q&A
(leave empty)"
[hit enter]
Subsequent messages:
[Look at the Figma prototype in another window for convenience, and describe out loud one user story at a time using Whisper speech-to-text, then hit enter]
### 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.
How it works: Prompt (send first message):
"You are an expert product manager and I need your help to articulate my thoughts into a PRD. I'm going to give you the template and then I'm going to later tell you all the context that I have in my head, and you're going to help me structure the document. Do you understand?"
[hit enter]
Second message (template):
# Objective
# Target customer
# How this connects to company strategy
# What we believe
# Solution constraints and principles
# [other sections from your preferred template]
[hit enter]
Third message:
[Dictate your thoughts on the above sections using speech-to-text (BetterDictation, Superwhisper, or built-in OS dictation)]
### Adam Thomas's Initiative Template (My favorite product management templates)
A one-page initiative template that emphasizes keeping scope constrained at the start
How it works: Google Doc initiative template designed to stay on one page. Linked at: https://docs.google.com/document/d/1B3GEUwgEIIQVgRp85l4DKLZOTzgGZmBIAjR06p4wuwY/edit
### Adam Waxman's PRD Template (SeatGeek) (My favorite product management templates)
A PRD template featuring a 1-pager summary section before diving into detail
How it works: Google Doc PRD template with a 1-pager summary section upfront followed by deeper detail. Linked at: https://docs.google.com/document/d/1xc9TZX-7NMfOykzFKR0o0jzTUygoAFzWadxDVR7sNvs/edit
### Asana's Project Brief Template (Examples and templates of 1-Pagers and PRDs, My favorite product management templates)
Asana's project brief template, noted for its problem statement framework
How it works: Google Doc template featuring a problem statement framework. Linked at: https://docs.google.com/document/d/1W46cmPfPwXIIH2mNNbbQ5EdjnhQFqGxGhT5iAijmJjc/edit#heading=h.cqt1a4hrfy8u
### Bolt PRD Template (Examples and templates of 1-Pagers and PRDs)
A PRD template specifically suited for hardware products
How it works: Lenny highlights: 'Ideal for hardware products.' Link: Google Docs.
### ChatPRD Standard Template Structure (Claire Vo)
The default structure used by ChatPRD to generate product specs.
How it works: Includes: Objectives, User Goals, User Stories, Out of Scope, UX Walkthrough, Narrative (how to pitch/position the product), Sequencing and Milestones, and Measurements and Goals.
### 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
How it works: One-Pager Template sections (based on screenshot): 1. Title / Feature Name. 2. Author(s) and Date. 3. Problem Statement — What problem are we solving? Why does it matter? 4. Proposed Solution — High-level description of the feature idea. 5. Goals — What does success look like? What metrics will be impacted? 6. Non-Goals — What is explicitly out of scope? 7. Key Risks and Open Questions — What could go wrong? What do we need to figure out? 8. Rough Timeline / Next Steps. (Note: The actual template was shown as an image; these sections are derived from the visible structure.)
### Effort Scoping Reframe Question (Five habits of highly annoying product managers)
A replacement phrase for 'this should be quick' that collaboratively scopes work with engineers and designers.
How it works: Instead of saying: 'This should be quick' or 'This should just take a few hours'
Say: 'What would need to be true for this to be doable in the next [X] days?'
This reframes the conversation from a PM assertion about effort to a collaborative exploration of constraints and feasibility.
### Figma's PRD Template (Examples and templates of 1-Pagers and PRDs, My favorite product management templates)
A super comprehensive plug-and-play PRD template from Figma, hosted on Coda
How it works: Lenny highlights: 'A super comprehensive plug-and-play template.' Link: Coda (coda.io/@yuhki/figmas-approach-to-product-requirement-docs/prd-name-of-project-1)
### First Principles / Second-Order Effects PRD Section (Nickey Skarstad)
A section in a product requirements document to force teams to think about downstream impacts.
How it works: Include prompts: 'What are the first principles we care about for this build?' and 'How will these changes cascade through our ecosystem?' Get alignment on this section before moving into design or technical architecture.
### Front's PRD Template (Examples and templates of 1-Pagers and PRDs)
A PRD template from Front (the customer communication platform) that enforces structure and clarity
How it works: Lenny highlights: 'Love the structure and clarity it enforces.' Hosted on Dropbox Paper.
### Growth-Oriented Ticket/Spec Addition (Summary: The ultimate guide to adding a PLG motion | Hila Qu (Reforge, GitLab))
A simple addition to product tickets/specs that forces PMs to connect features to growth levers
How it works: Add a section to every product ticket/spec with two fields:
1. Success Metric: What metric will this feature improve? (written ahead of time, before building)
2. Growth Lever: Which growth lever will this feature help? (e.g., activation, conversion, retention, acquisition)
Purpose: Forces PMs to think deeply about the purpose of every feature and connect it to measurable business outcomes.
### Intercom's Job Story Template (Examples and templates of 1-Pagers and PRDs)
A simple story-based template from Intercom that has everything you need to get started
How it works: Lenny highlights: 'Love the simplicity, while still having everything you need to get started.' Hosted as PDF on Intercom's marketing CDN.
### Intercom's Story Template (My favorite product management templates)
A simple story-based template with everything needed to get started on a project
How it works: PDF template focused on simplicity while covering essential project information. Uses job story format. Linked at: https://s3.amazonaws.com/marketing.intercomcdn.com/assets/Intercom-Job-Story-template.pdf
### Kevin Yien's PRD Template (Examples and templates of 1-Pagers and PRDs)
A PRD template from a PM at Square, notable for its Non-Goals section and step-by-step flow
How it works: Lenny highlights: 'Love this whole template, particularly the Non-Goals section and the step-by-step flow.' Link: Google Docs.
### Kevin Yien's PRD Template (Square) (My favorite product management templates)
A PRD template notable for its Non-Goals section and step-by-step flow, used at Square
How it works: Google Doc PRD template featuring a Non-Goals section and step-by-step user flow. Linked at: https://docs.google.com/document/d/1mEMDcHmtQ6twzNlpvF-9maNlAcezpWDtCnyIqWkODZs/edit
### Lenny's 1-Pager Template (Examples and templates of 1-Pagers and PRDs, What 5 years at Reddit taught us about building for a highly opinionated user base)
Lenny's personal template used anytime he starts a new project
How it works: URL: https://docs.google.com/document/d/1541V32QgSwyCFWxtiMIThn-6n-2s7fVWztEWVa970uo/edit
Used by Tyler Swartz at Reddit as the foundation for step 1 of the community-driven launch playbook. The PM completes this one-pager, then reviews it with Community Managers before writing the full product spec.
### Lenny's Personal 1-Pager Template (My favorite product management templates)
Lenny's go-to template for starting every project — a concise 1-page project brief
How it works: Google Doc template used by Lenny to kick off every project. Linked at: https://docs.google.com/document/d/1541V32QgSwyCFWxtiMIThn-6n-2s7fVWztEWVa970uo/edit
### Nine-Box Kickoff Exercise (Ryan Singer)
At project kickoff, the build team translates the shaped idea into a 3x3 grid of nine major implementation scopes. This tests whether the shaped work is clear enough and the scope is realistic.
How it works: Steps: 1) Take the shaped idea. 2) Draw a 3x3 grid (9 boxes). 3) Have the build team fill in 9 major implementation scopes (not tickets — big chunks). 4) Sanity check: 30 business days ÷ 9 = ~4 days per scope. Does that feel realistic? 5) If >10 scopes, there's too much — revisit shaping. 6) Use as coaching moment: senior engineers can review junior engineers' proposed approaches. Rule: Keep to 9 or fewer (based on cognitive science rule of 7±2).
### PRD Growth Lever Addition (Hila Qu)
A required section in product requirement docs to ensure features drive measurable growth.
How it works: Add a section to every product ticket/doc requiring the PM to write the success metric ahead of time and explicitly state which growth lever it supports: acquisition, activation, retention, or monetization.
### PRD/1-Pager 'Why This Is a Problem' Section (Five habits of highly annoying product managers)
Lenny's recommendation for what every PRD or 1-Pager must include to justify prioritization and gain team buy-in.
How it works: Every PRD/1-Pager should contain a strong 'why this is a problem' argument. This section should:
1. Clearly articulate the problem being solved
2. Provide data-driven (not anecdotal) evidence for why this matters
3. Explain the rationale behind the priority level
Additionally, for non-trivial projects: speak with the engineer, designer, etc. in person to explain the rationale and address their concerns in real time.
Lenny links to his PRD/1-Pager template: https://docs.google.com/document/d/1541V32QgSwyCFWxtiMIThn-6n-2s7fVWztEWVa970uo/edit
### Problem Statement One-Pager Template (What Seven Years at Airbnb Taught Me About Building a Business)
A one-page document template refined over years at Airbnb to crystallize the problem and opportunity for teams and stakeholders. Used as the starting point before any project begins.
How it works: Google Doc template linked in the newsletter: https://docs.google.com/document/d/1541V32QgSwyCFWxtiMIThn-6n-2s7fVWztEWVa970uo/edit. Purpose: Crystallize the problem and opportunity for the team and stakeholders. Used at Airbnb as the single most important step before solving any problem.
### Product 1-Pager Template (SCR-based) (The Minto Pyramid Principle and the SCR Framework)
Lenny's favorite product 1-pager template that maps to the SCR framework. Description = Situation, Problem = Complication, What = Resolution.
How it works: Google Doc link: https://docs.google.com/document/d/1541V32QgSwyCFWxtiMIThn-6n-2s7fVWztEWVa970uo/edit
SCR Mapping:
- Description section → Situation (state of affairs)
- Problem section → Complication (what needs to change)
- What section → Resolution (what to build/do)
### Product Hunt's PRD Template (Examples and templates of 1-Pagers and PRDs, My favorite product management templates)
Product Hunt's PRD template that begins with Who, Why, What structure
How it works: Google Doc PRD template structured around Who, Why, What. Linked at: https://docs.google.com/document/d/1yrU5F6Gxhkfma91wf_IbZfexw8_fahbGQLW3EvwdfQI/edit
### Skeleton Prototypes for Flows (Elena Verna 3.0)
Wireframes containing the common, winning elements of specific user flows derived from competitor teardowns.
How it works: Instead of starting from scratch or blindly copying one competitor, extract the common structural elements (e.g., for a pricing page or sharing model) into a skeleton, then apply your own authentic brand, copy, and design.
### Steve Morin's 1-Pager Template (Examples and templates of 1-Pagers and PRDs)
A 1-Pager template from an Engineering Manager at Asana focused on success criteria and risks
How it works: Lenny highlights: 'Love the focus on success criteria and risks.' Link: Google Docs.
### Steve Morin's 1-Pager Template (Asana) (My favorite product management templates)
A 1-pager template with focus on success criteria and risks
How it works: Google Doc 1-pager template emphasizing success criteria and risk identification. Linked at: https://docs.google.com/document/d/1BeNK9BYd3-8pAqVYR_B0Gzp7kGNtWdPFHJKIXI52_84/edit
### Working Backwards PR & FAQ (Ian McAllister)
A document format used to ensure a product solves a real customer problem before writing any code.
How it works: Consists of an internal press release containing a problem paragraph, a solution paragraph, and a customer quote, followed by an FAQ that proves a legitimate plan to succeed.
## Checklists
### Design Crit Format (How Figma builds product)
Figma's structured format for running design critiques — explicitly generative and non-decisional.
How it works: Structure per topic (typically 2 topics per meeting): (1) ~10-15 minutes of presenting — use Spotlight in FigJam, attendees can comment during presentation, (2) ~5 minutes of lingering questions, (3) ~5 minutes of silent writing and commenting on the file. Key principles: Crits are explicitly NOT about making decisions — they are generative only. Designers share a file (often FigJam) with 10 minutes heads-down silent feedback via stickies and comments before live discussion. Scheduling: 5 standing weekly slots with escalating attendance — Tuesdays for tech pillars, Thursdays for Editor/Non-Editor teams, Fridays for all of design. Designers control booking and invitations. Automated Slack reminders for sign-ups. Guest observers from across the company are welcome — every employee encouraged to attend at least one crit per year. Additional resource: https://www.figma.com/blog/design-critiques-at-figma/
### 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.
How it works: A strong problem statement should be:
1. **Short** — Aim for a single sentence. The more you need to explain it, the less clear the problem is.
2. **Focused** — Single clear problem that can be owned by a single team and solved in a reasonable amount of time. Helpful to add examples of what problem you are NOT solving.
3. **References an unfulfilled need** — Focus on a user need (or business need if necessary). The Jobs-To-Be-Done framework is especially useful here.
4. **Includes a what and a why** — What's going wrong, and why is it a problem? Back it up with evidence.
5. **Agnostic of a solution** — Resist the urge to jump to a solution this early.
### 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
How it works: When reviewing a PRD, check for these common issues:
1. Is the problem crystallized clearly in a few strong sentences near the top?
2. Are there clear, specific success criteria (but not too many)?
3. Is there a directional solution that gives engineers/designers enough to work with?
4. Is the stakeholder/players list appropriately scoped (not too long)?
5. Is the document clean and well-formatted (not messy)?
6. Does it explain why this direction is the right one?
7. Are acceptance tests or requirements concrete enough for the builder?
8. Is additional context pushed to an appendix rather than cluttering the main doc?
### Product Quality List (PQL) (Matt MacInnis)
A lightweight, evolving checklist of standards a product must meet before shipping.
How it works: Includes specific rules like 'You are allowed to have one feature flag that governs your entire product at ship.' It is iterated on constantly based on new mistakes discovered during product reviews.
### 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
How it works: Application Architecture questions:
- What changes need to be made to each tier (client, server, database) for your new feature?
- Ask the engineer to walk you through implementation at a high level. Does it align with what you were expecting?
API questions:
- Have you tested your API from the perspective of your customer?
- How well does your API support customer workflows?
- Test internal and external APIs yourself. Do they perform the way you expect? What bottlenecks are there (if any)?
SDLC questions:
- How can you reduce implementation risk through closer collaboration with technical stakeholders?
- How much testing, and what types of testing, are appropriate for the change you're pushing to production?
### Three Habits for Staying Aligned to the Problem (A Three-Step Framework For Solving Problems 👌)
Three recurring habits to prevent scope creep and solution drift during product development.
How it works: 1. In every design review, make sure designers start by reviewing the problem statement. If it's not clear, ask 'What problem are we trying to solve?'
2. In every progress update to stakeholders, review the problem statement to ensure continued alignment on the outcome.
3. Before finalizing designs, ask yourself: 'Am I feeling confident this is going to solve the problem we set out to solve?'
### Three Reasons to Include Designers Early (The PM 🤝 Design Partnership)
Three ways including designers early in the product development process saves time and money
How it works: 1. Designers inform the conversation with a salient voice of the user
2. Designers catalyze the conversation and drive innovative thinking with creative ideas, visual storytelling, and prototypes
3. Designers gain greater context, develop a keener intuition for what's best, and are able to drive higher quality execution faster
## Examples
### Airbnb Host Dashboard Scope Creep Example (A Three-Step Framework For Solving Problems 👌)
A real example of how Lenny used the problem statement to fight scope creep on an Airbnb host dashboard project.
How it works: The team was building a dashboard for Airbnb hosts. The initial problem: reducing host response time (shrinking the average time a host takes to respond to a guest message). The hypothesis: hosts would respond more quickly if unread messages were more prominent and they were reminded that reply time impacts search ranking. The hypothesis proved correct, but throughout the project, as scope and complexity grew, Lenny had to repeatedly remind the team of the original problem statement. Dashboards are identified as a classic 'silver burrito' problem where everyone has their own vision.
### Basecamp Calendar — shaping example (Ryan Singer)
A fully worked example of how a vague 'calendar' request was framed down to 'seeing empty spaces' and then shaped into a specific solution describable in fewer than 10 moving pieces.
How it works: Problem framed: Users need to see empty spaces (not a full Google Calendar clone). Shaped solution: (1) Two-month dot grid showing days with/without events, (2) Tap a day to see scrolling agenda view underneath, (3) Navigation to go forward/back in months, (4) Create button to add event from empty space view. Test: Engineer can say 'I know what to build now.' Total: ~5 moving pieces.
### Facebook Newsfeed — Architecture That Stood 12+ Years (Peter Deng)
How thoughtful systems thinking in the Newsfeed rebuild created an information architecture that has barely changed in over a decade.
How it works: Approach: Deep investment in understanding the sharing loop — posting at top of page → appearing in newsfeed → like button → notification lighting up red → repeat. Focused on information architecture and the complete flow. Outcome: The current Newsfeed design has stood largely unchanged for 12+ years. Lesson: Going slow to build the right systems in the scaling phase pays off in long-term durability.
### Good vs Bad Problem Statement Examples (A Three-Step Framework For Solving Problems 👌)
Concrete examples of well-written and poorly-written problem statements with annotations explaining what makes each good or bad.
How it works: **Good problem statements:**
- 'Lyft drivers are cancelling rides too often because the passengers are too far away.'
- 'Airbnb hosts are feeling frustrated because they want to improve, but are finding it difficult to figure out how.'
- 'Users are dropping off at too high a rate at the final step of the signup flow.'
**Bad problem statements:**
- 'User growth is slowing.' — Issue: Too broad for this process; not user-centric.
- 'Build a loyalty program.' — Issue: Assumes a solution. What's the problem this is solving?
- 'Users are bouncing from the signup flow.' — Issue: Not focused enough, and missing a hypothesis of the why. Go one level deeper.
### Linear's Target Date Feature (Nan Yu)
A case study on solving the emotional pain of missing strict deadlines.
How it works: Customers felt bad when they missed specific dates (e.g., Dec 30th) causing marketing misalignment. Linear built a feature allowing target dates at any granularity (a specific day, a month, Q4, or H2) to remove the anxiety of false precision.
### Lyft Lost and Found 1-Pager (Examples and templates of 1-Pagers and PRDs)
A real-world product spec from Lyft for their Lost and Found feature, praised for problem-orientedness, clear success criteria, and simplicity
How it works: Strengths: Problem-oriented, very clear success criteria, overall simplicity. Weaknesses per Lenny: Could have crystallized the problem more clearly, outlined the details of the spec more concretely, and generally kept the document cleaner. Link: Google Drive document.
### Shift Swap Project Charter (Examples and templates of 1-Pagers and PRDs)
A real-world project charter for a Shift Swap feature, praised for structure and problem orientation
How it works: Strengths: Great structure, problem-orientedness, and clear success criteria. Weaknesses per Lenny: Missing any sense of a solution, list of 'players' is too long, and there are far too many success criteria — both should be cut back. Link: Google Docs.
### Shopify to Quickbooks Connector PRD (Examples and templates of 1-Pagers and PRDs)
A real-world PRD for a Shopify to Quickbooks integration, noted for its detailed acceptance tests and engineer-ready features
How it works: Strengths: Acceptance tests, success criteria, and fully thought-out features — good for an engineer who's ready to build. Weaknesses per Lenny: Document is relatively messy, not fully fleshed-out, and missing insight into the problem itself. Link: Google Docs.
### prodmgmt.world 1-Pager (Examples and templates of 1-Pagers and PRDs)
A real-world product spec for prodmgmt.world, praised for problem-orientedness and directional solutioning
How it works: Strengths: Problem-orientedness, directional solutioning, and clear success criteria. Weaknesses per Lenny: The 'User' section doesn't seem valuable and should be replaced with a clearer sense of why this direction is the right one. Link: Google Docs.
## Tools
### Write My PRD (How to use ChatGPT in your PM work)
A dedicated tool for using AI to write product requirements documents
How it works: URL: https://writemyprd.com/ — A specialized AI tool focused specifically on generating PRDs for product managers.
references/guest-insights.md
# Writing Product Requirement Documents - All Guest Insights
*14 sources, 38 insights*
---
## Bob Baxley
**Insight:** A successful design brief provides clear constraints and context while leaving the visual solution entirely to the designer.
**Tactical advice:**
- Focus the brief on the future state you want to create rather than the specific features to build.
- Wait as long as possible to draw pictures to ensure the problem space is fully defined first.
*Source: [35 years of product design wisdom from Apple, Disney, Pinterest, and beyond | Bob Baxley](https://www.youtube.com/watch?v=X-83gvgVaWc) @ 01:01:53*
---
**Insight:** Prematurely creating high-fidelity prototypes can anchor a team to a suboptimal solution before they have fully explored the problem space.
**Tactical advice:**
- Wait as long as possible to create a prototype or draw a picture of your idea.
- Prioritize verbal and conceptual alignment on the desired outcome before moving to visual design.
*Source: [35 years of product design wisdom from Apple, Disney, Pinterest, and beyond | Bob Baxley](https://www.youtube.com/watch?v=X-83gvgVaWc) @ 01:09:04*
---
## Claire Vo
**Insight:** Leveraging AI to automate the synthesis and formatting of requirements allows PMs to pivot their time toward high-level strategy and alignment.
**Tactical advice:**
- Experiment with AI tools to handle the clerical parts of product requirement generation.
- Focus on refining the strategic 'why' of a product while letting AI manage the functional 'what.'
- Stay ahead of the curve by identifying which PM skills will be complemented or replaced by AI shifts.
*Source: [Bending the universe in your favor | Claire Vo (LaunchDarkly, Color, Optimizely, ChatPRD)](https://www.youtube.com/watch?v=aXGo1o_baBo) @ 00:54:06*
---
## 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."
**Insight:** The speed of AI-driven engineering requires design to shift from static, long-term theoretical planning to short-term functional prototyping and real-time execution support.
**Tactical advice:**
- Replace multi-year vision decks with three-to-six-month directional prototypes.
- Reduce time spent on high-fidelity mocks to prioritize supporting engineers with 'last mile' implementation and polish.
- Test functional prototypes with actual models to account for the non-deterministic nature of AI behavior.
*Source: Jenny Wen @ 00:04:59*
---
## Julie Zhuo
**Insight:**
*Source: [Julie Zhuo on accelerating your career, impostor syndrome, writing, building product sense, using intuition vs. data, hiring designers, and moving into management](https://www.youtube.com/watch?v=YLsxHa1dhSw) @ 00:54:52*
---
## Katie Dill
**Insight:** Physical proximity and shared goals between disciplines prevent silos and ensure design intent is maintained during execution.
**Tactical advice:**
- Seat designers, engineers, and product managers together to facilitate spontaneous 'shoulder-look' feedback.
- Establish shared goals across disciplines to ensure the entire team is aligned on the same outcome.
- Balance cross-disciplinary pods with regular functional meetups to foster community and maintain craft excellence.
*Source: [Building beautiful products with Stripe’s Head of Design | Katie Dill (Stripe, Airbnb, Lyft)](https://www.youtube.com/watch?v=gfEEcssu304) @ 01:01:59*
---
## Kevin Yien
**Insight:** The role of a product manager is to maximize the team's output by providing the necessary direction and decision-making that builders may not have the capacity to handle alone.
**Tactical advice:**
- Step in to define constraints when a product space becomes too complex for builders to manage alone.
- Delegate PM activities to engineers or designers when they are the target customers for the product.
- Focus on minimizing the loss of value when converting team effort into customer benefits.
*Source: [Unorthodox PM wisdom: Automating user insights, unselling job candidates, logging every decision, more | Kevin Yien (Stripe, Square, Mutiny)](https://www.youtube.com/watch?v=xOTO98MXG9o) @ 00:19:10*
---
## Lenny Rachitsky
**Insight:** Continuously returning to the defined problem and success metrics serves as a filter to reject features that don't directly serve the project's goal.
**Tactical advice:**
- Keep coming back to the original problem statement during every phase of development.
- Evaluate every proposed feature by asking if it increases the likelihood of hitting your defined success metric.
- Cut any scope that does not directly contribute to solving the core problem.
*Source: [A Three-Step Framework For Solving Problems 👌](https://www.lennysnewsletter.com/p/a-three-step-framework-for-solving-problems)*
---
> "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."
**Insight:** An effective PRD centers on a clearly defined problem and specific success metrics to ensure the team remains aligned on the 'why' before debating the 'how'.
**Tactical advice:**
- Crystallize the problem being solved in a few strong sentences near the top of the document.
- Define super-specifically what success looks like to help the team make tradeoff decisions throughout the project.
- Include a clear proposed timeline for review and shipping to maintain urgency and prevent scope explosion.
*Source: [Examples and templates of 1-Pagers and PRDs](https://www.lennysnewsletter.com/p/examples-and-templates-of-1-pagers-and-prds)*
---
> "Design crits are intended to be very generative, and are explicitly not about making decisions. Designers share a file (often on FigJam), and we spend 10 minutes heads-down silently leaving stickies and comments to give feedback on the designs before discussing live."
**Insight:** Separating generative feedback from decision-making ensures more diverse input and prevents the loudest voices from prematurely narrowing the creative process.
**Tactical advice:**
- Dedicate at least 5-10 minutes of every critique for silent, written feedback before speaking.
- Structure crits around technology pillars or product areas with regular standing slots.
- Invite 'observers' from across the company to participate and understand the design culture.
*Source: [How Figma builds product](https://www.lennysnewsletter.com/p/how-figma-builds-product)*
---
> "A week before a product review, Snowflake product managers share a six-page document for the topic with meeting attendees that outlines the customer problem, proposed solution, risks, and other key data points around a specific product investment."
**Insight:** Use a comprehensive six-page narrative to facilitate deep asynchronous feedback from leadership before the actual review meeting.
**Tactical advice:**
- Distribute the review document to attendees at least one week before the meeting.
- Include an executive summary, problem statement, use cases, risks, and an FAQ section.
- Invite leadership to provide feedback via comments directly in the document before the session.
*Source: [How Snowflake builds product](https://www.lennysnewsletter.com/p/how-snowflake-builds-product)*
---
> "A reminder of how valuable it is to keep these to one page, at least to start"
**Insight:** Keeping initial project documents to a single page forces clarity and ensures the team stays focused on core problems and goals before increasing complexity.
**Tactical advice:**
- Keep initial PRDs or initiative documents to a single page to maintain focus.
- Include a "Non-Goals" section to clearly establish project boundaries.
- Use a problem statement framework to anchor the project's purpose.
*Source: [My favorite product management templates](https://www.lennysnewsletter.com/p/my-favorite-product-management-templates)*
---
**Insight:** High-performing PM and design partnerships rely on the PM acting as a facilitator who trusts design expertise and aligns the team through shared context rather than control.
**Tactical advice:**
- Trust the designer’s expertise in creative schedules and the need for uninterrupted maker-time.
- Act as a conductor by clarifying context and facilitating communication rather than dictating every detail.
- Ensure team alignment on the core problems, mission, and goals to leverage each expert's unique superpowers.
*Source: [The PM 🤝 Design Partnership](https://www.lennysnewsletter.com/p/the-pm--design-partnership)*
---
**Insight:** To improve a product spec, audit it for clarity of the problem statement, concrete feature details, and overall readability.
**Tactical advice:**
- Study 1-Pagers from past successful projects at your company to understand what 'great' looks like in your specific context.
- Verify that the document provides 'just enough' direction without eliminating the opportunity for teammates to find better solutions.
- Clean up formatting and resolve comments regularly to ensure the document remains readable and usable.
*Source: [Examples and templates of 1-Pagers and PRDs](https://www.lennysnewsletter.com/p/examples-and-templates-of-1-pagers-and-prds)*
---
> "In the end, if you want this document to be used, it needs to be readable. So keep it brief (that’s why I like the term 1-Pager), clean up formatting and comments anytime it starts to get messy, and put additional context into an appendix at the end."
**Insight:** Choose a template that enforces brevity and focuses on essential structural elements like problem statements and success criteria rather than exhaustive documentation.
**Tactical advice:**
- Select a '1-Pager' style template to ensure the document remains brief enough for the team to actually read and use.
- Use templates that include 'Non-Goals' or 'Acceptance Tests' to explicitly define project boundaries and technical requirements.
- For hardware products, utilize specialized templates that account for the unique constraints of physical manufacturing.
*Source: [Examples and templates of 1-Pagers and PRDs](https://www.lennysnewsletter.com/p/examples-and-templates-of-1-pagers-and-prds)*
---
> "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."
**Insight:** Over-specifying features stifles the creative input of designers and engineers and can make the team feel micromanaged.
**Tactical advice:**
- Prioritize verbal conversation over exhaustive written documentation.
- Check if teammates are actually using your documents or if they are feeling micromanaged by the length of your specs.
- Narrow in on which nuances actually require written clarification versus those that are better handled via discussion.
*Source: [Five habits of highly annoying product managers](https://www.lennysnewsletter.com/p/five-habits-of-highly-annoying-product-managers)*
---
> "Instead of suggesting something will be quick, ask, “What would need to be true for this to be doable in the next x days?” It’s totally OK to suggest something will be quick occasionally, but if you’re finding that the majority of your asks should take “just” a few hours, you’re probably annoying the sh*t out of your team."
**Insight:** Assuming technical tasks are "quick" undermines the expertise of your engineers and risks burning them out on unrealistic promises.
**Tactical advice:**
- Eliminate the word "just" when describing the expected duration of an engineering task.
- Frame requests by asking what resources or conditions are needed to meet a specific timeline.
- Listen for engineering pushback on estimates as a signal that you are underestimating technical complexity.
*Source: [Five habits of highly annoying product managers](https://www.lennysnewsletter.com/p/five-habits-of-highly-annoying-product-managers)*
---
> "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."
**Insight:** AI can automate the bulk of technical writing tasks, allowing PMs to focus their energy on the final refinement and nuance of product specs.
**Tactical advice:**
- Use natural language descriptions to generate 80% complete PRD drafts using AI tools.
- Refine AI-generated specs to ensure they include necessary nuance and team context.
- Explore specialized tools like ChatPRD or WriteMyPRD for faster feature documentation.
*Source: [How AI will impact product management](https://www.lennysnewsletter.com/p/how-ai-will-impact-product-management)*
---
**Insight:** Maintaining product simplicity and delight remains a uniquely human responsibility and a key competitive advantage in an AI-commoditized market.
**Tactical advice:**
- Personally review designs and prototypes to ensure the user experience is cohesive and simple.
- Use AI to identify common UX challenges and verify that designs follow industry best practices.
- Leverage human judgment to refine AI suggestions into truly delightful product experiences.
*Source: [How AI will impact product management](https://www.lennysnewsletter.com/p/how-ai-will-impact-product-management)*
---
**Insight:** Use AI to overcome the 'blank page' problem by generating initial drafts of technical documentation and user requirements.
**Tactical advice:**
- Prompt the AI to create a v1 PRD or Jira ticket based on a feature idea.
- Use the tool to write specific user stories and acceptance criteria.
- Identify potential drag metrics that could impact your feature's success.
*Source: [How to use ChatGPT in your PM work](https://www.lennysnewsletter.com/p/how-to-use-chatgpt-in-your-pm-work)*
---
**Insight:** AI platforms designed for product management can transform disorganized notes into standardized, professional documentation that integrates directly with development workflows.
**Tactical advice:**
- Convert messy initial notes into clear, structured PRDs automatically.
- Connect documentation to Linear to break down work into actionable sub-issues.
- Mention AI agents in comments to get immediate feedback or improve task descriptions.
*Source: [Part 2 of how to get the most out of your product pass—and welcome, Stripe Atlas, to the bundle!](https://www.lennysnewsletter.com/p/part-2-of-how-to-get-the-most-out-of-your-product-pass-and-welcome-stripe-atlas)*
---
> "I know it can be hard to add yet another person to the room, but the benefit outweighs the risk. A good example is during planning. I have known plenty of PMs that were eager to rush ahead with a list of features they thought the team should build. However, I have seen these same PMs sing a very different tune after including designers in the planning process."
**Insight:** Including designers in early product planning avoids the inefficiencies of waterfall handoffs and leverages their ability to catalyze innovation and advocate for the user.
**Tactical advice:**
- Bring designers into the planning process early to gain a skillful facilitator, user advocate, and storyteller.
- Avoid waterfall handoffs by having designers inform conversations with a salient voice of the user from the start.
- Use visual prototypes and creative ideas during planning to catalyze conversations and drive more thoughtful solutions.
*Source: [The PM 🤝 Design Partnership](https://www.lennysnewsletter.com/p/the-pm--design-partnership)*
---
**Insight:** A clear problem statement must be concise, focused on a single need, and strictly agnostic of any potential solutions.
**Tactical advice:**
- Aim for a single sentence to describe the actual problem.
- Reference a user or business need that is currently unfulfilled.
- List examples of what specific problems the project is not intended to solve.
*Source: [A Three-Step Framework For Solving Problems 👌](https://www.lennysnewsletter.com/p/a-three-step-framework-for-solving-problems)*
---
**Insight:** A structured one-pager forces teams to document the problem, evidence, and success criteria before diving into design or engineering.
**Tactical advice:**
- Complete a 1-pager answering description, problem, why, success, audience, and what.
- Assign a single person, usually the PM, to take the first pass at the document.
- Use the 'Why' section to collect evidence that justifies the team's time investment.
*Source: [A Three-Step Framework For Solving Problems 👌](https://www.lennysnewsletter.com/p/a-three-step-framework-for-solving-problems)*
---
**Insight:** Modern product managers must leverage AI and automation to handle increasing output expectations with fewer resources.
**Tactical advice:**
- Use AI tools to get more done with fewer management layers and resources.
- Hone productivity practices that provide leverage beyond what is traditionally expected of individual contributors.
*Source: [Product manager is an unfair role. So work unfairly.](https://www.lennysnewsletter.com/p/product-manager-is-an-unfair-role-so-work-unfairly)*
---
**Insight:** Aligning the team on a precise problem statement is the most critical step to ensure efficient execution and avoid project churn.
**Tactical advice:**
- Use a one-pager template to crystallize the problem and opportunity for all stakeholders.
- Apply the situation-complication-resolution framework to communicate the project's story.
- Utilize the jobs-to-be-done framework to ensure solutions address actual customer needs.
*Source: [What Seven Years at Airbnb Taught Me About Building a Business](https://www.lennysnewsletter.com/p/what-seven-years-at-airbnb-taught-me-about-building-a-business)*
---
**Insight:** Technical knowledge allows PMs to account for implementation constraints and architectural trade-offs during the planning and design phases of product development.
**Tactical advice:**
- Ask engineers about the database requirements for new features early in the planning stage to avoid late-stage storage issues.
- Factor in time for testing phases like integration and end-to-end tests when setting project timelines.
- Define the specific data needed from API endpoints within your requirements to ensure technical feasibility.
*Source: [Become a more technical product manager](https://www.lennysnewsletter.com/p/become-a-more-technical-product-manager)*
---
**Insight:** High-fidelity interactive prototypes drive better discovery conversations and help teams identify technical edge cases far faster than static text or wireframes.
**Tactical advice:**
- Use tools like v0 or Bolt to build interactive flows that can be demonstrated during discovery.
- Focus prototyping efforts on specific elements being tested to keep discussions focused.
- Maintain a repository of reusable components to quickly assemble interactive mocks for new projects.
*Source: [How to get your entire team prototyping with AI](https://www.lennysnewsletter.com/p/how-to-get-your-entire-team-prototyping-with-ai)*
---
## Maggie Crowley
**Insight:**
*Source: [Mastering product strategy and growing as a PM | Maggie Crowley (Toast, Drift, Tripadvisor)](https://www.youtube.com/watch?v=4LjddcccYIo) @ 00:49:52*
---
## 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."
**Insight:** Transform amorphous concepts into actionable projects by systematically moving them from the 'chaos' of an idea to the 'clarity' of a documented plan.
**Tactical advice:**
- Add clarity to every abstract idea by forcing yourself to write it down as the very first step.
- Develop a visual vision deck for every new project to make the intended outcome visible to the team.
- Iterate through designs and prototypes to refine the concept before seeking mastery or total answers.
*Source: [The woman behind Canva shares how she built a $42B company from nothing | Melanie Perkins](https://www.youtube.com/watch?v=-LywX3T5Scc) @ 00:11:49*
---
## Nickey Skarstad
**Insight:** Analyze the downstream effects of optimizing for immediate conversion to prevent creating a low-quality ecosystem that hurts user behavior in the long run.
**Tactical advice:**
- Look beyond immediate conversion rates to see how changes affect user success days or weeks later.
- Measure the emotional impact of early wins, as these are critical motivators for long-term retention.
- Evaluate if 'success' at the start of a funnel actually translates to a sustainable behavior later in the journey.
*Source: Nickey Skarstad (Airbnb, Etsy, Shopify, Duolingo) on translating vision into goals, operationalizing product quality, second-order decisions, brainstorming, influence, and much more @ 00:42:29*
---
## 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."
**Insight:** Use intense shaping sessions with engineering, product, and design to create a shared, concrete understanding of a project's boundaries before development begins.
**Tactical advice:**
- Gather product, design, and senior engineering leads for short, high-intensity collaborative sessions.
- Create diagrams that represent the core concept without getting bogged down in high-fidelity details.
- Verify technical feasibility early to avoid drastic changes in cost or time during the build.
*Source: [A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up,” early employee at 37signals)](https://www.youtube.com/watch?v=GF-yUANql0c) @ 00:33:19*
---
**Insight:** Successful projects require aggressive sharpening of ideas into a specific, bounded concept to prevent waste and ensure the team reaches the finish line.
**Tactical advice:**
- Narrow down fuzzy requests into specific problems that can be solved within a fixed cycle.
- Ensure the project concept is bounded so the team can see the end from the beginning.
- Filter out "big things" that haven't been distilled into actionable, small-scale work.
*Source: [A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up,” early employee at 37signals)](https://www.youtube.com/watch?v=GF-yUANql0c) @ 00:19:10*
---
**Insight:** Empower builders by handing off a shaped concept that defines the boundaries but leaves the specific implementation details to the team.
**Tactical advice:**
- Provide a shaped diagram rather than a long, rigid PRD to allow for builder ownership.
- Allow the build team to translate the concept into their own implementation tasks.
- Ensure the team understands the "end from the beginning" during the project handoff.
*Source: [A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up,” early employee at 37signals)](https://www.youtube.com/watch?v=GF-yUANql0c) @ 01:04:22*
---
## Scott Belsky
**Insight:** Superior products result from collapsing the artificial boundaries between functions so the entire team can focus on the user's perception of the technology.
**Tactical advice:**
- Break down artificial and constraining boundaries between product, design, and engineering.
- Align the entire cross-functional team around shipping better end-to-end user experiences.
- Review designs across the entire company to raise the bar for the total experience being shipped.
*Source: [Lessons on building product sense, navigating AI, optimizing the first mile, and making it through the messy middle | Scott Belsky (Adobe, Behance)](https://www.youtube.com/watch?v=HCKosdV1J-8) @ 00:35:18*
---
## Shweta Shriva
**Insight:**
*Source: [Product lessons from Waymo | Shweta Shrivastava (Waymo, Amazon, Cisco)](https://www.youtube.com/watch?v=VtNmAjNF3Tc) @ 00:25:40*
---
## Vijay
> "And if you're shipping features that quick leads, you don't have time to stop and think, where does this go, and how does this fit into our overall system architecture? And what started to happen was that we were hitting diminishing returns with some of these features. And not considering the holistic design and consistency meant the reach of every feature was low."
**Insight:** High-velocity feature shipping eventually hits a wall of diminishing returns unless the product is anchored by a consistent system architecture and design building blocks.
**Tactical advice:**
- Identify the minimal number of core building blocks required for your product's system architecture.
- Pivot to a design-led initiative to ensure consistency once high-velocity shipping begins to fragment the user experience.
- Establish design as a key differentiator to improve feature discoverability and reach across the platform.
*Source: [An inside look at Mixpanel’s product journey | Vijay Iyengar (Head of Product)](https://www.youtube.com/watch?v=t-2oXtZrlEc) @ 00:12:09*
---
**Insight:** Traditional estimation should be replaced by appetite-based scoping to optimize for speed and clarity in execution.
**Tactical advice:**
- Define the 'appetite' or time box for a project before deciding on the specific features to build.
- Explore how project requirements change when given different time constraints (e.g., two weeks versus two months).
- Focus on the problems you are trying to solve rather than precise hour-based technical estimates.
*Source: [An inside look at Mixpanel’s product journey | Vijay Iyengar (Head of Product)](https://www.youtube.com/watch?v=t-2oXtZrlEc) @ 00:26:51*
---