jshmllr · September 17, 2024 13:04
diff --git a/PRD-Writer-Prompt b/PRD-Writer-Prompt
 We're writing a Product Requirements Document (PRD) for the business.

 Why Do Product Teams Use PRDs?
 A PRD aligns all stakeholders. If teams don’t take the time to think deeply about what the goals are, clearly define success, scope, and assess risk, at some point inevitably someone will run into challenges. Without a PRD, the great risk is that each team member has a slightly different understanding of the project, which will later require backtracking to clarify and correct further down the line resulting in wasted time. So why should designers care about a PRD and why should you? So we have a deep understanding of what we're trying to achieve—as a business.
 So we can be involved in planning. We should be an active participant and not passively receive the PRD from a product manager. Understand what we're being given by a product manager in order to contribute and even disagree. As a design team we're probably directly or indirectly involved in processes that influence the PRD such as customer interviews. Be sure that the integrity of the user is kept in addition to achieving business goals. PRDs create clarity out of chaos. Add to the design backlog. Track the improvements you want to make. For the sake of sprint planning and measuring outcomes, work with what’s within scope but don’t forget potential future wins.
 Benefits of PRDs
 Organization: Have a source of truth. Keep the team organized around each project, documentation, and resources.
 Purpose: Make the purpose of the project explicit. Give the team a chance to understand the purpose. Quality: Enable the team to focus on quality and not get caught up in confusion around details. Accountability: Make it clear who is responsible for each task and what decisions were made.
 Scale: Allow the team to scale up as it continues to iterate or build on what has already been done. Have a document to refer back to when iterating.
 Speed: The PRD takes some time but enables speed by making clarifying requirements up front and decreasing the chance for a change in goals or scope.
 Team Empowerment: The entire team participates and gives input on their area of expertise thus empowering each individual to contribute.
 Considerations
 Be succinct, keep it 1–2 pages max
 Define the what, not the how, leave that to the human experts Include background and strategic fit
 Why are we doing this?
 How does this fit into the overall company objectives? How does it fit into (quarterly) planning?
 Manage your time — define what’s out of scope prior to starting the project Pay attention to what could be done and how it influences scope creep
 2. Share PRD With Stakeholders
 Have everyone comment thoughts, ideas, opinions, objections
 3. Address Comments and Achieve Alignment With Stakeholders Incorporate feedback and achieve consensus
 4. Assess If a Meeting Is Necessary for Kickoff or Discussions
 Determine if a meeting is needed to align on project kickoff or further discussions
 Why Should Designers Care About a PRD?
 Understanding: Have a deep understanding of what we're trying to achieve—as a business.
 Involvement: Be involved in planning. Be an active participant and not passively receive the PRD from a product manager.
 Contribution: Understand what we're being given by a product manager in order to contribute and even disagree.
 Customer Integrity: As a design team, we’re probably directly or indirectly involved in processes that influence the PRD such as customer interviews. Ensure that the integrity of the user is kept in addition to achieving business goals.
 Clarity: You may end up in a startup where you need to come into a chaotic situation and create clarity with a PRD.
 Design Backlog: Add to the design backlog. Track the improvements you want to make. For the sake of sprint planning and measuring outcomes, work with what’s within scope but don’t forget potential future wins.

 Steps to Draft the PRD
 Take into account:
 Target audience: who are we designing the feature for. Think in terms of demographics, interests, and any specific pain points they might have around the problem.
 Unique features: Are there any specific features you envision that makes the feature stand our from existing features in the market? This could include customization options, etc.
 Monetization strategy: How do we plan to generate revenue from this feature if any? Subscriptions? Up-sells? Or is this just achieving product market fit?
 Technical constraints: Any particular technical platforms (iOS, Android, Web) or constraints we should consider while designing the new feature?

 Then
 1. Draft the PRD Basic Information
 Project Name: Date Last Updated: Participants:
 Create a tl;dr
 Who Is Involved? Include the product owner, team, stakeholders
 Status: What’s the current state of the program? (e.g., on target, at risk, delayed, deferred)

 When is it projected to ship?
 The Problem & The Research That Indicates This is a Problem
 Detailed description of the problem Supporting research
 Assumptions/Hypothesis
 List of assumptions or hypotheses driving the project Definitions
 Definitions of key terms and concepts Goals
 Clear and measurable goals of the project Success Metrics
 Ways to measure success
 The test plan (e.g., rollout, how long to wait until verdict)
 Release Criteria
 1. Functionality:
 Original features to retain
 Mandatory functions
 Nice to haves 
 2. Usability:
 Is the program aesthetically pleasing to users? Does it use the right components?
 Is it consistent with the brand?
 3. Reliability:
 Acceptable failure rate
 Can the system recover from failures? 
 4. Performance:
 Maximum response time
 Does it deliver what is promised in maturity? 
 5. Supportability:
 Is it testable, serviceable, installable, and configurable? 
 Risks: Identification of potential risks and mitigation strategies User Stories & Narrative
 Who are the users?
 What is their use case?
 What do they need?
 What are they trying to accomplish?

 Success Metrics like user adoption rate, conversion, satisfaction, engagement, etc.

 Any milestones and sequencing?

 Optional: create a tech spec for the frontend, backend, apis and integrations, security, and analytics. Ensure the system scales.
 Optional: include future considerations for enhancement

 Section for Product Design
 Design Deliverables:
 e.g., research, copy, sitemap, user flows, actual designs, prototypes
 Questions
 What questions does the PRD prompt?
 What is unclear? (Sometimes this is best done as comments)
 Resources
 e.g., product roadmap in Jira or Productboard, research findings from Productboard or elsewhere, customer interview links, analytics from Pendo
	We're writing a Product Requirements Document (PRD) for the business.

	Why Do Product Teams Use PRDs?
	A PRD aligns all stakeholders. If teams don’t take the time to think deeply about what the goals are, clearly define success, scope, and assess risk, at some point inevitably someone will run into challenges. Without a PRD, the great risk is that each team member has a slightly different understanding of the project, which will later require backtracking to clarify and correct further down the line resulting in wasted time. So why should designers care about a PRD and why should you? So we have a deep understanding of what we're trying to achieve—as a business.
	So we can be involved in planning. We should be an active participant and not passively receive the PRD from a product manager. Understand what we're being given by a product manager in order to contribute and even disagree. As a design team we're probably directly or indirectly involved in processes that influence the PRD such as customer interviews. Be sure that the integrity of the user is kept in addition to achieving business goals. PRDs create clarity out of chaos. Add to the design backlog. Track the improvements you want to make. For the sake of sprint planning and measuring outcomes, work with what’s within scope but don’t forget potential future wins.
	Benefits of PRDs
	Organization: Have a source of truth. Keep the team organized around each project, documentation, and resources.
	Purpose: Make the purpose of the project explicit. Give the team a chance to understand the purpose. Quality: Enable the team to focus on quality and not get caught up in confusion around details. Accountability: Make it clear who is responsible for each task and what decisions were made.
	Scale: Allow the team to scale up as it continues to iterate or build on what has already been done. Have a document to refer back to when iterating.
	Speed: The PRD takes some time but enables speed by making clarifying requirements up front and decreasing the chance for a change in goals or scope.
	Team Empowerment: The entire team participates and gives input on their area of expertise thus empowering each individual to contribute.
	Considerations
	Be succinct, keep it 1–2 pages max
	Define the what, not the how, leave that to the human experts Include background and strategic fit
	Why are we doing this?
	How does this fit into the overall company objectives? How does it fit into (quarterly) planning?
	Manage your time — define what’s out of scope prior to starting the project Pay attention to what could be done and how it influences scope creep
	2. Share PRD With Stakeholders
	Have everyone comment thoughts, ideas, opinions, objections
	3. Address Comments and Achieve Alignment With Stakeholders Incorporate feedback and achieve consensus
	4. Assess If a Meeting Is Necessary for Kickoff or Discussions
	Determine if a meeting is needed to align on project kickoff or further discussions
	Why Should Designers Care About a PRD?
	Understanding: Have a deep understanding of what we're trying to achieve—as a business.
	Involvement: Be involved in planning. Be an active participant and not passively receive the PRD from a product manager.
	Contribution: Understand what we're being given by a product manager in order to contribute and even disagree.
	Customer Integrity: As a design team, we’re probably directly or indirectly involved in processes that influence the PRD such as customer interviews. Ensure that the integrity of the user is kept in addition to achieving business goals.
	Clarity: You may end up in a startup where you need to come into a chaotic situation and create clarity with a PRD.
	Design Backlog: Add to the design backlog. Track the improvements you want to make. For the sake of sprint planning and measuring outcomes, work with what’s within scope but don’t forget potential future wins.

	Steps to Draft the PRD
	Take into account:
	Target audience: who are we designing the feature for. Think in terms of demographics, interests, and any specific pain points they might have around the problem.
	Unique features: Are there any specific features you envision that makes the feature stand our from existing features in the market? This could include customization options, etc.
	Monetization strategy: How do we plan to generate revenue from this feature if any? Subscriptions? Up-sells? Or is this just achieving product market fit?
	Technical constraints: Any particular technical platforms (iOS, Android, Web) or constraints we should consider while designing the new feature?

	Then
	1. Draft the PRD Basic Information
	Project Name: Date Last Updated: Participants:
	Create a tl;dr
	Who Is Involved? Include the product owner, team, stakeholders
	Status: What’s the current state of the program? (e.g., on target, at risk, delayed, deferred)

	When is it projected to ship?
	The Problem & The Research That Indicates This is a Problem
	Detailed description of the problem Supporting research
	Assumptions/Hypothesis
	List of assumptions or hypotheses driving the project Definitions
	Definitions of key terms and concepts Goals
	Clear and measurable goals of the project Success Metrics
	Ways to measure success
	The test plan (e.g., rollout, how long to wait until verdict)
	Release Criteria
	1. Functionality:
	Original features to retain
	Mandatory functions
	Nice to haves
	2. Usability:
	Is the program aesthetically pleasing to users? Does it use the right components?
	Is it consistent with the brand?
	3. Reliability:
	Acceptable failure rate
	Can the system recover from failures?
	4. Performance:
	Maximum response time
	Does it deliver what is promised in maturity?
	5. Supportability:
	Is it testable, serviceable, installable, and configurable?
	Risks: Identification of potential risks and mitigation strategies User Stories & Narrative
	Who are the users?
	What is their use case?
	What do they need?
	What are they trying to accomplish?

	Success Metrics like user adoption rate, conversion, satisfaction, engagement, etc.

	Any milestones and sequencing?

	Optional: create a tech spec for the frontend, backend, apis and integrations, security, and analytics. Ensure the system scales.
	Optional: include future considerations for enhancement

	Section for Product Design
	Design Deliverables:
	e.g., research, copy, sitemap, user flows, actual designs, prototypes
	Questions
	What questions does the PRD prompt?
	What is unclear? (Sometimes this is best done as comments)
	Resources
	e.g., product roadmap in Jira or Productboard, research findings from Productboard or elsewhere, customer interview links, analytics from Pendo