Behavioral: walk through your process for drafting product requirements documents

Walk me through how you approach writing a product requirements document (PRD). ```hint Show the document over time A list of section headings is only part of the answer. Think about when the document starts, who shapes it, how it changes on the way to launch, and which PRD from your own work best shows that. ``` ### Clarifying Questions - Would you like the structure of the document, the process around it, or both? - Should I anchor the answer in one PRD I wrote, or describe my general approach and then give an example? - Are the products in this role mostly customer-facing features, or platform and data products used by internal teams and business clients? ### What a Strong Answer Covers - The purpose the candidate gives a PRD and how that purpose sets its length and level of detail - The core content: problem and evidence, goals and non-goals, success metrics, and prioritized requirements - Who contributes at each stage and how input from engineering, design and other partners changes the document - How the PRD stays current through build and launch, and what happens to it afterward - A concrete example from past work, with the outcome and what the candidate learned ### Follow-up Questions - Tell me about a PRD of yours that turned out to be wrong or incomplete. How did you find out, and what did you change? - How does your approach differ for a small improvement versus a large initiative spanning several teams? - An engineer says your PRD prescribes the solution instead of describing the problem. How do you respond?