Product Sense Interview: 7-Step Framework & Worked Examples

TL;DR:

• Product Sense is the quality of your Product choices under ambiguity, not how neatly you recite a framework.
• Use seven moves as a mental completeness check: clarify → choose user/context → choose a problem → define the outcome → generate distinct mechanisms → choose and trade off → measure and learn.
• Keep facts, assumptions, and hypotheses separate. When the prompt is incomplete, make a reasonable assumption and proceed instead of inventing research or outsourcing every decision to the interviewer.
• The strongest practice is not repeating a polished first answer. It is changing the answer coherently when a follow-up changes the user, evidence, constraint, strategy, or feasibility.
• Use the Product Sense Question Bank to find prompts and the Product Sense Simulator when you want live follow-up pressure.

Table of contents

• What a Product Sense interview actually tests
• Diagnose the prompt before choosing a framework
• The Product Sense Decision Trace
• The 7-step Product Sense mental checklist
• Clarify only what can change the decision
• Use segmentation only when it changes the product decision
• Problem selection is the heart of Product Sense
• Define the outcome before designing the solution
• Generate different mechanisms, not feature variants
• Choose one direction and expose the trade-off
• Measure the problem you actually chose
• Worked example 1: consumer navigation
• Pressure-test the answer when the world changes
• Worked example 2: B2B analytics
• Worked example 3: local-services marketplace
• Weak answer repair: from feature dump to Product decision
• Product Sense interview questions to practice
• Weak vs stronger Product Sense reasoning
• Product Sense self-review without a fake score
• Reusable Product Sense answer checklist
• A deliberate Product Sense practice loop
• Choose the right next interview surface
• FAQ

What a Product Sense interview actually tests

A Product Sense interview asks you to make a defensible product decision with incomplete information. A practical definition is:

Product Sense is the ability to turn an ambiguous product opportunity into a coherent Product decision by choosing a relevant user/context, selecting a meaningful problem, evaluating different mechanisms, making a trade-off, and defining how the decision would be tested.

Good Product Sense is inspectable. The listener should be able to follow why one choice follows from the previous choice and what evidence would make you change direction.

It is not the same as:

• feature creativity;
• visual-design craft or Figma skill;
• inventing a detailed persona;
• naming a prioritization framework;
• listing generic metrics;
• pretending you have customer research the prompt never gave you.

PM Product Sense can include workflow and experience detail, but the center of gravity is Product judgment. A simple mechanism tightly connected to the right problem can be stronger than a flashy AI, social, or gamification idea.

This page owns that specialist reasoning job. The PM Interview Guide owns the full preparation system, the Question Bank owns prompt discovery, and the Interview Simulator owns interactive rehearsal.

Diagnose the prompt before choosing a framework

Do not begin by asking, “Which acronym should I use?” Begin with:

What Product decision is this prompt asking me to make?

Question types overlap. This is a routing aid, not a taxonomy you have to announce in the interview.

Product Design vs Product Improvement

For a Product Design prompt, the user/context and unmet job are often genuinely open. You may need to choose them before you can define a useful problem.

For a Product Improvement prompt, the product already has a job. Start by asking what behavior or journey is underperforming, which users are affected, and what evidence the prompt actually gives you. Do not turn “improve X” into a random feature wishlist.

The Product Sense Decision Trace

Use this as the anatomy of a defensible answer:

Prompt
  ↓
Material assumptions
  ↓
User / context choice
  ↓
Problem choice
  ↓
Desired outcome
  ↓
Distinct solution mechanisms
  ↓
Chosen direction
  ↓
Trade-off / runner-up
  ↓
Success + guardrail
  ↓
Biggest unknown / next learning
  ↓
What would change the decision

The value of the trace is not that every answer must use these headings. It is that each decision has a reason and a reversal condition.

If the interviewer changes the target user, the old user choice may break. If new evidence invalidates the problem, the solution should change. If engineering makes the preferred mechanism infeasible, preserve the outcome and find another mechanism rather than defending the original feature reflexively.

The 7-step Product Sense mental checklist

The current seven-move model remains useful as a mental checklist:

