Two days ago, Argentina beat Switzerland 3-1 in extra time at the 2026 World Cup. Leandro Paredes is Argentina's holding midfielder, the player responsible for organizing the team's shape in the middle of the pitch. Lionel Scaloni is Argentina's head coach. Mid-extra time, off the side of the pitch, the broadcast picked up a ten-line conversation between them about how Paredes should defend against a specific opposing striker. It's a better demonstration of good and bad discovery interviewing than most product management courses.
The conversation
Translated from Spanish. You can watch the moment here, via TN:
Paredes: "There's a striker next to me, their guy. When the center back steps out, I move to the right. But once I open up to the right, I lose control of how we build the play."
Scaloni: "Just leave the striker with the center back when you have the ball..."
Paredes: "He won't go where I am. He drifts to the other side. Like that other striker a while back, the bigger one, he stayed between the center backs."
Scaloni: "Do you need us to pull him higher?"
Paredes: "No. Have a center back mark him."
Scaloni: "Yeah, yeah. But what do you need? Another center back?"
Paredes: "A center back who stays one-on-one with him."
Scaloni: "Alright, we'll put in Ota. Done."
Scaloni starts by proposing solutions, not asking questions
His first three responses are all fixes: leave the striker with the center back, pull him higher, add another center back. He's guessing before he understands the problem. Paredes has to correct him three times before the real question comes.
This is the most common failure in a discovery interview. Hearing half the story and jumping to a fix feels like progress. Asking another question feels like stalling. It usually isn't.
The one question that works
"But what do you need?"
Not "what should we change." Not "which player." What do you need. It's the only question in the exchange aimed at the outcome instead of a specific fix, and it's the one that finally gets a precise answer.
Teresa Torres makes this distinction central to Continuous Discovery Habits: ask customers what to build, and you get a feature request filtered through whatever solutions they already know about. Ask about the outcome and a specific recent moment, and you get the actual opportunity underneath it.
Paredes answers with a story, not an opinion
He doesn't say "wide strikers give me trouble" as a general complaint. He points to one specific, recent instance: that other striker, a while back, who stayed central instead of following him. That specificity is what lets Scaloni see the actual mechanism, that particular matchup takes the middle of the pitch away from Paredes, rather than a vague dislike that's hard to act on.
People are unreliable narrators of their own general patterns. They're much more reliable when asked to recount one specific thing that actually happened. Ask "tell me about the last time," not "what do you usually do."
The request and the need were two different things
If Scaloni had gone with his own first guess, another center back, Argentina might have made a substitution that solved the wrong problem. Paredes wasn't asking for a body on the pitch. He was asking for control of the middle back. Once Scaloni understood that as the outcome, the actual fix (Otamendi, someone who could hold the striker one-on-one and free Paredes centrally) took five seconds to land on.
"I want another center back" was a solution in disguise. "I need someone to occupy their striker so I get the middle back" was the real opportunity, and it's the version of the ask that actually pointed to the right fix.
What this means for your next interview
Stop asking users what they want you to build. Ask what they need, and ask for the last specific time the current thing failed them. The feature request is usually a guess dressed up as an answer. The outcome, and the story behind it, is the actual brief.