Product Manager interview prep

Keep it to 90 seconds and make it a product story, not a CV recital.

Three beats: what you have built or decided so far (one example with a metric), why product is the job you want, and why this company’s product is the next problem you want to work on.

End with one specific observation about their product that you noticed as a user.

Name the moment you found yourself doing PM work already: deciding what to build, talking to users, settling a trade-off between engineering and the business.

Then explain what you liked about it and what you are giving up (deep engineering, client work, analysis) with open eyes.

Close with what you will bring that most PMs lack: your engineering, data, design or domain background.

Use STAR, but spend most of the time on the decision. Situation: what you were building and the bet behind it. Then the signal that the bet was wrong: data, user interviews, a competitor move.

Explain how you decided to change course, who you had to convince, and what you stopped doing. Pivots are about cutting, so name the cut.

Finish with the result and what you would spot earlier next time.

This maps to Amazon’s “Dive Deep” principle, so pick a story where the surface answer was wrong.

Example shape: a metric looked healthy, you pulled the raw data or read support tickets, and found a segment hidden by the average. Say what you looked at, in what order, and what you found.

End with the decision it changed and the number that moved.

Pick a story with at least two stakeholders who wanted different things, such as sales wanting a custom feature and engineering wanting to pay down tech debt.

Show how you made the trade-off explicit: the cost of each option, the metric you used to decide, and who agreed to what. Say who was unhappy and how you handled it.

The result should include how the relationship held up, not just what shipped.

Choose a decision with real stakes and incomplete data: killing a feature, delaying a launch, saying no to a large customer.

Walk through the options, what you knew and did not know, and why you decided when you did instead of waiting for more data. Amazon calls this a two-way versus one-way door: say which it was.

Close with what happened and whether you would decide the same way again.

Clarify the goal first: health outcomes, engagement or revenue? Assume it is helping seniors stay active safely.

Segment: seniors living alone, seniors with a chronic condition, seniors whose children manage their health from another city. Pick one, say the third, because they have both a strong need and a paying family member.

Pain points: no one notices when activity drops, exercise feels unsafe, and apps are too fiddly. Solution: a simple daily walk goal on a basic phone or watch, with a weekly summary sent to the family and an alert when activity falls for three days. Metric: weekly active seniors meeting their goal; guardrail: falls or injuries reported.

Start with what Calendar is for and who uses it: people booking meetings with others. Pick a segment, for example managers with back-to-back meetings.

Their pains: no time to prepare, meetings that run over, and no focus time left. Rank them by frequency and pain; “no focus time” hurts most because it affects every day.

Improvement: suggest moving low-priority meetings to protect two focus blocks a week, with one tap to accept. Measure the share of users who keep focus blocks for four weeks, with a guardrail on meetings declined by others.

Define the creator: small creators (under 10,000 followers) trying to grow, or established ones trying to earn. Pick small creators; there are more of them and their retention drives content supply.

Their pains: not knowing what works, low reach, and time spent editing. The biggest is not knowing what works, because it makes them post less.

Solution: a weekly “what worked” card comparing their Stories on replies and completion rate, with one suggestion. Metric: stories posted per active small creator per week; guardrail: viewer time spent in Stories.

Clarify why: group buying lowers price per unit and brings new users through friends. Assume the goal is new buyers in tier-2 and tier-3 cities.

User: a price-sensitive shopper who already buys with friends or family. Flow: start a group for a deal, share it on WhatsApp, the price drops when 3 people join within 24 hours, and everyone pays separately.

Risks: groups that never fill and sellers who cannot handle the discount. MVP: 50 products in 2 categories with a guaranteed fallback price. Metrics: new buyers acquired through groups and their 60-day repeat rate.

Find where repeat orders are lost. Split users into one-time, occasional and habitual; the biggest lever is usually turning a second order into a third.

Pains for occasional users: deciding what to eat takes too long, and the last order’s restaurant may be closed. Ideas: a “reorder” row on the home screen with one-tap checkout, and smart substitutes when a favourite is closed.

Test the reorder row first because it is cheapest. Metric: share of users placing a second order within 14 days; guardrail: average order value.

Ask which users and which categories. Meesho shoppers are often first-time online buyers on low-cost phones, browsing fashion with thousands of results.

Pains: too many results, filters hidden behind a menu, and filter names in English jargon. The biggest: shoppers do not find filters at all.

Ideas: show 3 visual filter chips (price band, size, “COD available”) above results, and remember the size the user picked last time. Metric: search-to-order conversion; guardrail: search latency on low-end phones.

Users: drivers going somewhere they have not been, commuters, and parking operators. Pick first-time visitors to busy city areas.

Pains: not knowing if parking exists near the destination, circling for spots, and forgetting where they parked. Circling hurts most: it wastes time and makes people late.

Solution: before the trip starts, show the likely parking difficulty and the nearest paid lot, and route to the lot, not the door. Metric: share of trips that end at a suggested lot; guardrail: total trip time.

Clarify first: which metric (daily active users or documents created), over what period, and was the drop sudden or gradual?

Then go in order. Is the data right (a tracking change)? Did we ship something (a release, a login change)? Is it external (a holiday, a competitor, an outage)? Then segment by platform, country, user type and entry point until the drop concentrates somewhere.

State your most likely cause, how you would confirm it, and what you would do next.

“Suddenly” points to a change. Check the timing against releases, server incidents and policy or pricing changes.

Read the reviews themselves: group them by theme (crash, login, price, ads) and by app version, device and country. If one version or one device family dominates, it is likely a bug.

Confirm with crash rates and support tickets for the same window. Then fix or roll back, reply to reviews, and add an alert on review rating by version.

