Spec met but user problem unsolved: facilitating the fix

WHAT THIS TESTS The interviewer is assessing emotional intelligence and systems thinking: can you distinguish building the thing right from building the right thing, and lead a conversation that fixes the outcome without making anyone defensive.

A GOOD ANSWER COVERS Start by genuinely validating that the team did their job: the feature meets every requirement in the ticket, so this is not about execution quality. Then locate the problem where it actually lives, in the requirements themselves, which are always an imperfect proxy for the underlying user need. Frame that proxy as something the whole team, product, design, and engineering, share ownership of, so no single party is at fault. Bring evidence rather than opinion: show the observed user behavior and a clear user-need statement that the current solution does not satisfy, letting the data carry the message. Then reframe the session as collaborative discovery, asking how can we close this gap together, and explicitly invite engineering's perspective on feasible options, since they often see the cheapest path. Aim to leave with a shared revised understanding of the need and next experiment, not a reprimand.

COMMON WRONG ANSWERS Implying engineers built the wrong thing or wasted effort. Presenting research as a final verdict that trumps their work. Leading with conclusions instead of evidence. Skipping acknowledgment of what went right, which puts the team on the defensive immediately.

LIKELY FOLLOW-UPS How do you prevent this gap next time, for example outcome-based tickets and shared exposure to research. How do you handle disagreement about whether the research is valid. How do you involve the product manager who wrote the ticket. How do you decide what to change versus accept.

ONE CONCRETE EXAMPLE A ticket asked for an export-to-CSV button, which engineers shipped perfectly. Research showed users actually needed scheduled recurring reports, not manual exports. In the meeting you credit the clean delivery, show the user-need statement and session clips, and frame it as our shared requirement missed the real need; you then invite engineering to scope a lightweight scheduling option together.