"What is your least favorite product and how would you fix it?"

Q: What is your least favorite product and how would you fix it?

The least-favorite product question is a product-improvement exercise in disguise. Here is the answer structure, a worked example, and the rubric signal.

The framing is a trap. “Least favorite” sounds like an invitation to vent, but the interviewer does not care about your taste. They are running the same product-improvement exercise they would run with any design prompt, and they chose adversarial framing deliberately to see whether you can maintain analytical distance from a product you dislike. The complaint is only the entry point. The fix is the entire answer.

What the rubric actually measures

Interviewers at Google, Meta, and Airbnb map this question to four competencies: problem space understanding, strategic insight, user empathy, and execution judgment. All four must appear. A candidate who names a product and then lists UX grievances is hitting zero of the four. A candidate who diagnoses why the product fails a specific user segment, names the structural cause, proposes a testable fix with a metric, and closes with the tradeoff is hitting all four.

The question also pairs naturally with the favorite product question. When interviewers ask both in sequence, they are checking whether your evaluative criteria are consistent. Use the same analytical frame in both directions.

How to pick a product

Three constraints matter.

First, do not pick the interviewing company’s own product. It puts the interviewer on the defensive and signals you have not done basic research into what they actually ship.

Second, do not pick a direct competitor to the company you are interviewing at. It reads as a provocation, not insight.

Third, avoid obviously failed products (Google+, Quibi). Choosing a dead product looks like you are avoiding intellectual risk. The strongest choice is a product that is genuinely successful by market metrics but has a clear, specific failure mode for a real user segment. That combination shows you can separate market success from product quality for a defined use case.

The four-move structure

1. Name the product, acknowledge its market success, and immediately narrow to a specific segment where it fails. Do not open with a complaint. Open with data: “X has [market metric]. But for [specific segment], it consistently fails at [specific moment in the journey].” This signals analytical distance from the first sentence.

2. Diagnose the root cause before prescribing anything. This is the most common failure mode: candidates skip diagnosis and go straight to a feature request. The diagnosis tells the interviewer whether you understand why the product is the way it is, which is different from knowing that you dislike it. The strongest diagnosis is structural: an incentive misalignment, a business model conflict, or a data feedback loop that optimizes for the wrong signal.

3. Propose one concrete fix with a testable hypothesis and a leading metric. Not a feature list. One change, one behavior it would shift, one metric to watch. The fix should be narrow enough to run as an experiment.

4. Close with the tradeoff and the business case. Name the downside, say how you would mitigate it, and say why the fix is worth the cost. A fix without a tradeoff signals you have not thought about why the product does not already have this feature.

The full answer runs 4-6 minutes in a live interview. It is a mini product-design exercise, not a quick two-liner.

strong

"LinkedIn job alerts. It is dominant in professional hiring: over a billion members, recruiter subscriptions are LinkedIn's largest revenue line. But for senior PMs actively searching, the signal-to-noise ratio makes the alerts nearly unusable. I get 40 alerts a day and maybe three are genuinely relevant. The root cause is not a UX decision. The relevance algorithm optimizes for click volume, because that is what justifies the recruiter subscription price. High click volume looks like engagement, but it does not correlate with hire quality. The fix I would test: introduce a match quality signal derived from message reply rates after application, not click-through. Candidates who get recruiter replies are clearly better matches than candidates who click and never hear back. The leading indicator would be recruiter reply rate per alert click; I would expect to see movement within two job-search cycles. The tradeoff is that fewer total alerts means fewer total clicks in the short term, which creates pressure on a metric tied to recruiter pricing. The business case is recruiter retention: when hires are slow, recruiters churn. Better match quality reduces churn, which is worth more than raw click volume."

weak

"I really don't like LinkedIn because the UI is so cluttered and confusing. I'd add better filters so you could narrow down the results." No user segment named. No causal diagnosis. No business context. No tradeoff. The interviewer hears: this candidate cannot separate their personal reaction from a structured analysis. "Better filters" is a feature request any engineer could write on a sticky note. The PM is supposed to explain why this one, why now, and what gets sacrificed to get it.

The 2026 reframe

In 2026, “how would you fix it” cannot mean “add a feature” or “clean up the UX.” Feasibility is nearly free. Any LLM wrapper can replicate a surface-level UX improvement overnight. The bar is viability and lovability.

Your fix needs to answer two questions: is there a user who would change behavior or pay for this? And does the experience become genuinely more lovable, meaning it meets users where they are and anticipates what they need, rather than just removing an annoyance?

The strongest 2026 answers name a structural change: an incentive, a business model, a data feedback loop that compounds over time. The LinkedIn example works because match quality scoring is a feedback loop. It gets better as more data accumulates, and it addresses a real business problem (recruiter churn) rather than just a UX problem (too many notifications).

If you propose an AI-assisted fix, address the lovability question directly. AI assistance that is interruptive, wrong at the wrong moment, or intrusive makes the product worse, not better. The question is whether the product meets users where they already are. See lovable, not just usable and feasibility is free for how to frame this in the interview room.

The three fastest ways to fail

Vague UX complaints: “the interface is confusing” is a preference, not a product critique. Name the exact moment the product fails a specific user doing a specific task.
Feature requests with no tradeoff: every engineer can think of features. Name the reason the feature does not already exist and what you would sacrifice to build it.
Metric-free proposals: if you cannot name a leading indicator and a behavior you expect to shift, the fix is not testable. Untestable fixes are not PM thinking.