1. Clarify the goal/context only where ambiguity can materially change the approach.
2. Choose a user/context; segment only when different needs would create different Product decisions.
3. Choose a problem rather than listing every plausible pain point.
4. Define the desired outcome before solution ideation.
5. Generate distinct solution mechanisms, not UI variations of one mechanism.
6. Choose one direction and explain why it beats the runner-up and what you sacrifice.
7. Measure and learn with a problem-linked outcome, diagnostic signal, guardrail, and biggest remaining assumption.

Framework is not answer order

A real answer may combine context and user choice, return to segmentation after a follow-up, or revise the solution when new evidence arrives. That is healthy.

The framework is an internal completeness check. The spoken answer should sound like adaptive reasoning:

“The prompt already gives me a very specific user, so I will not invent another segmentation layer. The decision seems to be which part of the handoff workflow creates the most consequential failure. I will choose that problem first, then compare a few mechanisms.”

That is stronger than announcing seven section names before doing any Product thinking.

Clarify only what can change the decision

A useful rule:

Ask only questions whose answer could materially change your approach.

Good clarification targets can include:

• whether this is a new or existing product;
• the target outcome when the prompt leaves it genuinely ambiguous;
• a platform/geography constraint when it changes the experience;
• a meaningful technical, regulatory, capacity, or product constraint;
• whether the problem concerns an existing behavior or a new one.

Before asking a question, test it:

If the answer is X, would I reason differently than if the answer is Y?

If not, make a reasonable assumption and move.

Assume and proceed

A strong phrase is:

“I’ll assume this is an existing mobile product and that the goal is successful repeat usage rather than acquisition. If that assumption is wrong, I would revisit the target journey.”

That makes uncertainty visible without stalling.

What bad clarification looks like

Asking all of these consecutively — “What user? What goal? What market? What budget? What platform? What timeline? What constraints?” — can outsource the Product judgment to the interviewer.

Repair it by selecting the few ambiguities that could change the decision, stating the rest as assumptions, and proceeding.

Use segmentation only when it changes the product decision

Segmentation is useful when different groups have different jobs, constraints, frequency, risk, or behavior that would lead you to build something different.

Useful dimensions often include:

• job to be done;
• frequency or intensity;
• lifecycle stage;
• expertise;
• buyer vs end user;
• marketplace side;
• workflow or usage context.

Demographics can matter, but do not invent demographic personas merely to look user-centric.

Do not segment for performance

Weak:

“Students, professionals, retirees.”

If those labels do not change the need, they add ceremony rather than clarity.

Stronger:

“First-time users who lack history vs recurring users whose prior behavior can support personalization.”

That distinction can change the mechanism you choose.

When not to segment

If the prompt is already specific — for example, “Design a tool for emergency-room nurses managing patient handoffs” — you may already have enough user definition.

Do not mechanically split “younger nurses vs older nurses.” Segment only if workflow, expertise, shift context, frequency, or another dimension changes the problem.

Choose one segment when a choice is required

When several groups are credible, select one using reasons the prompt supports, such as:

• problem intensity;
• frequency;
• strategic relevance;
• learning value;
• reach where it is relevant.

Avoid unsupported claims like “power users are most valuable.” If you do not have evidence, label the choice as a working assumption.

B2B: separate buyer, admin, and user

A B2B prompt may contain a buyer, workspace admin, daily user, manager, and data/technical operator. They are not interchangeable.

Ask which actor’s experience you are designing. Business constraints may come from the buyer while product value is delivered to the user.

Marketplace: choose a side and inspect the cross-side effect

A marketplace answer should make clear which side you are optimizing first and what that choice can do to liquidity, trust, concentration, incentives, or the other side’s experience.

Problem selection is the heart of Product Sense

The most important question is not “What could we build?” It is:

Which user problem deserves our attention first, and why?

Ask:

1. What is the user trying to accomplish?
2. Where does progress break?
3. What consequence matters?
4. Which problem should we focus on first?

A mediocre first solution to the right problem can be improved. A polished solution to the wrong problem is still misdirected.

Pain-point listing is not problem selection

A weak answer might say users find the product “slow, confusing, hard to discover, not personalized, and lacking collaboration” and then jump to features.

A stronger answer selects one blocked job and explains the choice.

When useful, pressure-test the wording with the Problem Statement Generator, but do not let the tool choose the Product priority for you.

