Product sense: from a vague prompt to a defensible product
Learn to choose a user, prioritize one problem and defend a coherent first release. Product sense and product design are treated as one topic here; the emphasis is on the decision, not the alias.
Original PMMockr learning guide · Examples are illustrative, not company interview transcripts.
Before you start
Know one product’s main task and current alternatives; use hypotheses when user research is unavailable.
What you will learn
- Segment by a meaningful need or constraint.
- Compare different solutions to the same selected need.
- Define a coherent first release and a falsifiable value test.
Read the explanation, attempt the problem yourself, then compare the worked answer.
Improve meal planning for households that shop together.
Original teaching scenario. Any figures are illustrative assumptions.
Scope and assumptions
- Assume repeated shopping coordination is the target outcome.
- Pain points below are hypotheses to validate, not interview research already conducted.
How to tackle this question
- Name the household and the moment of coordination. Ask whether duplicated purchases or discovering meals is the more important problem.
- Compare two mechanisms for the selected need, such as a shared list and item ownership. Explain what the first release must do when an edit fails.
- Define a useful completed outcome, its measurement blind spot and a test that could disprove the need.
Try a short outline and spoken answer before comparing.
Reveal model solution and reasoning
Choose the problem
I would compare households coordinating a weekly shop with occasional recipe browsers. For the coordinating group, I would test whether duplicate purchases are more costly than discovering recipes.
Compare and scope
A shared list directly addresses duplicated purchases; pantry recognition could help but adds data and correction complexity. I would start with a shared editable list, clear ownership and reversible item changes.
Measure and learn
I would measure households completing a coordinated shop in a stated week, using confirmation feedback to validate the event. I would monitor notification opt-outs and access problems rather than counting list edits as value.
Interviewer follow-up
What if a household member often has no connection in the store?
Offline viewing and queued edits become part of the minimum coherent experience. I would show sync status, avoid silently overwriting changes and test conflict recovery before rollout.
Check your reasoning
- Did I compare user needs before proposing features?
- Does the first release solve the selected problem end to end?
- Can I explain a blind spot in my success metric?
Try a changed constraint
Choose a different coordination problem and defend two genuinely different solutions before selecting one.
Go deeper
A segment is useful when its needs change the decision; demographics alone are insufficient.
Choose a validation method that can disprove the riskiest assumption; a clickable prototype may test comprehension but not repeated household coordination.
Start with the vocabulary
Clarification
A question that resolves an ambiguity which could change your recommendation. Clarify the goal, audience, scope, constraints and time horizon; do not ask a long list of questions just to follow a template.
“Are we improving the experience for first-time riders or increasing repeat rides?” These goals could lead to different products.
Common mistake: Asking about button colors before knowing which user problem matters.
User segment
A group whose needs, behavior or constraints differ enough to require a different product decision. Compare segments, choose one and explain why it is worth prioritizing now.
In a navigation app, an unfamiliar-city commuter may need confidence about transfers; a familiar-route commuter may need disruption alerts.
Common mistake: Treating everyone aged 18–35 as having the same need.
Minimum viable product
The smallest coherent experience that lets you test an important value or feasibility assumption. An MVP still has to work safely from start to finish for its intended user.
Test scheduled pickup at a small set of stores before building a nationwide delivery marketplace.
Common mistake: Calling a list of partially working features an MVP.
North Star metric
A primary measure of the value customers repeatedly receive from a product. Define the event, eligible population and time window. It should connect customer value to a sustainable business outcome.
For a learning tool, weekly learners completing a useful practice session can be more informative than total registrations.
Common mistake: Choosing revenue or daily activity without explaining how it reflects value for this product.
Guardrail metric
A measure that tells you whether improving your main objective is causing unacceptable harm elsewhere. Name the downside, how you measure it and what action a breach would trigger.
A faster checkout experiment can improve conversion while increasing refund requests. Track refund rate alongside conversion and agree a rollback threshold before the experiment.
Common mistake: Listing “quality” as a guardrail without an observable measure or decision rule.
Build your answer, layer by layer
This is a learning sequence, not a mandatory order for presenting every answer. Adapt to the actual question.
Clarify the decision
Translate the prompt into an outcome for a user and a business. Ask only questions whose answers would change your direction.
Apply it: For a meal-planning app, ask whether the goal is reducing planning effort or improving grocery conversion.
Go deeper: State what you will assume if the interviewer leaves the scope open.
Connect the goal to the product
Explain why the problem is worth solving in this product and why now. Separate the customer benefit from the company benefit.
Apply it: Less time planning could increase weekly repeat use; that is a hypothesis, not an established fact.
Go deeper: Explain why an adjacent competitor might solve the same need differently.
Choose a user segment
Compare users by behavior, urgency and constraints. Choose a segment with a clear reason rather than naming a persona and moving on.
Apply it: Prioritize busy households coordinating meals over occasional recipe browsers if coordination is the selected pain.
Go deeper: Discuss which underserved users your initial focus excludes.
Map the journey and prioritize pain
Walk through what happens before, during and after the task. Identify the most consequential friction using frequency, severity and alternatives.
Apply it: A household may agree on meals but still duplicate shopping because lists are not shared.
Go deeper: Distinguish a root problem from a symptom and identify evidence you would seek.
Explore distinct solution directions
Generate alternatives that solve the same selected problem in different ways. Explain the mechanism of value for each.
Apply it: Compare a shared list, automatic pantry reminders and a lightweight meal agreement flow.
Go deeper: Include a non-AI option and explain when it is sufficient.
Choose and scope an MVP
Compare benefit, effort, risk and learning value. Describe the smallest end-to-end experience and explicitly defer less important features.
Apply it: Start with a shared editable list and change notifications; defer automatic pantry recognition.
Go deeper: Name the riskiest assumption and how the MVP tests it.
Define success and guardrails
Choose a value-oriented outcome and diagnostic input metrics. Add measures for harm introduced by your own design.
Apply it: Measure households completing a coordinated weekly shop, with notification opt-outs as a guardrail.
Go deeper: Explain denominator, window, attribution and possible metric gaming.
Address failure and inclusion
Consider edge cases, abuse, accessibility, privacy and operational failure. Choose mitigations proportional to the product risk.
Apply it: Allow correction and offline access rather than assuming every household member is always connected.
Go deeper: Explain which failure would block launch and who owns its resolution.
Launch and learn
Stage rollout, name the evidence needed to continue and explain how you would investigate mixed outcomes.
Apply it: Pilot with a small eligible cohort before expanding; check whether coordination improved rather than counting taps.
Go deeper: Separate novelty effects from repeat value and plan a rollback.
Synthesize the recommendation
Close with the chosen user, problem, product, reason and success measure. State the most important uncertainty.
Apply it: “For coordinating households, I would test a shared list because duplication is the key friction.”
Go deeper: Explain the next decision you would make if the pilot disproves your assumption.
Move from audience to a specific moment
Start with a task someone is struggling to complete, not an age range. For shared shopping, a weekly household coordinator and an occasional recipe browser may use the same app for different reasons. Compare severity, frequency and current workarounds before choosing the coordination need. Interviews or observation can challenge that hypothesis; do not introduce invented research participants as evidence.
Compare mechanisms, then test the fragile link
After selecting duplicate shopping as the problem, compare a shared list, responsibility assignment and pantry reminders. A recipe recommender addresses a different need and is not a useful comparator here. Choose a complete flow including edit, access and recovery behavior. A prototype may establish comprehension, while a real pilot is needed to assess repeated coordination. Track completed useful shopping and unwanted notifications, and explain what observation would make you abandon the idea.
Connect the reading to this case
Practice answering before watching or reading a sample. In this lesson, preserve your original choice so you can compare the assumptions behind it.
Jason Girouard: The PM Job Search, Practical GuideHow would you test a change to reduce frustration with Google Maps?
Attempt this second problem before comparing. Behavioral answers must use a true experience.
Compare with PMMockr’s worked solution
Original public teaching answer; hypothetical figures and fictional experience are not results to claim as your own.
I would define frustration as a specific task failure before designing the experiment. Assuming driving in a region that supports offline maps, I would focus on occasional rural travelers preparing for a trip. My hypothesis is that they may be unsure whether the downloaded area covers their journey; I would validate that with observation before treating it as a proven problem.
Google Maps already supports downloading areas and driving offline. I would compare clearer pre-trip coverage confirmation with reminders to download maps. I would start with confirmation because it helps someone discover a missing area before departure. This is a proposed usability improvement, not a claim that offline navigation is a new feature.
Randomly assign eligible consenting travelers to existing preparation controls or the proposed confirmation flow, keeping assignment stable across repeat journeys. Test whether travelers can prepare a covered route without assistance; define the minimum meaningful improvement and sample requirements before reading results. Monitor download size, data use, battery impact and incorrect reassurance. Offline traffic and alternate routes are unavailable; the design must explain those limitations. If existing controls already solve the problem in testing, I would reconsider the proposal.
Pushback
Would you automatically download every possible detour?
No. That could consume storage without establishing value. I would let the traveler review the area and download size, explain what remains unavailable offline, and test a bounded opt-in suggestion against current controls.
Common mistake
Add offline maps so people do not get lost.
Why this answer is stronger
Offline maps already exist. The stronger answer states a testable usability hypothesis, compares interventions, and defines what could disprove the recommendation.
From a weak answer to a defensible one
Weak: Everyone needs meal planning, so I would add AI recipes.
Stronger: I would first test duplicate purchasing among coordinating households, then compare a shared list with item ownership before choosing a first release.
Prepare your own answer
Keep the chosen need fixed, invent two different mechanisms, and defend the smaller reversible test.
Close the guide and answer aloud. After reviewing, identify one missing decision and retry on a different problem.
Watch one interview
Mock Product Manager Interview: Improve WhatsApp (Google PM) ↗
Exponent · Mock interview · YouTube
Watch with a task: Notice how the candidate frames the improvement. Challenge one user assumption rather than copying the proposed feature.
Practice with a PMMockr worked answer
Open the practice problem and attempt it before comparing.
Compare after your attempt
Read the original worked answer, follow-up and feedback
Compare problem framing, assumptions, rejected options, evidence and response to pushback. Explain what evidence would settle a disagreement.
Further reading and perspectives
Official documentation explains product behavior; coaching and community accounts offer preparation perspectives. Interview examples do not confirm a company’s current hiring process.
- IGotAnOffer: Product sense interviews
Study problem framing and alternatives, then attempt a case before watching an answer.
Interview coach guidance · Public page - Strategyzer: Test the most critical hypotheses
Identify the weakest important assumption before paying to build a solution.
Primary framework · Public page - Reddit: PM interviewing mistakes
Use reported difficulties with goals, user types and concise answers as prompts for self-review.
Reddit · anecdotal discussion · Search excerpt reviewed; full thread unavailable - Jason Girouard: The PM Job Search, Practical Guide
Read one practitioner’s approach to preparation, reflection and answering before watching.
Medium · personal account · Public page
Turn the reading into practice
- Easy: outline your answer and explain every term you use.
- Medium: compare two options, defend one and name a downside.
- Hard: handle uncertainty, conflicting goals and a changed assumption.
Complete three questions at each level in your selected learning path where available. Review model solutions through the question’s solution action after meeting its access requirements.
Choose a learning path →Further reading
Continue with these related PMMockr articles. Examples in this guide are illustrative practice scenarios.