ARTICLE · Research

The customer asks for a button: nine different things reports call a need

Boris Kaptelov · 02.08.2026 · 9 min

"We need a reorder button." The phrase lands in the report under "customer needs," moves from there to the backlog, and from the backlog into a sprint. A quarter later the button exists — and repeat orders have not grown.

There is nothing to analyze here: what made it into the report was not a need. It was a solution the customer invented on their own, based on what they had seen in other products. The actual need may have been to cut the time and the risk of error in a recurring purchase, and the button is just one way to do that — not necessarily the best one.

In research reports, the word "need" covers at least nine different things. They call for different actions, and confusing them costs more than it seems.

A goal and a task are not the same thing

The international ergonomics standard ISO 9241-11 separates them cleanly: a goal is the intended outcome; a task is the set of activities undertaken to achieve it. The goal does not depend on the means. The task describes a specific way.

A person can keep the goal and change tasks. The goal of "having a clean shirt by morning" can be met by washing at home, by a laundry service, or by buying a new shirt. If you wrote "laundry" into the needs list, you have already chosen the means on the customer's behalf — and missed who you are actually competing with.

Hence a practical test for any line in a report: can the same outcome be achieved in a fundamentally different way? If yes, you are looking at a task or a solution, not a goal.

A problem is not a need, and a barrier even less so

A problem is a perceived gap between the current state and the desired one. It is related to a need but does not coincide with it.

A need can exist without any dissatisfaction at all, as long as the current solution is considered good enough. And the reverse: a problem can arise from the failure of a specific solution without pointing to a distinct, stable need. A customer cursing a supplier's interface does not necessarily need a new product — perhaps they need the old one to work.

A barrier is a separate category. It is whatever makes reaching the goal harder: lack of information, skill, time, money, access, trust, or authority. A barrier is not a need in itself. Removing a barrier has value only relative to a specific goal. Clearing an obstacle from a path the customer never intended to take is not an improvement.

Next to the barrier stands the constraint, and they are not the same thing. A barrier makes things harder; a constraint sets the boundary of acceptable means. For an individual buyer that means budget, physical ability, space, compatibility with what they already own. In corporate purchasing it means regulation, security requirements, integration architecture, procurement procedures, contract terms, and the distribution of authority. A barrier can be removed with an argument or a product tweak. A constraint cannot be removed — you have to fit within it.

The word "pain" stands apart here. It is a handy metaphor and a useless analytical category: it is applied to negative emotion, monetary cost, lost time, risk, inconvenience, and process failure alike. These phenomena have different mechanisms and different costs of solving. Piling them into one list just because the customer spoke about them with irritation is a way to lose exactly the distinctions the research was done for.

A risk is not a problem that has not happened yet

This is a distinction reports miss with remarkable regularity.

A problem is damage that has already occurred. A risk is uncertainty about future consequences. The need may consist not in fixing current damage but in reducing the probability or severity of a future event.

The practical consequence is direct. The absence of frequent negative episodes does not mean that redundancy, quality control, insurance, or information security are unnecessary. If the researcher hunts only for pain points, the entire category of risk-related value disappears from the report — and with it the products that are sold precisely on that value.

A workaround proves less than people tend to think

A finding researchers usually celebrate: the customer has built a workaround. Exports everything to a spreadsheet, keeps a parallel ledger, employs a person who reconciles the numbers by hand.

The theory of workarounds describes this as an adaptation that emerges from the collision of a goal, an obstacle, available resources, and the consequences of following the rules. The existence of a workaround is evidence that the outcome has some value to the participant and that they are willing to invest effort in it.

It does not prove willingness to buy. The workaround may be rare. It may be cheap. It may yield side benefits your product lacks: flexibility, control, transparency, independence from someone else's system. It may be socially acceptable and cause no one any trouble.

So five things need to be kept apart: the barrier itself, the current practice, the cost of the workaround, the result it delivers, and the reasons the current way of doing things persists. The last is investigated least often — and is worth more than all the rest.

Frequency of mention does not equal importance

Griffin and Hauser's study of the voice of the customer separates three distinct analytical tasks: identifying needs, structuring them, and prioritizing them. And it shows, separately, that frequency of mention does not equal importance.

This directly contradicts how reports get read. A theme that came up in twelve interviews out of twenty goes to the top of the list. A theme voiced twice sinks to the bottom or drops out entirely.

Yet what gets mentioned often is what is easy to put into words and what was recently irritating. What gets mentioned rarely is what has become habitual, what is awkward to admit, and what a person does not regard as their own problem. Prioritization is a separate piece of work, not a by-product of counting. How to take a report all the way to priorities and decisions is something we cover separately.

The Kano model adds a second correction: the link between implementing an attribute and satisfaction is nonlinear. Must-be attributes cause dissatisfaction when absent but do not necessarily raise satisfaction when present. Attractive attributes work the other way around. The same increment of effort spent on different attributes yields different results, and no frequency-sorted list will show it.

"Latent need" means five different things

The term is used so loosely that it has stopped meaning anything. It is taken to cover:

a need the person is aware of but did not voice; an experience that is hard to put into words; a baseline expectation taken for granted; a future need that has not yet become widespread; a researcher's interpretation that the participant themselves does not use.

These are five different cases, and each demands its own kind of evidence. The first is resolved with a follow-up question. The second — by observation, not conversation. The third reveals itself only when it is violated. The fourth is found through those who ran into the new conditions ahead of the market. The fifth is not found in the data at all — it is constructed by the researcher and must be labeled as a construction.

"Unarticulated" and "emerging" needs deserve separating as well. Lead users, who encounter future conditions before everyone else, may be perfectly aware of their need and able to articulate it. There just are not many of them yet.

Value does not live in a product attribute

"Automatic cleaning" is not a value. The means–end chain links a product attribute to the consequences of use and, further on, to what matters to the person in the first place: automatic cleaning reduces effort, lowers risk, frees up time.

You have to work with the research at all three levels at once. The attribute tells the engineer what to build. The consequence tells you what to say in your communication. The top level explains why the customer will listen to you at all.

A report stuck at the attribute level turns into a wish list. A report stuck at the top level turns into an essay on values from which nothing can be built.

What to do about this in a report

One discipline closes most of the problem: every line in the "needs" section must carry a label saying what it actually is.

Goal. Task. Problem. Barrier. Constraint. Risk. Workaround. Preference. Requested solution.

Preference deserves its own note, because it is especially easy to mistake for a need. A preference is a comparative judgment of alternatives, and it depends on which set of options the person saw, how the choice was framed, what it cost, and what constraints they were under. A person can prefer your product on a specific parameter and still not buy it — because of price, switching risk, or incompatibility. A preference is not a basic need and does not guarantee a choice.

The requested solution, meanwhile, is not garbage. It shows what categories the customer thinks in, what they consider an acceptable course of action, and what they compare you against. Its status is simply that of evidence about the customer's experience — not proof that the feature is needed.

And one last thing worth remembering when reading any report of this kind. An interview yields statements, accounts of events, explanations, and descriptions of practice. Need, motive, and value are not what was said. They are constructions the researcher built out of what was said. A good report lets you see exactly what each one is built from.

If you are looking at such a list of your own right now, tagging it against the nine categories is a day's work, and it usually reshuffles backlog priorities more than a new study would. We offer this as a separate short format: we take an existing report apart, show which lines are what, and say which data is missing for the decision you are about to make.