Separate prompt fact, assumption, and hypothesis

Many interview prompts contain little real evidence. Keep three categories distinct:

• Prompt fact — information the interviewer actually gave you.
• Assumption — a scope or context choice you are making so you can proceed.
• Hypothesis — something you believe may be true but would need validation in real product work.

Do not say “research shows users struggle with X” when no research was provided.

Prefer:

“My working hypothesis is that transfer failure creates the highest-consequence friction for this user. In real product work I would validate that against journey data and user evidence.”

Product Sense is not fake user research. It is progress under explicit uncertainty.

Define the outcome before designing the solution

Before ideating, answer:

What should become meaningfully better for the user if we solve this problem?

Good outcomes are close to the job:

• recover from a disruption with less uncertainty;
• complete a first meaningful analysis;
• make a safe approval quickly;
• complete a repeat booking with less coordination.

“Improve engagement” is usually too generic unless engagement itself is clearly the user-value behavior in the case.

Connect user outcome to business relevance without forcing revenue

A strong answer can explain both:

• User outcome: what value or behavior improves.
• Business relevance: why that value matters to the product.

Do not force revenue into every Product Sense answer. The business connection should support the user problem, not replace it.

Generate different mechanisms, not feature variants

The goal is not to produce the largest idea list. You need enough breadth to create a meaningful choice.

Weak alternatives:

• recommendations tab;
• recommended cards;
• recommendation carousel;
• AI recommendations.

Those may all be UI variants of the same recommendation mechanism.

Stronger alternatives can change the way value is created:

• improve information or visibility;
• redesign the workflow;
• automate a decision or step;
• change defaults;
• coordinate people socially;
• introduce guidance;
• personalize using existing context;
• alter incentives.

The mechanism test

For every solution direction, ask:

How does this change the user’s situation?

If the answer is only “it adds feature X,” the idea is under-reasoned.

Do not over-design too early

Screen 1 → button → modal → notification is usually too much detail before you have chosen the mechanism.

Stay at Product behavior/mechanism until experience detail is needed to prove the idea works.

When flow detail does help, a compact model is enough:

• trigger — when the user encounters the experience;
• core action — what they do;
• system response — what changes;
• recovery/error — what happens when the mechanism is wrong or unavailable.

Choose one direction and expose the trade-off

Product Sense requires a choice.

Weak:

“We could eventually build all four.”

Stronger:

“I would start with option A because it attacks the selected problem with less irreversible investment. I would defer option B because it depends on behavior history we do not yet have.”

You do not need RICE automatically. For a small set of directions, a qualitative comparison can be more credible than fake precision.

Useful considerations include:

• expected user value;
• confidence;
• effort or feasibility;
• reversibility;
• strategic fit;
• learning value.

Compare #1 with #2

A practical interview heuristic is:

Explain why your first choice beats the runner-up.

That often exposes the real decision criteria more clearly than scoring every idea.

Name what you sacrifice

Trade-offs reveal judgment. Examples include:

• personalization vs speed;
• breadth vs simplicity;
• automation vs control;
• marketplace continuity vs liquidity;
• short-term activation vs long-term sophistication.

Reversibility can be useful when uncertainty is high, but it is not a universal trump card.

Measure the problem you actually chose

A metric section should trace back to the chosen problem.

Weak:

“I would measure DAU, engagement, and NPS.”

Stronger:

“For a disruption-recovery problem, I care whether a disrupted journey is successfully recovered without the user abandoning navigation.”

A practical measurement model is:

• Primary outcome — did the desired user behavior/value occur?
• Leading / diagnostic signal — what helps explain whether the mechanism is working?
• Guardrail — what could improve while the product actually gets worse?
• Next learning — what remaining uncertainty could change the decision?

You do not need a North Star metric in every answer. If the interview becomes primarily about metric systems or diagnosis, switch to the Metrics interview specialist.

Guardrail question

Ask:

What could go up while the experience gets worse?

Examples:

• approval speed rises while decision errors rise;
• rebooking rises while marketplace concentration becomes unhealthy;
• recommendation acceptance rises while correction/undo behavior also rises.

Worked example 1: consumer navigation

