Name a product decision you think is bad. Now tell me why the team that made it might have been right.

What this question is really screening for

It looks like an invitation to be clever about a product and it is not. Almost everyone can produce a critique; the interviewer already knows the critique, and often knows the product better than you do. What is being graded is the second half — whether you can hold a design you dislike and a defensible reason for it in your head at the same time.

The reason that matters commercially is that most of your career will be spent inheriting decisions made by people who had information you do not. A product manager who reads every awkward design as incompetence rewrites things that were load-bearing, and does it repeatedly, because the mechanism that produced the design is still in place. The candidate who scores well treats a strange design as evidence of a constraint they have not yet found.

Critique the cost, not the taste

Start by making the criticism specific enough to be wrong. "The navigation is cluttered" is a preference. "A first-time user looking for their invoices has to open a menu whose top-level label is Business, then a submenu labelled Financials, and neither word appears anywhere in the email that sent them there" is a claim about a person in a moment, and it can be checked.

The useful discipline is to name the user, the moment, the goal and the specific cost, and then say what evidence would exist if you were right. If the labelling really is the problem, there will be support contacts asking where invoices are, a search box with invoice as a common query, and drop-off on that menu. If none of that exists, your critique is aesthetic and you should say so rather than defend it.

Version of the criticism	Why it scores differently
"The onboarding is too long"	Preference, unfalsifiable, no user named
"Six of the nine onboarding fields are not used until a second session, and completion drops sharply at the fifth"	A cost, a mechanism, and something checkable

Reconstruct the constraint

There are a small number of reasons a competent team ships something that looks wrong, and going through them out loud is the substance of the answer.

The business model is the most common. A confirmation step that seems redundant may exist because cancelling that action costs the company money, and the friction is the point. Free plans are frequently made slightly awkward on purpose. Advertising placements that damage the reading experience pay for the reading experience existing.

Organisational structure is the second. Two features that ought to share one interface but do not usually belong to two teams with separate roadmaps, and the seam in the product is a seam in the org chart. This is worth naming precisely because it tells you the fix is not a design change.

Regulation and legal exposure produce many of the strangest flows in finance, health and telecommunications, and they are invisible from outside. A consent screen nobody reads may be mandatory in wording as well as in presence.

Migration state accounts for much of the rest. What looks like an inconsistent design is often two designs, because the second one is 70 per cent rolled out and stalled behind a customer segment that cannot be moved. Very few products are ever in a finished state, and criticising a half-finished migration as a design decision is the most common way a candidate reveals inexperience.

Finally, the decision may have been correct on a metric you have not considered. A change that makes the product feel worse on first use may have moved retention at week four, and if the team measured that, they know something your five minutes of inspection cannot see.

Worked, on the redundant confirmation step

Take a design you frequently see criticised: a subscription cancellation flow with three screens, an offer, and a required reason. The critique writes itself — it is hostile, it damages trust, and the user has already decided.

The reconstruction is more interesting. Suppose 100 people a day begin cancelling, and the flow saves 12 of them because the offer addresses a genuine price objection. If the average remaining subscription value is £90, that is £1,080 a day of retained revenue from twelve people, some of whom were genuinely better off staying. Set against that a cost in goodwill that nobody has measured, spread across the 88 who cancelled anyway and resented the process. The team has one number and no measure of the other, and that asymmetry is why the flow exists and persists. Those figures are illustrative, but they show the shape of the argument, and the shape is the answer.

Now the proposal has to engage with that. "Remove the flow" loses the £1,080 and will be refused. "Show the offer once, on one screen, and make the reason optional" keeps most of the save rate, and can be tested against it directly. Add the missing measurement — repurchase rate among people who cancelled, and support contacts mentioning the cancellation experience — so the second number stops being invisible. That is a proposal a team can act on, and it is the same criticism you started with.

The critique that cannot survive the constraint

Where strong candidates lose this is the last step. They diagnose the constraint accurately, then propose a change that quietly assumes the constraint is gone. If you have just explained that the seam exists because two teams own the two halves, an answer that unifies the interface is not an answer; it is a request for a reorganisation, and you should say so plainly if that is what you mean. If you have just explained that the friction protects revenue, an answer that removes the friction has to say where the revenue comes from instead.

Say which category your proposal falls into. A design change you could ship in a sprint, a business-model change that needs an executive, or an organisational change that needs a director. All three are legitimate. Conflating them is what makes a critique sound naive, and it is the single thing an experienced interviewer is listening for behind the words.

The other half of the same failure is refusing to commit. A candidate who is so busy being charitable that they never say what they would change has answered only the second half of the question. Hold both: this is worse for this user for this reason, the team probably did it for that reason, here is the version that serves both, and here is how I would find out within a week whether I am wrong.

Any product you did not build contains constraints you cannot see. Name the one that best explains the design, then make sure your proposed change still works if that constraint is real.