PRD from your meeting conversationPRD a partir da conversa da reunião

PromptPrompt

Your task is to write a PRD in the style of Lenny Rachitsky in the below format. First you will read the template structure and advice on how to fill it out using context from my meetings, then you will read the clean template itself, and finally there are style and content instructions.

First response is something like:

“I'm going to ask you a few questions before filling out Lenny's PRD for you. First up: What would you like a PRD for? I can scan your recent meetings and draft a PRD, or you can name the project.”

Propose up to 3 likely candidates using:

**Project:** <inferred title>
- **Why it’s a match:** <1 line>

Wait for user selection (or new project name).

On selection, use only the chosen meeting(s) + clearly related follow-ups (same project keywords/participants within 14 days). Do not merge unrelated threads.

Before drafting the full PRD, crystallize a 1-sentence problem hypothesis from the selected meetings. Show it for quick confirmation.

If the user confirms, proceed to full PRD; otherwise refine and align first.


SECTION I: TEMPLATE STRUCTURE

Instructions: Write a PRD using the format below. Sections 4a, 4b, 4c, and 5 are the longest and require extensive thought. The rest can be a few bullet points maximum. Leave a line break after each major section.

**1. Description: What is it?**  
Describe what you're thinking so that folks reading this doc can quickly understand what this project is all about. Keep it concise and digestible.

[Detailed guidance: The problem statement is foundational - spend extra time here. Think of it like a hypothesis.  
Key attributes of strong problem statements:

- Short: Aim for a single sentence. The more explanation needed, the less clear it becomes
    
- Focused: Single clear problem owned by one team, solvable in reasonable time
    
- References a "need": Focus on user need (or business need). Use Jobs-To-Be-Done framework
    
- Includes what and why: What's going wrong, and why is it a problem?
    
- Solution-agnostic: Resist jumping to solutions early  
    Examples of GOOD problem statements:
    
- "Lyft drivers are canceling 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."  
    Examples of BAD problem statements:
    
- "User growth is slowing." (Too broad, not user-centered)
    
- "Build a loyalty program." (Assumes a solution)
    
- "Users are bouncing from the signup flow." (Not focused enough, missing hypothesis)]
   

---

**2. Problem: What problem is this solving**

**2a. What is the problem this project addresses? (Ideally in 1 sentence)**
- (response)

[See guidance above under Section 1: PROJECT DESCRIPTION.]


**2b. What is your hypothesis for why this problem is happening?**
- (response)


**2c. What problems are you NOT solving?**
- (response)

---

**3. Why: How do we know this is a real problem and worth solving?**

Impact of the Problem:

Business Impact:
- [2-3 strong data points]
    

Customer Impact:
- [2-3 bullet points]
    

[This is where you collect evidence backing up your problem statement. What initially convinced you this was a problem? What makes it clear this needs to be tackled?  

Tips for this section:

- Look at both quantitative and qualitative evidence: Collect all data points pointing to this being real and important
    
- Quality over quantity: 3-5 strong data points better than dozens of weak ones. Your case gets weaker with too many minor/unrelated points
    
- Play devil's advocate: Try to convince yourself this isn't actually real or big enough. What gaps exist in your evidence?
    
- It's a judgment call: Make the best case with available data. Continue refining as you learn more]
    
---

**4. Success: How do we know if we've solved this problem?**  
Define specific, measurable goals that connect to team KPIs.

[This criteria becomes critical throughout the project for decision-making and prioritization. Does feature X increase chances of achieving your goal? If not, cut it.  
Ideally your metrics are:

- Specific with defined goals that are easily measurable
    
- Directly connected to team KPIs
    
- Based on hard data about opportunity size, investment size, and past experiment heuristics  
    Guidelines:
    
- Make it concrete: Try for specific numbers (e.g., 10% increase in X, 50% decrease in Y, 20% adoption of feature Z within 3 months)
    
- Believable but ambitious: What goal would excite your team and leaders?
    
- If metrics don't make sense: Concretely describe what success looks like in the world]
    

---

**5. Audience: Who are we building for?**  
 Be concise and specific.

---

**6. What: Roughyl, what does this look like in the product?**  
Link to designs if available.

[This is where you describe the solution to the problem. Detail level depends on team operations and current knowledge.  
Key tip: Align with designers on how much detail they want and what would be most helpful in their process.]

---

**7. How: What is the experiment plan?**  


---

**8. When: When does it ship and what are the milestones?**  


Structure as: Milestone, Date, Risks, Mitigations

[Detailed guidance: Structure each milestone with these four elements:

Milestone: [Description]  
- Date: [Timeline]
- Risks: [Potential blockers]
- Mitigations: [How to address risks]  
    For unconfirmed timelines, be clear they're tentative and specify who can confirm.]
    

---

Template Output Structure:

# 1. Description: What is it?

Describe what you're thinking so that folks reading this doc can quickly understand what this project is all about. Keep it concise and digestible.

---

# 2. Problem: What problem is this solving?

 **2a. What is the problem this project addresses? (Ideally in 1 sentence)** 
 - [response]
 **2b. What is your hypothesis for why this problem is happening?** 
 - [response]
 **2c. What problems are you NOT solving?**
 - [response]

---

# 3. Why: How do we know this is a real problem and worth solving? 

Impact of the Problem: 

**Business Impact:**  
- [2-3 strong data points]

**Customer Impact:**  
- [2-3 bullet points]

---

# 4. Success: How do we know if we’ve solved this problem?
Define specific, measurable goals that connect to team KPIs. 

---

# 5. Audience: Who are we building for? 
Be concise and specific. 

---

# 6. What: Roughly, what does this look like in the product?
 Link to designs only if available. 

---

# 7. How: What is the experiment plan?

---

# 8. When: When does it ship and what are the milestones?
When does it ship and what are the milestones?

Structure as: Milestone, Date, Risks, Mitigations

FORMATTING RULES
- Use bold for all section headings
- Write in full sentences where needed
- Use bullets for bullet points
- Leave a line break between sections
- Keep everything scannable and professional

CONTENT RULES
- Do not invent answers where you can't find them, or infer what you think reasonable answers might be
- It is ok to leave a section blank, or indicate that the answer wasn't found in the source material. 

You are now ready to fill out Lenny's PRD template and create an essential and helpful bit of documentation for my team.