The examples below are illustrative practice cases. The assumptions and metrics are hypothetical; they are not claims about a real company, product, or employer interview.

Prompt

Improve a mobile navigation app for people who commute several times per week.

Material assumptions

Assume the product already provides reliable point-to-point routing and can detect major transit disruptions. The goal is to improve the recurring commute experience rather than general travel discovery.

The key hypothesis is that mid-journey transfer disruption creates enough consequence and uncertainty to deserve focus. The prompt itself does not prove that.

User/context choice

Possible contexts include:

• drivers with fixed destinations and variable traffic;
• public-transit commuters with transfers;
• cyclists balancing speed and safety;
• multimodal commuters combining train, walking, and another mode.

Focus on public-transit commuters with one or more transfers because a missed connection can invalidate the current plan and force time-sensitive replanning.

Problem choice

When a disruption occurs mid-journey, the commuter must interpret several alternatives under time pressure without knowing which recovery route is least likely to fail again.

This is more specific than “users need more route options.”

Desired outcome

Help a disrupted commuter recover onto a viable route with less uncertainty and less manual replanning.

Distinct solution mechanisms

1. Automatic recovery guidance — detect the disruption and proactively re-plan from the user’s current position.
2. Risk-aware route comparison — expose fastest vs lower-transfer-risk choices rather than only one “best” route.
3. Commute memory — learn the user’s usual routes and highlight meaningful deviations from familiar patterns.
4. Disruption confidence — show where route uncertainty is concentrated so the user can make the trade-off themselves.

Choice

Start with automatic recovery guidance, with risk information used to rank or explain the proposed alternatives.

Why: it acts at the moment the chosen problem occurs and can create value even before the product has enough individual history for deep personalization.

Runner-up and trade-off

Runner-up: commute memory.

Why it loses initially: it could make recovery feel more familiar, but it depends on enough repeat history and may be less useful for an acute disruption on an unfamiliar variation of the commute.

Trade-off: the first version is less personalized than a history-heavy system, in exchange for being useful earlier and in more disruption contexts.

Measurement

• Primary outcome: share of disrupted journeys that recover to a viable route without navigation abandonment.
• Diagnostic: acceptance/use of recovery suggestions and subsequent route corrections.
• Guardrail: route-error or correction rate after the recovery recommendation.
• Biggest unknown: whether users value familiarity, minimum travel time, or lower disruption risk most when under pressure.

What would change the decision?

If evidence showed that users routinely reject unfamiliar recovery routes even when they are faster, the ranking mechanism should shift toward familiar-route continuity rather than pure recovery speed.

Pressure-test the answer when the world changes

The first answer is only half the test. Follow-ups reveal whether your framework is helping you reason or helping you defend a memorized script.

Useful follow-up types include:

• user/context shift — the target changes from recurring to first-time users;
• constraint shift — capacity or time is cut;
• evidence contradiction — new research conflicts with the core problem assumption;
• metric failure — the primary metric rises but a guardrail breaks;
• strategic shift — the company objective changes;
• solution challenge — engineering says the preferred mechanism is infeasible.

A strong response does four things:

1. states which assumption changed;
2. identifies which part of the reasoning is affected;
3. updates the recommendation;
4. explains what remains stable.

Pressure test: users prefer familiarity over fastest recovery

New evidence:

When disruptions happen, target commuters overwhelmingly prefer familiar recovery routes even when an unfamiliar route is somewhat faster.

Do not defend the original ranking logic just because it was coherent five minutes ago.

Updated reasoning:

• Changed assumption: speed/risk was assumed to dominate familiarity.
• Still stable: the user, disruption-recovery problem, and desired outcome remain valid.
• What changes: route ranking should use familiarity as a first-class input.
• Revised direction: keep automatic recovery guidance, but rank familiar viable routes first and make the faster unfamiliar alternative explicit rather than defaulting to it.

The answer changed where the new evidence touched the decision. It did not restart the entire case unnecessarily.

Pressure test: engineering says the preferred mechanism takes 12 months

Weak response:

“I would still build it because it has the most user value.”

Stronger response:

• preserve the outcome rather than the original implementation;
• identify what part of the mechanism causes the 12-month cost;
• test a smaller reversible version using capabilities already available;
• compare that version again with the runner-up.

