How do you write a product spec or PRD that engineers find useful?
What the interviewer wants to hear
- Clear problem, users and evidence
- Goals, success metrics and non-goals
- Requirements and user stories with acceptance criteria
- Edge cases and open questions; collaborate with the team
Model answer
A useful spec is short and focuses on why and what. I start with the problem, who it affects and the evidence, such as data or customer quotes. Then I write the goals and success metrics, and the non-goals, which are just as important because they stop scope from growing. Next come the requirements, usually as user stories with acceptance criteria, plus key edge cases like errors, permissions and empty states. I add links to designs and list open questions instead of hiding uncertainty. I do not write technical solutions; that is for engineers. Most importantly, I write it with the team, not alone. I share an early draft, get questions from engineers and designers, and update it. A spec is a living document until we ship.
Can you answer it under time pressure?
Take a timed medium round and get scored on every answer.
More medium Product Manager questions
- How would you define success metrics for a new feature?
- How do you say no to a stakeholder request?
- How do you run customer discovery for a new problem area?
- Tell me about a feature that did not perform as expected. What did you do?
- Leadership wants to change your product's pricing. How would you approach it?
- Walk me through how you plan a major product launch.
- Your A/B test finished and the result is not statistically significant. What do you do next?
- How would you set OKRs for your product team for next quarter?
- How would you tell whether a new product has product-market fit?