# Writing PRDs — Quiz

## Question 1

Which of these is a problem statement rather than a solution?

A) Users need a dark mode toggle
B) Users report eye strain when using the app in low-light for 30+ minutes, reducing engagement
C) We should add a settings page for appearance options
D) The design team wants to support dark mode

<!-- ANSWER: B -->
<!-- EXPLANATION: A problem statement focuses on user pain (eye strain, reduced engagement) without prescribing a fix. A, C, and D either describe solutions (toggle, settings page) or stakeholders, not the underlying problem. -->

## Question 2

What does the JTBD framework help you capture?

A) Technical implementation details
B) The user's situation, motivation, and desired outcome
C) Competitor feature comparisons
D) Engineering estimates

<!-- ANSWER: B -->
<!-- EXPLANATION: Jobs To Be Done captures: When [situation], I want to [motivation], so I can [outcome]. It's about user context and value, not technical specs, competitors, or estimates. -->

## Question 3

Why are non-goals important in a PRD?

A) They make the document longer and more impressive
B) They prevent scope creep by explicitly stating what's out of scope
C) They replace the need for success metrics
D) They are required for legal compliance

<!-- ANSWER: B -->
<!-- EXPLANATION: Non-goals explicitly state what you're NOT building. Stakeholders often assume "everything related" is in scope; non-goals deflect those assumptions and keep the team focused. -->

## Question 4

Which success metric is MOST actionable?

A) Improve user satisfaction
B) Increase NPS from 42 to 50 by end of Q3
C) Make the product better
D) Users should like it more

<!-- ANSWER: B -->
<!-- EXPLANATION: A good success metric has a specific measure (NPS), a baseline (42), a target (50), and a timeframe (Q3). A, C, and D are vague and impossible to track or act on. -->

## Question 5

What is the main anti-pattern of "solution-first thinking"?

A) Writing too many user stories
B) Defining the solution before understanding the problem
C) Including too many success metrics
D) Skipping the non-goals section

<!-- ANSWER: B -->
<!-- EXPLANATION: Solution-first thinking jumps to features (e.g., "we need X") before validating the problem. The PRD should start with the pain and outcome, not the proposed fix. -->

## Question 6

In the PRD lifecycle (Problem → Research → PRD → Review → Build), what role does Research play?

A) It's optional—you can skip it for small features
B) It validates the problem and informs the PRD with data and user input
C) It happens only after the PRD is approved
D) It replaces the need for a PRD

<!-- ANSWER: B -->
<!-- EXPLANATION: Research (interviews, data, competitive analysis) validates the problem and provides evidence that informs the PRD. Without research, the PRD is guesswork. Research comes before the PRD, not after. -->

## Question 7

<!-- VISUAL: quiz-drag-order -->

Put these PRD sections in the recommended order for the document:

A) Success metrics
B) Problem statement
C) Solution and requirements
D) Non-goals
E) User stories / JTBD

<!-- ANSWER: B,E,A,C,D -->
<!-- EXPLANATION: Start with the problem statement, then user stories or JTBD to capture value. Define success metrics before solution details. Describe the solution and requirements, and close with non-goals to prevent scope creep. -->

## Question 8

<!-- VISUAL: quiz-drag-order -->

Put these problem-to-spec steps in the correct flow:

A) Write PRD
B) Validate problem (research, data)
C) Identify problem and outcome
D) Review with stakeholders
E) Build and iterate

<!-- ANSWER: C,B,A,D,E -->
<!-- EXPLANATION: Identify the problem and desired outcome first. Validate with research and data. Write the PRD. Review with stakeholders for alignment. Then build and iterate based on feedback. -->