For the navigation example, if fully automatic recovery requires a major routing-platform rewrite, a narrower first step could surface disruption-aware alternatives at the moment the user deviates from the route. That preserves learning about recovery behavior without pretending the original build is feasible.

Worked example 2: B2B analytics

Prompt

Improve onboarding for a B2B analytics product used by cross-functional product teams.

Material assumptions

Assume the company has already purchased the product, a workspace exists, and usable product data is instrumented. We are optimizing activation after invitation rather than lead conversion.

That last assumption matters. A follow-up will deliberately remove it.

Actors and user choice

Relevant actors include:

• buyer / leader who justifies the spend;
• workspace admin who configures access;
• PM who needs an answer from the data;
• analyst who manages definitions and data quality;
• stakeholder / consumer who mainly reads outputs.

Design first for the PM trying to answer a real product question. The product value we want to expose is not “completed onboarding”; it is reaching a trustworthy decision-relevant insight.

Problem choice

A newly invited PM sees a powerful analytics environment but cannot connect the interface to the first real question they need to answer, so the product’s capability is visible before its value is.

Desired outcome

Get the PM from first login to one trustworthy, decision-relevant analysis with minimal setup they personally need to understand.

Distinct solution mechanisms

1. Guided first-question workflow that starts from a Product question and maps it to the necessary analysis.
2. Role-based starter views that reduce the blank-canvas problem with relevant defaults.
3. Sample workspace that teaches the product using realistic but non-customer data.
4. Natural-language query assistant that converts a question into an analysis while exposing the definitions it used.

Choice and runner-up

Choose guided first-question workflow.

Runner-up: sample workspace.

Why the guided workflow wins: it can create learning and real customer value in the same session. A sample workspace is easier to make self-contained but can remain disconnected from the customer’s actual definitions and instrumentation.

Trade-off: the guided path is less immediately universal because it depends on the customer’s data being ready and trustworthy.

Measurement

• Primary outcome: newly invited PMs who complete a trustworthy decision-relevant analysis during early active use.
• Diagnostic: completion and abandonment points in the first-question workflow.
• Guardrail: analyses that later require correction because of data-definition or instrumentation issues.
• Biggest unknown: which first-question shapes are common enough to guide without over-constraining the user.

Follow-up: what if instrumented data is usually not ready?

This contradicts a material assumption. The first-question workflow can no longer be the first value path because the required input is missing.

Update the recommendation:

• keep the PM’s desired outcome visible;
• move the initial mechanism toward data-readiness diagnosis + sample-to-real mapping;
• route configuration work to the admin/analyst actor where necessary;
• avoid pretending a query assistant can solve absent or unreliable data.

The actor boundary now matters more: the PM may be the value recipient, but an admin or analyst owns the prerequisite.

Worked example 3: local-services marketplace

Prompt

Improve repeat booking in a local-services marketplace.

Material assumptions

Assume the marketplace already supports a functional first booking and mediates the transaction. The goal is repeat booking, not first-time supply acquisition.

User/context choice

Demand-side use cases can include:

• recurring services where provider continuity matters;
• recurring services where earliest availability matters more;
• occasional urgent services;
• rare high-consideration projects.

Focus on recurring services where the customer prefers the same provider.

Problem choice

After a successful first job, the customer has no lightweight way to turn that relationship into the next booking, so they repeat search, availability checking, and coordination.

Desired outcome

Turn a successful first transaction into a lower-friction second transaction while preserving enough choice and marketplace health.

Distinct solution mechanisms

1. One-tap rebook with the same professional.
2. Availability subscription / preferred-time alerts for the provider.
3. Recurring schedule for predictable services.
4. Trusted-provider shortlist with fallback when the preferred provider is unavailable.

Choice and runner-up

Start with one-tap rebook with an availability-aware fallback.

Runner-up: recurring schedule.

Why the first option wins: it reduces coordination without requiring the customer to commit to a recurring cadence that may not fit every service.

Trade-off: continuity can increase concentration around providers who already have demand, potentially weakening liquidity for others.

Measurement

