Product Sense Interview AnswerSAFE

Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: product-sense-interview-answer
argument-hint: "[interview prompt]"
description: 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.
intent: >-
  Coach PM candidates through open-ended product-sense interviews using a repeatable
  six-part answer spine: clarify, rationale, goal, segmentation, pain points,
  and solution choice. Use this to practice product design and product improvement
  questions, avoid solution-first answers, and produce responses that sound
  thoughtful out loud rather than over-scripted on the page.
type: component
theme: career-leadership
best_for:
  - "Practicing product design and product improvement interview questions"
  - "Coaching candidates who jump to solutions too quickly"
  - "Turning messy ideation into a crisp spoken interview answer"
scenarios:
  - "How would you improve YouTube?"
  - "Design a product for travelers with flight anxiety"
  - "What would you build next for DoorDash?"
estimated_time: "20-30 min"
---

## 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

### The Six-Part Answer Spine

1. **Clarify** - Reduce ambiguity, define scope, and state assumptions.
2. **Rationale** - Explain why the problem matters now for the market and, if relevant, the company.
3. **Product Goal** - Define the user outcome you want to create before talking about features.
4. **Segmentation** - Choose who to serve first and show why that target wins.
5. **Pain Points** - Map the journey, name the main frictions, and pick the one worth solving first.
6. **Solution** - Generate distinct options, compare them, and commit to one MVP with clear exclusions.

The order matters. If you skip from prompt to feature ideas, your answer sounds clever but ungrounded. If you establish the user, goal, and pain first, your solution feels earned.

### Why This Works

- **Prevents feature dumping:** You do not start with ideas before you know whose problem you are solving.
- **Balances user and business thinking:** The answer includes demand, company fit, and strategic tradeoffs rather than pure UX talk.
- **Creates a speakable narrative:** Each section becomes a short checkpoint the interviewer can follow.
- **Forces prioritization:** Reach, impact, fit, frequency, severity, and effort all surface tradeoffs instead of hand-wavy optimism.

### Anti-Patterns (What This Is NOT)

- **Not a feature brainstorm:** Listing ideas without choosing a target user or problem is not product sense.
- **Not a TAM presentation:** You do not need made-up market numbers to sound strategic.
- **Not a memorized monologue:** Rigid scripts break as soon as the interviewer redirects or narrows scope.
- **Not a business-case-only answer:** Product sense still requires empathy, behavior, and user context.

### When to Use This

- Product design questions
- Product improvement questions
- "What would you build next?" prompts
- Mock interviews where you want a repeatable spoken structure

### When NOT to Use This

- Behavioral interviews that need STAR stories
- Execution and analytics cases that revolve around metrics diagnosis
- Go-to-market or pricing interviews where distribution or monetization is the main problem

## Application

Use [`template.md`](template.md) as the working structure.

### Delivery Rules

- State your structure early so the interviewer knows where you are going.
- Ask only 1-2 clarifying questions. More than that feels like stalling.
- Keep lists MECE where possible: segments should be distinct, pain points should not overlap, and solutions should not be three versions of the same thing.
- Speak in short sentences. Interview answers should sound conversational, not like a memo read aloud.
- If the prompt does not name a company, use a startup assumption and skip fake company-mission talk.

### Step 1: Clarify the Prompt

Start by surfacing the two ambiguities that change the answer most. Good clarifiers usually narrow:

- Product or surface area
- User group
- Time horizon
- Business model or operating constraints

If the interviewer does not answer, state your assumptions and move on. The goal is to unblock the rest of the answer, not to turn the interview into requirements gathering.

**Quality bar:** Ask questions that materially change the solution. "Are we talking mobile or desktop?" 

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.