Start with why Netflix would do this: more time with Netflix and lower churn, not podcast ad revenue.

North star: weekly podcast listening hours per subscriber, because it captures both reach and depth. Inputs: share of subscribers who try a podcast, listening hours per listener, and week-4 return rate.

Guardrails: video watch time should not fall, and churn among listeners should be lower than among similar non-listeners. Say what result at month 6 would make you keep investing.

Reels has viewers, creators and advertisers. Success means viewers find it worth their time, creators keep posting and it adds to Instagram overall.

Viewers: daily Reels viewers and time spent per viewer. Creators: share of creators posting weekly. Business: ad impressions in Reels. Pick one north star, say daily Reels viewers who watch at least 5 minutes.

Guardrails: total Instagram time (Reels should not just steal from the feed) and reported or hidden content rate.

Break returns down: by category, by reason code (size, quality, “did not like”, wrong item), by seller and by buyer segment. Fashion size issues usually dominate.

Then tie each reason to a cause in the flow: missing size charts, photos that do not match, or sellers shipping wrong items.

Prioritise by returns removed per unit of effort: size guidance on top fashion listings first, seller penalties for wrong items second, photo checks third. Track return rate by category and guard against a fall in conversion.

State your structure before any numbers: households × share owning a car × cars per owning household, plus commercial cars (taxis, company fleets).

Use round assumptions and say they are assumptions: for example 2 crore people, 4.5 people per household (about 45 lakh households), 30% owning a car, 1.3 cars each, which gives about 17–18 lakh private cars. Add a share for taxis and fleets.

Sense-check against something you know, such as traffic or parking, and say which assumption you are least sure of.

Do not answer yes or no straight away. Ask what Flipkart wants: rural users, a new revenue line or a logistics edge.

Then test three things: is the market large and underserved, does Flipkart have a right to win (payments, logistics, trust), and what is hard (live animals, health checks, regulation, delivery)?

Give a recommendation with a smaller first step, for example a listings marketplace with verified sellers and payments, no delivery, in two states, and the metric that would justify going further.

Start with Google’s goal and what it already has: YouTube is already a huge video platform, so the real question is whether a separate paid OTT adds anything.

Check the market (crowded, content is expensive), Google’s edge (distribution on Android TV and Chromecast, ads, payments) and the cost (content rights).

A reasonable answer: do not build a new OTT; grow YouTube’s paid tiers and channel subscriptions instead. Say what would change your mind.

Clarify the store’s strengths: fresh produce, trust, a nearby location. The goal is to keep regular shoppers, not to beat delivery apps on speed.

Segment: regulars who still visit but now order staples online. Their pain: carrying heavy items and not knowing what is in stock.

Product: order staples for same-day pickup or local delivery while browsing fresh items in store, with a weekly list saved. Metric: retained regular shoppers and basket size; guardrail: in-store margin.

Set the goal and the success metric first: share of small businesses that reply to a customer within an hour, for example.

Plan the launch in stages: internal test, a small beta with 100 businesses, then a percentage rollout by country. List what must be ready at each stage: help content, support training, abuse controls.

Name the risks (spam, slow replies hurting customers) with a guardrail and a rollback rule for each. Close with how you would decide to go from beta to full launch.

Tie every request to the quarter’s goal first; anything that does not move it goes to the bottom, however loud the requester.

Score the rest on impact (users affected × size of the effect), confidence (how sure you are) and effort (engineering weeks), and show the scores so others can challenge them.

Then check dependencies and risk, pick 3, and tell the owners of the other 7 why, and when you will look again.

Treat it like a short consulting deck: the question, the answer on slide one, then the evidence.

Cover market size and growth (with sources), who already serves it, Ekart’s advantages (network, volume, tech) and gaps (pickup from individuals, pricing for one-off parcels), and the economics of a parcel.

Recommend a first step, such as B2B courier for small online sellers in 10 cities, with the metrics and milestones that decide the next step. Keep it to the page limit.

Keep it high level and talk through the flow. Clients send a message to an API server, which stores it and pushes it to the recipient through a persistent connection; if they are offline, a push notification goes out and the message waits.

Name the key choices: how messages are stored and ordered, how delivery and read receipts work, and how group chats fan out.

Then talk trade-offs a PM cares about: latency, cost at scale, end-to-end encryption versus server-side features like search.

Pick a real trade-off: build versus buy, a quick fix versus a rebuild, or accuracy versus speed.

Explain the options in plain words, what engineering recommended, and the product factors you added: user impact, time to market, cost of being wrong.

Say what you decided, how you made it reversible if possible, and what happened.

Spend the first minutes on the spec, not the tool: the user, the job to be done, the one flow you will build, and what “done” looks like.

Then prompt an AI builder (Claude, Cursor, Lovable or v0) one screen at a time, test each step, and fix what breaks. Narrate your choices so the interviewer sees your judgement.

At the end, show the prototype, list what you cut, and say how you would test it with five users.

Start with the problem, not the model: for example, sellers writing poor product titles that hurt search.

Propose the simplest AI that solves it: generate a title and attributes from the seller’s photo, which the seller approves. Explain the inputs, the output and where a human checks it.

Define evaluation before launch: a set of 200 listings rated for accuracy, a target error rate, and the cost per listing. Then the business metric: search clicks on listings that used the suggestion.

Some APM loops include a light coding question. Clarify: combinations of what size? If it is all subsets, the answer is 2 to the power N; if it is choosing k of N, it is N! / (k! (N−k)!).

Write a short function, compute it iteratively to avoid huge factorials, and test it on small cases you can check by hand (N = 3, k = 2 gives 3).

If you are rusty, say so and reason clearly; interviewers care about how you think through the problem.