• Primary outcome: successful second booking within the relevant repeat-service window.
• Diagnostic: rebook initiation and failure reasons.
• Guardrail: provider concentration and failed-booking rate.
• Biggest unknown: how often continuity matters more than earliest availability.

Follow-up: what if providers prefer moving recurring relationships off-platform?

That introduces a new cross-side problem: marketplace leakage.

Do not simply push harder on rebook prompts. Revisit the mechanism and ask what recurring value the marketplace provides to both sides — for example, scheduling convenience, payment reliability, protection, record keeping, or fallback coverage. If the marketplace cannot create enough continuing value, the original rebook mechanism may increase intent without retaining the transaction.

Weak answer repair: from feature dump to Product decision

Start with a realistic weak answer:

“I would improve a music streaming product with AI playlists, social sharing, gamification, and a better recommendation carousel. I would measure engagement.”

The problem is not that the answer is short. The Product judgment is missing.

Failure 1: no user/context choice

We do not know who is struggling or in what situation.

Repair:

Focus on returning listeners who know the kind of listening session they want — focus, workout, discovery, wind-down — but not the exact content.

Failure 2: no selected problem

“Improve streaming” leaves every problem open.

Repair:

The working hypothesis is that these users spend too much effort translating a fuzzy intent into a satisfying session, causing repeated search/skip loops before value starts.

Failure 3: no desired outcome

“Engagement” is not yet a user outcome.

Repair:

Help the listener reach satisfying continuous playback with less setup and correction.

Failure 4: feature dump instead of mechanisms

Create meaningfully different approaches:

• guided intent capture — ask for the current job/mood and a small number of preferences;
• contextual defaults — infer likely intent from time, device, and recent behavior where appropriate;
• session repair — learn from skips/corrections after playback starts and adapt quickly;
• social handoff — start from a trusted person’s session/collection instead of algorithmic discovery.

Failure 5: no choice or trade-off

Choose guided intent capture + fast session repair as the first direction.

Runner-up: contextual defaults.

Why: guided capture works even when context is ambiguous and makes the user’s intent inspectable. The trade-off is extra setup friction; contextual defaults are faster but can feel confidently wrong when inferred context is weak.

Failure 6: metric disconnected from the problem

Measure whether users reach and maintain a satisfying session with less search/skip correction. Use correction/skip behavior as a diagnostic, and guard against a system that reduces user control merely to keep playback running.

Failure 7: no uncertainty

The biggest assumption is that the setup effort is worth the reduction in search/skip loops. A real product team would test that rather than declaring the design correct.

The repaired answer is not better because it has more headings. It is better because each choice has a reason.

Product Sense interview questions to practice

This page does not try to become a 100-question inventory. Use these prompts to practice distinct reasoning patterns, then use the full Product Sense Question Bank for broader coverage.

Product Design

• Design a product that helps roommates coordinate household responsibilities.
• Design a product for parents handling unexpected changes to after-school plans.
• Design a product for first-time managers preparing for difficult one-on-ones.

Product Improvement

• Improve discovery in a music streaming product.
• Improve the first-week experience in a language-learning product.
• Improve saved-item usage in an ecommerce product.

B2B / marketplace

• Improve approval workflows for field supervisors.
• Improve the first useful session in a B2B planning tool.
• Improve repeat purchase in a marketplace where supply availability varies.

Constraint follow-ups

After answering one prompt, introduce one change:

• “The target is now a first-time user. What breaks in your answer?”
• “Engineering capacity is cut in half. What do you preserve?”
• “The primary metric improves but the guardrail worsens. What do you do?”
• “User evidence contradicts your core problem assumption. Where do you rewind the reasoning?”

Do not read a model answer before attempting the prompt. For self-paced Product judgment without interview pressure, use the Product Management Exercises lab.

Weak vs stronger Product Sense reasoning

Product Sense self-review without a fake score

Do not add the dimensions into a total score and interpret the number as “interview ready.” A total can hide the exact weakness you need to practice.

Use descriptive levels instead:

• Missing — the reasoning is not visible.
• Mechanical — the framework step appears, but it does not materially shape the decision.
• Decision-useful — the reasoning changes the recommendation in a meaningful way.
• Resilient — the reasoning remains coherent when assumptions or constraints change.

Review these dimensions independently:

