The Product Sense Interview: A Worked Answer to 'Improve a Product You Use'

"Pick a product you use and tell us how you'd improve it."

It sounds like the friendliest question in the loop. It is the one that eliminates the most people, and usually within the first ninety seconds — before the candidate has said anything an interviewer could disagree with.

The reason is structural. The prompt is enormous and the answer is scored on narrowing. A candidate who starts listing improvements has already failed, not because the improvements are bad but because choosing between them was the entire exercise.

What is actually being tested

Not creativity. Interviewers are not hoping to be surprised by a feature idea, and they have heard every idea before.

Product sense is being able to say who has what problem, how you'd know, and why this problem rather than the others. The feature at the end is almost incidental — it's evidence that the reasoning produced something concrete, nothing more.

Which means the answer has a shape, and the shape is not "here are three ideas":

Five minutes. Everything else is follow-up conversation, which is where the round is actually won.

The worked answer

The product below is deliberately ordinary — a supermarket's grocery delivery app. Ordinary is the right choice: an obscure product forces you to spend two minutes explaining what it is, and a glamorous one invites the interviewer to know more about it than you do.

"I'll take the grocery delivery app I use weekly. I'm picking it because I use it under real constraints — I'm ordering while doing something else, and I've abandoned it mid-basket more than once, so I have first-hand friction rather than theories.

Before improving anything: whose goal am I serving? I'll assume the company's goal is order frequency rather than basket size, because frequency is what makes delivery economics work and it's the harder of the two. If that's wrong, tell me and I'll change tack.

Now the narrowing. The app serves at least three groups: the big weekly-shop household, the top-up shopper buying six things, and the first-time user. I'll take the weekly-shop household, because they're the ones whose habit drives frequency, and because their job is the most repetitive — and repetitive jobs are where a product can earn a lot by removing small costs.

Their job isn't 'buy groceries'. It's 'reproduce roughly last week's shop, minus what we still have, plus the two things we've run out of.' That's a job of editing, not browsing. And almost everything in the interface is built for browsing.

Concretely, where it breaks: the repeat-order flow gives me last week's basket as a list of forty items with no memory of which ones I always remove. I delete the same four things every week — the ones that come in packs too big for us. The app has watched me do that forty times and has learned nothing from it.

So the improvement: when a repeat basket is loaded, items I've removed on three consecutive occasions come in pre-deselected, shown greyed with a one-tap restore. Not removed — deselected and visible, because silently dropping something from a grocery order is a much worse failure than leaving it in.

The cost, and it's real: I'm adding a state to every line item, which makes the basket busier at exactly the moment the user wants it simple. And there's a trust risk — if we get the prediction wrong we've made someone's dinner not arrive. That's why it's deselected rather than deleted, and why I'd want the threshold conservative. Three consecutive removals, not two.

How I'd know it worked: time from opening a repeat order to checkout, for returning weekly-shop users. Not basket size — I'd expect basket size to fall slightly, and I'd accept that, because the items being removed are ones they didn't want. The guardrail is post-delivery complaints about missing items, which is where this breaks if it breaks."

That's about four minutes spoken. It ends on a metric and a guardrail, which is what invites the next question rather than closing the topic.

The three follow-ups, and what they're checking

The prepared part of the answer is over in four minutes. What follows is the real round.

"Why that user and not the top-up shopper?" — checking whether your choice was reasoned or arbitrary. The strong answer names what you'd give up: "The top-up shopper has a more painful job — they want six items fast and the app is built for forty. It's probably the bigger UX win. I chose the weekly household because the goal I assumed was frequency, and they're the habit. If the goal were new-user activation, I'd have picked differently." You've now shown the choice was tied to the goal, which is the thing being tested.

"What if the data shows people remove different items every week?" — checking whether you'd notice your idea was dead. Answer honestly: "Then the feature doesn't work and I'd want to know that before building it. It's cheap to check — look at whether removal patterns repeat per household. If they don't, the real job isn't editing and my whole framing was wrong, not just the feature."

"How would you convince an engineer this is worth doing over the checkout bug they want to fix?" — checking whether you can hold a position without being rigid. The bad answer argues. The good one concedes: "I probably wouldn't. A checkout bug is revenue leaking now and this is a habit improvement. I'd want it in the next cycle, not this one — and I'd want to know how often the bug fires, because if it's rare my ordering changes."

Where these answers usually go wrong

A third failure is subtler and very common among strong candidates: proposing something with no cost. If your idea has no trade-off, you either haven't found it or you've picked something too small to matter. Interviewers read a cost-free proposal as inexperience, because everything real costs something — complexity, a slower screen, an edge case, someone's trust.

Preparing without a partner

You don't need a study group for this one. You need three products you use often enough to have noticed something about, and a timer.

For each, write one sentence: the user I'd pick, and what their job actually is, stated as a verb that isn't the obvious one. Editing rather than buying. Reassuring rather than tracking. Deciding rather than browsing. That single sentence is 70% of the answer and it's the part you can prepare in advance without sounding rehearsed, because it's a framing, not a script.

Then answer out loud, timed to five minutes, and stop at the metric. If you're still describing the problem at minute three, the narrowing didn't happen.

For the rest of the PM loop — the behavioural round, the metrics questions, the prioritisation case — the question list is here: Product Manager Interview Questions. And if you find yourself reaching for CIRCLES to structure this, read which frameworks to use and when to drop them first — naming the framework out loud is the fastest way to make a good answer sound procedural.