product sense questions
We look at — did you validate your assumption or not? If someone is starting with their mind, 'this idea is this, I will do this and all this' — that's where they already fail.
Product sense is the interview round where most candidates self-destruct. Not because the questions are hard, but because candidates treat them as creative brainstorming exercises. They are not. They are structured thinking tests disguised as open-ended questions.
I have watched thousands of candidates attempt product sense questions. The ones who fail share a pattern: they hear “design an app for elderly users in India” and immediately start listing features. Voice commands. Big fonts. Regional languages. They sound creative. They sound knowledgeable. And the interviewer marks them a no-hire within ninety seconds.
The ones who pass do something different. They ask questions first. They define the user. They identify the core problem. Only then do they build.
What the interviewer is actually evaluating
Product sense questions — “design a product for X,” “how would you improve Y,” “what’s your favorite product” — test four things simultaneously:
| Skill | What it looks like | What kills you |
|---|---|---|
| User empathy | You identify a specific user segment and articulate their actual pain, not an assumed one | Designing for “everyone” or for yourself |
| Structured thinking | Your answer has a visible skeleton: user → problem → solutions → trade-offs | Jumping straight to features, or meandering without a framework |
| Creativity under constraints | You generate solutions that are non-obvious but feasible | Listing features from competitors, or proposing sci-fi solutions |
| Prioritization instinct | You pick one solution and justify why it wins over alternatives | Presenting five ideas without committing to one |
The interviewer does not care about your specific idea. They care about how you got there.
The framework: five steps, no acronym needed
PM interview, round 2. The interviewer leans back in their chair.
Interviewer: “Design an app for elderly users in India.”
The candidate pauses. Does not reach for a whiteboard.
Candidate: “Before I start — can I ask a few questions to make sure I'm solving the right problem?”
Interviewer: “Go ahead.”
Candidate: “When you say elderly, are we talking 60+ living independently, or 75+ who need caregiver support? And is this a consumer app they download themselves, or something a family member sets up for them?”
The interviewer nods. This is already better than 80% of answers they hear.
The first thing you say should be a question, not a feature.
Here is the structure that works. Not a branded acronym — just the sequence your brain should follow:
Step 1: Clarify the problem space (1-2 minutes). Ask questions. What type of user? What context? What platform? What business? Do not assume the interviewer wants what you think they want. If they say “design an app for elderly users,” ask which elderly users. A 62-year-old retired banker in Bangalore and a 78-year-old farmer in rural UP have nothing in common except age.
Step 2: Pick a user segment (30 seconds). State it explicitly. “I am going to focus on urban elderly, ages 65-75, who live with their adult children but spend most of the day alone. They own smartphones but use only WhatsApp and phone calls.” This is not a guess — it is a scoping decision. The interviewer wants to see that you can narrow, not that you can cover everything.
Step 3: Identify the core pain point (1-2 minutes). For your chosen segment, what is their biggest unmet need? Not a list of ten problems — one specific pain. “These users experience social isolation during the day. Their children are at work. They have limited mobility for in-person socializing. Existing social apps are designed for people who type fast and understand feeds.”
Step 4: Generate three solutions, then pick one (2-3 minutes). Sketch three approaches. They should be genuinely different — not “app with video calls” vs “app with better video calls.” Compare on feasibility, impact, and differentiation. Then commit. “I am going with option B because it has the highest impact for the lowest technical complexity, and nothing in the market does it well.”
Step 5: Go deep on your chosen solution (3-5 minutes). Now you can talk features — but tied to the user and problem. Walk through the core experience. Describe the first-time setup. Explain what success looks like. Mention one metric you would track to validate the idea. End with one risk and how you would mitigate it.
Total time: 8-12 minutes. That is exactly how long a product sense answer should run.
Worked example: “What’s your favorite product?”
This question is not about your taste. It is a product sense question in disguise. The interviewer wants to hear you analyze a product with the same rigor you would bring to building one.
The trap: picking something “impressive” like Notion or Figma and reciting their feature list. The better move: pick something you actually use obsessively, where you have genuine opinions about what works and what does not.
A strong answer structure:
“My favorite product is Dunzo. I’ll tell you why, and then what I’d change about it.”
What it does well: Dunzo solved hyperlocal delivery in Indian cities before anyone else took it seriously. The core insight was that people in Indian metros need someone to run errands — pick up groceries, deliver documents, get something from a specific store. Not a marketplace. A person who does the task. That positioning was precise.
The user insight underneath: In Indian households, especially dual-income families, the “errand runner” role used to fall on domestic help or the family member who worked closest to home. Dunzo digitized a real human behavior, not an imagined one.
What I would improve: The discovery experience is weak. Dunzo knows my order history — I order from the same three stores every week. But the app still shows me a generic home screen every time. I would build a “quick reorder” surface that predicts my next order based on frequency and day of week. The metric: reorder-to-delivery time drops from 4 minutes of browsing + ordering to 30 seconds of confirming a prediction.
One risk: Prediction accuracy. If the suggestions are wrong more than 30% of the time, users will stop trusting them and revert to manual search. I would start with only the top-10% most predictable users and expand from there.
Notice what happened: the answer demonstrated user empathy (understanding Indian household dynamics), structured thinking (what it does, what I would change, how I would measure), creativity (the predictive reorder surface), and prioritization (starting with high-confidence users). Four evaluation criteria, one answer.
Worked example: “How would you improve Instagram?”
This is the most common product sense question in India, and most candidates butcher it. They say “add dark mode” or “improve the algorithm” — both useless because they are not tied to a user or a problem.
Step 1 — Clarify: “Which part of Instagram? Content creation, discovery, messaging, monetization, or safety?” Suppose the interviewer says: “Up to you.”
Step 2 — Pick a segment: “I’ll focus on content creators in India with 10,000-100,000 followers. Not mega-influencers, not casual users. The mid-tier creator who is trying to make a living from content.”
Step 3 — Core pain: “These creators struggle with monetization. Instagram’s ad revenue share is tiny for mid-tier creators in India. Brand deals are inconsistent. There is no built-in way for a creator to sell a digital product — a course, a template, a paid community — directly through Instagram. They all use Linktree to redirect to external platforms, which means Instagram loses that transaction and the creator loses followers in the redirect.”
Step 4 — Three solutions:
- Native digital product storefront on creator profiles
- Subscription tiers (like Patreon) built into Instagram
- Tipping/gifting during Reels and Lives with better revenue share
“I am picking option 1 — the native storefront. Subscriptions work for a small number of creators. Tipping is low-ARPU. A storefront lets any mid-tier creator sell courses, presets, templates — the things they already sell through external links. Instagram takes a cut instead of losing the user to Gumroad.”
Step 5 — Go deep: Describe the storefront UI on the creator’s profile page. Explain the checkout flow (UPI-first for India). Define the success metric: percentage of mid-tier creators with at least one product listed within 6 months. The risk: quality control — Instagram becomes a marketplace of junk digital products. Mitigation: require creator verification and a minimum follower count to access the storefront feature.
Worked example: “Design for accessibility”
Accessibility questions test whether you understand users who are not like you. In India specifically, this has layers most candidates miss.
The trap is thinking “accessibility” means screen readers and WCAG compliance. Those matter. But in India, the real accessibility challenges are:
- Literacy gaps. 25% of India’s population cannot read Hindi, let alone English. Your app’s text-heavy UI is already inaccessible to 350 million people.
- Device constraints. The median Indian smartphone has 3GB RAM, a 5.5-inch screen, and intermittent 4G. “Just add voice input” fails when the phone cannot run a speech model and the network cannot stream to a server reliably.
- Situational disability. A farmer checking crop prices on a phone has dirt on their hands and sunlight washing out the screen. A construction worker checking pay stubs has the same problem. Their fingers are thick, the tap targets need to be large, and they cannot rely on reading small text outdoors.
- Cultural context. An elderly woman in a Tamil household may be fluent in Tamil but uncomfortable with a UI that is only in English or Hindi. Language is an accessibility barrier, not just a localization feature.
If you get an accessibility question, do not jump to WCAG guidelines. Start with: “Accessible for whom, in what context?” That question alone puts you ahead of most candidates.
The three fatal mistakes
1. Solving for yourself. “I would add a feature where you can…” — the interviewer stops listening. You are not the user. Even if you happen to be in the target segment, frame the answer around a defined user persona, not your personal preferences.
2. Listing features without a spine. “We could add voice search, and also a recommendation engine, and maybe gamification, and also social sharing.” This is a brainstorm, not an answer. A product sense answer has a single thesis — one user, one problem, one solution explored in depth.
3. Ignoring trade-offs. Every solution has a cost. If you propose a feature without mentioning what you would give up — engineering time, user complexity, business model implications — the interviewer knows you have never shipped anything. Real PMs live in trade-offs. Show that you do too.
What to do when you have never used the product
This happens. The interviewer asks you to improve Spotify and you use Gaana. Or they ask about Slack and your company uses Google Chat. Do not fake familiarity. Instead:
- Say it directly. “I don’t use Spotify regularly, so let me reason from first principles about what a music streaming service needs to do well.”
- Transfer your mental model. You use a competing product. The user needs are similar. “Based on my experience with music streaming apps, the core jobs are discovery, mood-based listening, and social sharing. Let me pick one.”
- Ask the interviewer. “Can you tell me about a specific user pain point you are seeing, so I can focus my answer?” Some interviewers will give you a hint. Most will respect that you asked rather than guessed.
What you must not do: pretend you know the product and get caught when the interviewer asks a follow-up about a feature that does not exist.
Set a timer for 10 minutes per question. Answer each one out loud, as if in an interview. Record yourself if possible — you will hear your own rambling.
- Design a financial planning app for gig workers in India. (Hint: gig workers have irregular income. That changes everything about how a finance app should work.)
- How would you improve Google Maps for Indian users? (Hint: do not say “better traffic.” Pick a specific user segment that Maps underserves.)
- What is your favorite product and how would you improve it? (Hint: pick something you use daily. Your genuine frustrations are better than rehearsed takes on products you barely touch.)
After each answer, check: Did I define a specific user? Did I identify one problem? Did I go deep on one solution instead of listing five? Did I mention a metric and a risk?
You are in a PM interview at a fintech company. The interviewer asks: 'How would you improve CRED?' You downloaded CRED once, paid one credit card bill, and deleted it. You barely remember the interface.
The interviewer is watching you. You have about three seconds before the silence gets awkward.
your path
A Zomato interviewer asks: 'How would you improve the restaurant discovery experience on Zomato for users in Tier 2 cities like Nagpur or Surat?'
The call: Do you first clarify the problem, or launch into solutions to show momentum?
A Zomato interviewer asks: 'How would you improve the restaurant discovery experience on Zomato for users in Tier 2 cities like Nagpur or Surat?'
The call: Do you first clarify the problem, or launch into solutions to show momentum?
Where to go next
- Understand all PM interview types: PM Interview Types
- Practice case study frameworks: Case Study Frameworks
- Build the product thinking muscle underneath: Product Thinking
- See what interviewers actually evaluate: What Interviewers Actually Evaluate