Product Manager Interview Questions India 2026: Product Sense, Metrics, Case Studies, and Execution

Product sense questions for PM interviews:

1. 'Design a new feature for Swiggy to increase repeat orders.' Framework: understand the user first. Frequent Swiggy users: working professionals (25-40), students, time-pressed parents. Pain points causing missed repeat orders: decision fatigue (too many choices), forgetting (no reminder), cost concerns (delivery fee adds up). Feature ideas: 'My Usual' one-tap reorder of 3 saved meals on the home screen; 'Weekly Meal Plan' showing Mon-Fri lunch slots with personalised suggestions based on past orders; a loyalty nudge ('Order today, your 5th order this week is delivery-fee-free'). Prioritise: 'My Usual' has highest reach (existing heavy users), lowest effort (surface existing data), highest confidence (users reorder the same meals >60% of the time according to Swiggy's published data). Define success: orders per active user per week (primary metric), time-to-first-order-placed per session (leading indicator), delivery fee revenue (guardrail: should not drop).

2. 'How would you improve Google Maps for Indian users?' User insight: Indian roads have conditions not in the map (potholes, seasonal flooding, unofficial shortcut roads used locally). Pain points: inaccurate ETAs on congested Indian roads, no offline-first mode for tier-2 cities with 3G connectivity, limited Hindi/regional language voice navigation. Improvements: crowdsourced road condition reporting (tap 'rough road' while navigating; aggregate to dynamically re-weight routes); offline-first map caching over WiFi with auto-update; voice navigation in 12 Indian languages with casual phrasing ('Agle signal ke baad left lo' instead of 'Turn left at the intersection').

3. 'What is your favourite product and what would you improve?' Choose something you genuinely use daily. Structure: (1) What it does and who uses it. (2) The core user journey and where the friction is. (3) One specific improvement with a clear hypothesis. (4) How you would measure success. Avoid generic answers ('I would make it more intuitive'). Be specific ('The Duolingo streak mechanic causes anxiety rather than motivation for advanced learners; I would replace it with a weekly practice goal they set themselves, reducing streak-related churn by approximately 15%').

Metrics interview questions for product managers:

1. 'You are PM for Razorpay checkout. Define your north star metric.' North star: payment success rate (the percentage of initiated payment attempts that result in a successful transaction; directly measures the core value Razorpay delivers to merchants and their customers). Supporting metrics: checkout funnel abandonment rate by step (where do users drop off?), payment success rate by method (UPI vs card vs netbanking: which has the lowest success rate?), time-to-payment-confirmation latency (>5 seconds on payment confirmation significantly increases user abandonment), merchant time-to-go-live (how quickly can a new merchant complete integration and accept their first live payment?).

2. 'Prioritise this feature backlog of 20 items.' RICE framework: Reach (how many users in the next quarter?), Impact (how much does it move the north star metric per user, on a 1-3 scale?), Confidence (how confident are you in the estimates, as a percentage?), Effort (person-weeks). RICE score = (Reach x Impact x Confidence) / Effort. MoSCoW (for release planning): Must have (blocks launch without it), Should have (important but not blocking), Could have (nice to have), Won't have (not this release). Always anchor prioritisation to a strategic goal: 'This quarter's goal is to increase payment success rate from 95% to 97%; all features are prioritised by their estimated contribution to that metric.'

3. 'How would you investigate a 20% drop in Swiggy's DAU?' Is it all users or a cohort? (New vs returning? iOS vs Android? Metro vs tier-2?). Is it a tracking issue? (Check event ingestion in your analytics platform before assuming a product issue.) Is it correlated with a product event? (Release, A/B test, feature rollout?) Marketing event? (Spend cut, campaign end?) External event? (Holi, IPL, competitor promotion, bad weather in Mumbai and Bangalore?) After isolating the segment: form hypotheses, rank by likelihood, test each with data, communicate findings with proposed next actions.

Execution interview questions for product managers:

1. 'How do you work with engineering when there is a disagreement on scope?' Frame it as data, not opinion. Bring the user research, the metric impact estimate, and the business priority. Ask engineering for the effort estimate for the full scope vs a reduced scope. Present the trade-off to leadership: 'Option A delivers 80% of the user value in 2 weeks; Option B delivers 100% in 6 weeks. Given our launch deadline, I recommend Option A with Option B as a fast-follow.' Document the agreed scope in a written PRD so there are no surprises at launch.

2. 'How do you write a good Product Requirements Document (PRD)?' A PRD communicates the what and why, not the how (implementation is engineering's decision). Sections: Problem statement (what user problem are we solving and for whom?), Goals and success metrics (what does success look like in 30/60/90 days?), User stories (as a [user type] I want to [action] so that [goal]), Out of scope (what we are explicitly not building in this version), Open questions (decisions still needed), Appendix (research, data, designs). Length: 1-3 pages for a feature; a longer PRD is a sign the problem is not well-understood yet.

3. 'How do you handle a feature that underperforms after launch?' First: is underperformance real or measurement error? (Confirm tracking is correct.) Segment: which user cohort, geography, or device shows the worst performance? Run a retrospective with the team: was the hypothesis wrong, was the execution poor, or was the feature launched to the wrong audience? Decide: iterate (small changes to improve the metric), pivot (change the approach), or kill (stop investing if the core hypothesis is wrong). Communicate the decision with data and the reasoning to the team.