Product Sense Interview Answer
Structure a spoken PM product-sense answer with assumptions, segmentation, pain-point...
Install
npx skills add deanpeters/Product-Manager-Skills --skill product-sense-interview-answer -g -a claude-code -y- Repository
- deanpeters/Product-Manager-Skills7.8k
- Category
- Design
- Updated
- 20d ago
- License
- See repository
- Context cost
- Mediumabout 2,681 tokens
- Runs scripts
- No, instructions only
What it does
Structure a spoken PM product-sense answer with assumptions, segmentation, pain-point prioritization, and MVP tradeoffs. Use when practicing design, improve, or build-next interview questions.
Purpose
Help PM candidates and interview coaches structure product-sense answers that sound strong out loud, not just on paper. Use this when practicing prompts like "How would you improve X?", "Design a product for Y", or "What would you build next for Z?"
This is not a memorize-and-recite script. It is a reasoning scaffold that prevents solution-jumping, forces real prioritization, and leaves the interviewer with a clean story they can follow.
Input
Works best with: The interview prompt you're practicing (e.g., 'How would you improve X?', 'Design a product for Y'). Also useful: The company/role you're interviewing for and how much time the answer gets.
Anything supplied with the invocation itself, text after the skill name, a pasted context dump, or an appended ARGUMENTS: line, counts as answers already given. Use it and skip whatever it covers; don't re-ask.
Arriving empty-handed? That works too. The skill asks for the prompt, then walks the reasoning scaffold with you out loud.
Example invocation: Practice this: 'How would you improve Google Maps for commuters?', 25-minute answer, L5 PM loop.
Key Concepts
What Product Sense Interviews Actually Test
Strong product-sense answers do more than generate ideas. Interviewers are usually testing whether you can:
- Clarify ambiguous prompts without getting stuck
- Tie user value to market or business logic
- Segment thoughtfully instead of talking about "everyone"
- Prioritize one pain point instead of describing ten equally
- Make tradeoffs explicit when choosing an MVP
- Communicate clearly under time pressure
