🎨The Product Sense Interview
The defining PM interview. 'Design a product for X' or 'Improve X.' Tests judgment about users, problems, and trade-offs.
Product sense is the single most-tested PM interview competency. Failing it eliminates you from most loops, regardless of strength elsewhere.
A product sense interview is a 45-60 minute design exercise. Strong candidates structure with CIRCLES (or similar), prioritize a specific user with a specific pain, generate 3-5 concrete solutions, and evaluate against criteria. The non-obvious thing: interviewers care less about your final solution and more about *how you think*.
The CIRCLES framework (Lewis C. Lin)
- Comprehend the situation. "Tell me more about [product/user/context]."
- Identify the user. Pick a specific persona.
- Report user needs. Articulate the JTBD or pain point.
- Cut through prioritization. Pick the most important need.
- List solutions. 3-5 concrete options.
- Evaluate trade-offs. Score against criteria (impact, effort, fit).
- Summarize recommendation.
Walking through an answer (15-20 min)
Clarify (2 min). "When you say 'design a product for X,' do you mean B2C or B2B? Are we talking US market? Is this a new product or improvement?" Two or three good clarifying questions. Don't over-clarify.
Goal (2 min). "I'll assume our goal is to maximize [user value / engagement / revenue]. Is that right?"
Users (3 min). "Let me think about who'd use this. Three personas: A, B, C. I'd focus on B because [reasoning — usually market size + unmet need]."
Pain points (3 min). "User B's primary pains are 1, 2, 3. The most acute is #1 because [evidence/intuition]."
Solutions (5 min). "Three ideas: (a) ___, (b) ___, (c) ___. Each addresses pain #1 differently."
Evaluation (3 min). "Scoring on impact, effort, fit: solution (b) wins because [reasoning]."
Summarize (1 min). "I'd recommend (b). Validate with [specific test]. Measure success by [metric]."
Throughout: think out loud. The interviewer is scoring your reasoning, not just your conclusion.
What separates A from B answers
- A: Specific user. "Sarah, a freelance designer in Berlin running a 3-person studio."
B: Generic user. "Designers."
- A: Real pain point. "She loses 3 hours every Friday compiling invoices manually."
B: Vague pain. "Designers want better tools."
- A: Trade-offs explicit. "Option (b) is 3x the engineering of (a) but addresses 5x more users."
B: Trade-offs hidden. "Option (b) is best."
- A: Validates assumption. "I'm assuming X based on [evidence]. If I'm wrong, my recommendation changes to Y."
B: Asserts without evidence.
Common prompts to practice
- Design a product for blind people to navigate the subway.
- Design an alarm clock for the deaf.
- Design a fridge for college students.
- Improve Google Maps.
- Improve Instagram for older users.
- Design a product for new parents.
- Design a feature for Slack that improves remote team productivity.
Practice 20+ before interviewing. The fluency from reps is decisive.
Watch-outs
- Don't dive into solutions first. Spend the first third on understanding users and pains.
- Don't pick 7 personas. Pick 1, justify briefly, focus.
- Don't list 12 features. Pick 3 that span the solution space (different mechanisms).
- Don't forget the metric. 'How will we know it worked?' is part of a complete answer.
Key frameworks
Comprehend, Identify user, Report needs, Cut priorities, List ideas, Evaluate, Summarize.
Simpler framework, works equally well.
Real-world examples
Product sense is the #1 interview type at Google, Meta, Stripe, Airbnb. Strong product sense without other gaps usually clears the loop; weak product sense rarely does, regardless of other strengths.
Go deeper — recommended reading
Interview questions (2)
Q1Design a product for blind people to navigate the subway.product sensemid▼
Clarify. "Are we talking a smartphone app or a hardware device? US subway system? Existing users of accessibility tech?" I'll assume smartphone app for adults in US subways.
Goal. Help blind users navigate subway journeys end-to-end with the same independence sighted users have.
User. Sarah, mid-30s, lost vision in adulthood, tech-savvy, daily commuter in NYC. Already uses VoiceOver and BlindSquare. Subway is the most stressful part of her day.
Pain points.
- Knowing which platform / car to board (most acute — wrong train = lost time)
- Knowing where her stop is during the ride
- Navigating crowded stations safely
- Real-time service updates not accessible in audio
#1 is the most acute and the most distinct from existing tools.
Solutions. (a) BLE beacons at platforms. Audio-guides user to correct platform/car. High infrastructure cost; one-time setup. (b) Camera + AI navigation app. Phone camera reads signs, AI describes the path. Works without infrastructure but slower, battery-heavy. (c) Audio integration with subway PA + arrival data. Phone uses GPS + arrival API to announce upcoming stops and platform changes proactively.
Evaluation.
- (a) Infrastructure heavy ($, time), best UX but slow to scale
- (b) Quick to launch, lower UX quality, scales everywhere
- (c) Easiest engineering, integrates with existing data, less "magic"
I'd recommend launching (c) first because it's deployable in months and solves pain #2 and #4. Then test (a) as a beacon pilot in one station. (b) as future R&D.
Validate. Partner with the local accessibility community for testing. Measure: time to complete a known route, error rate (wrong platform), self-reported confidence.
Success metric. Reduce time-to-completion of average commute by 20%. NPS among users 50+.
Q2Improve Google Maps for tourists.product sensemid▼
Clarify. Tourists in a country they're new to. Smartphone-based. Goal: improve their experience.
User. Priya, 28, on a 10-day trip to Tokyo, doesn't speak Japanese, on data abroad.
Pain points.
- Navigating with unfamiliar street layouts and signs in another script
- Finding genuinely good restaurants (Google reviews skew tourist-trap)
- Public transit complex (Tokyo metro, fares, transfers)
- Knowing what's nearby that's worth visiting
I'll prioritize #3 — public transit confusion is what makes most tourists give up and pay for taxis.
Solutions. (a) Visual transit overlay. AR overlay through phone camera: see the next gate to enter, which platform, where to tap your card. Mimics Google's Live View walking. (b) Pre-built trip plans. Tap 'I want to visit X for Y hours.' Get a full transit + walking itinerary, pre-bookmarked. (c) Local 'tourist mode.' Detects you're not a resident, surfaces tourist-friendly explanations, filters reviews by 'verified locals.'
Evaluation.
- (a) High UX value, technically heavy, requires partnership with transit data
- (b) Easier engineering, works today, addresses 'planning' more than 'navigating'
- (c) Foundational, makes other features better
Recommend launching (c) first — tourist mode as a foundational shift. Then build (a) AR transit overlay as a flagship feature.
Validate. Beta with travelers to top 5 visited cities. Measure: time to first 'completed transit journey,' tourist-mode opt-in rate, NPS uplift among tourists.
Success metric. Tourist user retention in destination city. Conversion to 'I'd recommend Maps for traveling.'