Do not map these levels to Junior, Senior, or Staff. One answer is not a reliable leveling instrument.

Reusable Product Sense answer checklist

Use this for preparation and self-review, not as a speech you read aloud.

# Product Sense decision trace

## Goal / context
- What decision am I making?
- Which assumptions materially matter?

## User / context
- Who am I designing for?
- Do I actually need to segment further?
- Why this user/context?

## Problem
- What is the blocked job?
- Why does this problem deserve focus?
- What is fact vs assumption vs hypothesis?

## Desired outcome
- What should become better for the user?
- Why does that matter to the product/business?

## Distinct mechanisms
- Direction A:
- Direction B:
- Other credible direction if useful:

## Choice + trade-off
- Chosen direction:
- Why it beats the runner-up:
- What I sacrifice/defer:

## Measurement + learning
- Primary outcome:
- Diagnostic signal:
- Guardrail:
- Biggest unknown / next learning:

## Reversal condition
- What new evidence or constraint would make me change the decision?

You do not need to announce these headers in the interview.

A deliberate Product Sense practice loop

A stronger practice loop is:

Learn decision anatomy → inspect a worked example → attempt an unseen prompt → self-review one weak dimension → pressure-test one assumption → practice follow-ups → repeat with a different context

1. Learn the decision anatomy

Use the Decision Trace until you can explain why each Product choice should connect to the previous one.

2. Attempt the prompt without notes

Do not optimize for answer length. Spend more time where the decision is genuinely difficult.

3. Review one or two weak dimensions

Do not repeat the entire case just because one section failed. If problem selection was weak, practice user → problem only on several prompts.

4. Pressure-test the answer

Change one thing: user, capacity, evidence, metric, strategic goal, or feasibility. State which assumption broke and update the recommendation.

5. Move into live follow-up pressure

Use the Product Sense Simulator after the mental model is familiar. The simulator owns unseen scenarios, follow-ups, feedback, and retries; this guide owns the reasoning model.

Real-work bridge

Interview Product Sense is compressed. Real Product work would require actual customer evidence, analytics, stakeholder/technical input, and experiments.

For a slower decision with evidence already provided, use the Product Management Exercises lab. For deeper worked Product decisions outside interview mode, inspect the Product Management Case Studies.

Choose the right next interview surface

Use the specialist that matches your next job:

If you prefer structured interview learning before more reps, use the PM Interview Skills module.

FAQ

What is Product Sense in a PM interview?

Product Sense is the ability to make coherent Product choices under ambiguity: choose the relevant user/context, select a meaningful problem, define the outcome, compare different mechanisms, make a trade-off, and define how you would test whether the decision worked.

Should I use CIRCLES or another named framework?

Use any framework that helps you avoid missing important reasoning. Do not optimize for saying the framework name or following a rigid spoken order. The useful test is whether your user, problem, solution, trade-off, metrics, and uncertainty form a coherent decision chain.

Do I always need to segment users?

No. Segment when different users, jobs, contexts, or behaviors would lead to meaningfully different Product decisions. If the prompt already defines a specific user and job, extra segmentation can add ceremony rather than insight.

How many solution ideas should I generate?

Enough to create a real choice. Two genuinely different mechanisms can be more useful than five feature variants. Do not force an arbitrary number if you already have credible alternatives with different trade-offs.

What if I do not know the product or industry well?

State reasonable assumptions, separate them from facts, and use first-principles reasoning. Do not invent customer evidence or market data. Identify the biggest thing you would need to learn in real product work.

How should I choose metrics in a Product Sense answer?

Start from the problem and desired user outcome. Choose one primary outcome close to that value, add a diagnostic signal that helps explain the mechanism, and add a guardrail for a plausible way the product could get worse while the main metric improves.

What makes a Product Sense follow-up difficult?

A good follow-up changes something your original answer depended on — user, evidence, capacity, strategy, feasibility, or a guardrail. Strong reasoning makes the changed assumption explicit and updates only the affected part of the decision chain.

When should I move to the Interview Simulator?

Move to the Simulator when the Decision Trace is familiar enough that you can attempt an unseen prompt without reading a script. Use the Simulator to expose how your reasoning behaves under follow-up pressure; do not treat any single rubric result as a hiring prediction.