What people say, what they do, and what they need

The first mistake comes from treating three things as equivalent when they almost never coincide: what a person says they want, what they actually do in practice, and what they fundamentally need.

The gap between what people declare and what they later do is well documented in user research. People don't lie when they answer a survey or an interview. We are simply bad at predicting our own future behavior, we tend to give the answer we think is correct or socially desirable, and we later rationalize decisions made for reasons we don't even recognize. That's why asking directly "Would you use this?" or "Would you pay for that?" produces polite but unreliable answers.

Steve Portigal, in Interviewing Users (2013), insists that research is not about collecting opinions, but about understanding contexts and behaviors. When someone asks for a specific feature, that request is a data point, not an instruction. Our job is to ask what that person is trying to achieve when they ask for that, because the solution they propose is rarely the best answer to their own need.

The request is not the need

Here lies the heart of the misunderstanding. When a user says "I need a button to export to Excel," they mix into a single sentence a goal, a problem, and a solution they have imagined themselves. If we take the sentence literally and build the button, we may have solved what they asked for without touching what they needed.

Perhaps that person needed to share information with someone who doesn't have access to the system. Perhaps they wanted a report the product doesn't offer. Perhaps they didn't trust the tool's data and wanted to check it themselves. Each of those real needs would lead to a different and probably better solution than the button they asked for. The button was their hypothesis, not their need.

The jobs to be done framework, developed by Anthony Ulwick and popularized by Clayton Christensen, offers a useful way to look at this. The idea is that people "hire" a product to do a job in their lives. Christensen summarized it by saying nobody wants a drill, they want a hole, and actually not even the hole, but what the hole allows them to achieve. If we stay with the drill the user asks for, we optimize the wrong tool. If we understand the job they are trying to do, a range of solutions opens up that we couldn't see before.

Why we keep falling into it

If this mismatch is so well known, why do we keep tripping over it? There are several reasons, and none of them has to do with lack of talent.

The first is convenience. Interpreting what the user asks for literally is fast and avoids the uncomfortable work of researching for real. Taking the request as an instruction frees us from the responsibility of deciding, because we can always say we did what we were asked.

The second is confirmation bias. When we already have an idea of what we want to build, we listen selectively. We give weight to what confirms our hypothesis and dismiss what contradicts it. Research then becomes a search for justification rather than a search for truth.

The third is delivery pressure. Stopping to understand the real need seems like a luxury when there is a backlog to clear and dates to meet. Marty Cagan describes this clearly in Inspired (2017): many teams operate like factories that produce features without asking whether they solve a real problem, because the organization measures success by what it delivers rather than by the value it generates.

Don Norman, in The Design of Everyday Things (2013), adds an important dimension. Expert designers deliberately invest effort in determining the real problem before solving it, and they resist the temptation to accept the first statement they receive. That resistance is a competence that is trained, not an innate talent.

How to get closer to the real need

There is no infallible formula, but there are practices that significantly reduce the gap.

The first is to observe behavior instead of collecting opinions. Watching someone use a product, or reconstructing in detail how they solved a problem the last time they faced it, tells us much more than asking what they would do in the abstract. Concrete past behavior is a better predictor than an imagined future.

The second is to dig into the why before accepting the what. When a request arrives, the useful question is not "Shall we build it?" but "What were you trying to achieve when you thought of this?" Repeating that question with genuine curiosity usually reveals a need that the original request was hiding.

The third is to maintain regular contact with real users, not occasional contact. Teresa Torres, in Continuous Discovery Habits (2021), argues that product teams should hold frequent interviews, ideally weekly, so that understanding of needs does not depend on a large annual study that quickly becomes outdated. Continuous discovery keeps us from building for months on a frozen image of the user.

The fourth is to validate with committed behavior before building big. Cindy Alvarez, in Lean Customer Development (2017), reminds us that the best sign that a need is real is not that someone says they are interested, but that they do something that costs them: spend time, pay money, change how they work. Designing small experiments that ask for that kind of commitment yields far more reliable information than any statement.

The AI context: fast synthesis, fragile understanding

Artificial intelligence has transformed the most laborious part of this work, and that change deserves a nuanced look, because it has a bright side and a trap.

The bright side is real. Today a team can process hundreds of reviews, support tickets, and survey responses in minutes, and obtain a reasonable thematic grouping of what people are saying. That synthesis, which used to take days, frees up time for what really matters.

The trap is subtle. All of that capability operates on what people say, and we already know that what people say is not what people need. AI is extraordinary at summarizing statements, and precisely for that reason it can reinforce the old error of confusing the request with the need, now at a larger scale and with an appearance of rigor. A generated report that says "users are asking for X" sounds so authoritative that it invites building X without further thought.

There is an added risk. It has become fashionable to ask AI to generate "user personas" or to simulate how a customer would react. Those synthetic users can be a starting point for organizing ideas, but they remain a statistical guess about how someone might talk, not evidence of what a real person needs. Replacing conversations with flesh-and-blood users with a generated imitation means trading understanding for convenience. AI speeds up the collection of what is said, but it does not exempt us from the irreplaceable task of understanding what is needed, which still requires observing and talking with real people.

Discovering that what you thought the user wanted was something else is one of the most formative experiences in product work, and also one of the most humbling, because it usually arrives after we have already invested effort in the wrong solution. The good news is that this discovery, if it happens early and cheaply, is exactly what moves a good team forward.

The competence that separates someone who builds what they are asked for from someone who builds what is needed is not technical ability, but the willingness to doubt the first interpretation and go look for the real need where it lives: in people's behavior, not in their statements. At a time when technology makes it easier than ever to summarize what people say, cultivating that productive doubt becomes more valuable, not less.

What's your story? When did you discover that what you thought the user wanted was something else, and what signal did you miss along the way?

References

• Alvarez, C. (2017). Lean Customer Development: Building Products Your Customers Will Buy. O'Reilly Media.
• Cagan, M. (2017). Inspired: How to Create Tech Products Customers Love (2nd ed.). Wiley. I
• Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). Competing Against Luck: The Story of Innovation and Customer Choice. HarperBusiness.
• Norman, D. A. (2013). The Design of Everyday Things (revised and expanded ed.). Basic Books.
• Perri, M. (2018). Escaping the Build Trap: How Effective Product Management Creates Real Value. O'Reilly Media.
• Portigal, S. (2013). Interviewing Users: How to Uncover Compelling Insights. Rosenfeld Media.
• Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.
• Ulwick, A. W. (2016). Jobs to Be Done: Theory to Practice. IDEA BITE PRESS.