ARTICLE · Research

An organization is not a respondent

Boris Kaptelov · 02.08.2026 · 9 min

A familiar situation. A company runs twenty interviews with users of its product. The users are happy, name specific benefits, ask for two or three improvements. The product gets improved. Deals still don't close.

The mistake is not in the quality of the interviews. It is in the unit of analysis. Individuals were interviewed, but it is the organization that buys — and the two are not the same.

Who you actually interviewed

What a user says describes the user's position. It is not the company's position — and that is not a technicality.

The classic models of organizational buying by Webster and Wind and by Sheth, formulated back in the early seventies, describe a purchase as a process shaped simultaneously by the individual participants, the relationships between them, the structure of the organization itself, and the external environment. No single participant contains the whole decision.

There is also direct empirical evidence that supplier and customer see the same purchase differently. Tuli, Kohli, and Bharadwaj interviewed forty-nine managers on the customer side and fifty-five on the supplier side and found a systematic gap: suppliers describe a solution as a bundle of products and services, while customers describe it as a set of processes — defining requirements, customization and integration, deployment, and ongoing support afterward. In other words, you are selling an object, while what is being bought from you is a sequence of actions.

The practical implication is simple. Twenty satisfied users can explain why the product is pleasant to use. They cannot explain why it wasn't bought. These are different questions, and the answer to the second one sits with different people.

The buying center is a set of functions, not job titles

It is more useful to think not in terms of a list of job titles but in terms of the functions people perform in the decision. Someone initiates. Someone uses. Someone shapes the requirements. Someone controls access to information and to people. Someone formally approves. Someone pays.

Johnston and Bonoma, having studied purchase decisions in thirty-one organizations, showed that who participates and how they interact is consistently unrelated to the org chart. The same function sits with different positions in different companies. In one company, security can block the deal; in another, its opinion is merely advisory. The lawyer who signs off on the contract in a day at the first company turns out, at the second, to be the person who effectively decides whether the purchase happens at all.

Hence the sampling rule: select interviewees not by job title but by the function they performed in a specific deal. The question "who is responsible for buying this kind of software at your company" yields a formal answer. The question "walk me through how the decision went on your last similar purchase — who was involved and at what stage" yields the real map.

Roles shift as the decision unfolds

The second thing a one-off round of interviews misses: who participates, and how much each voice weighs, is not constant.

Early on, when the company is still articulating what it wants, the weight belongs to whoever describes the problem. Closer to supplier selection, the person who compares options and sets the criteria enters the game. In the final stretch, money, risk, and timelines decide — and people arrive who were not part of the conversation at all in the beginning.

That is why the same person, interviewed at different stages, will give different answers — and both will be true. And you can be late at any step: a product that didn't make it into the requirements while they were being drafted simply never reaches the comparison stage, however good it may be.

Three types of purchase mean three different conversations

The classification by Robinson, Faris, and Wind, proposed back in 1967, distinguishes three buying situations. The distinction is worth keeping in mind when assembling the corpus.

New task. The company is solving this type of problem for the first time. There are no requirements, no criteria, many participants, a long decision, and the influence of outside expertise is at its peak. This is where interviews yield the most.

Modified rebuy. Something similar has been bought before, but conditions have changed: volume has grown, regulations have shifted, the current supplier has disappointed. Requirements exist but are being revised. The most interesting question here is what exactly triggered the revision.

Straight rebuy. The company renews what already works. The decision is nearly automatic, the circle of participants narrow. An interview here will show habit, not choice, and the two should not be confused.

A corpus of thirty interviews in which twenty-eight are routine renewals will explain the mechanics of retention and tell you nothing about how you get chosen.

In construction and industrial manufacturing, this distinction is especially costly. Supplying an operating facility and supplying a new project run through different people: in the first case, the decision sits with facility operations and procurement; in the second, with the design engineer who specified the solution in the documentation a year before the purchase. Interview only the procurement staff and you will learn how you get renewed — and never learn why you weren't specified into the project.

A formal requirement is already someone's answer

A statement of work, a purchase specification, a list of tender criteria all look like a description of a need. In reality they are the output of internal work: someone has already translated the problem into a solution, screened out the options, and locked the result into a document.

Between the original situation and the formal requirement stands a chain of assumptions, some of them made by people who do not deal with the problem. A requirement like "integration with such-and-such system" may reflect a real constraint — or it may mean the document's author didn't know another way to solve the same problem.

The researcher's job here is to unwind the requirement back to its source: what situation led to it, who formulated it, what would happen if it weren't there. Sometimes it turns out that a product that fails the formal criterion solves the original problem better than the one that passes.

Needs live on several levels at once

The person sitting across from you has their department's task, the company's goal, and their own interest: don't miss deadlines, don't run into trouble during implementation, look competent in front of management.

These levels are under no obligation to coincide. A solution that is optimal for the company can be personally risky for the person championing it. This is one of the least visible reasons a good proposal fails: not because it is bad, but because the price of a personal mistake for a specific individual outweighs the company's gain.

The report must keep these apart. "The company needs to cut costs" and "the function head needs the implementation not to fall apart before year-end" are different needs, and they are addressed with different arguments. How many other different things end up in a report under the word "need" is a subject we cover in a separate piece.

Purchase, implementation, and sustained use are three different events

One more conflation that costs dearly.

The purchase is one event. Implementation is a second. Still using it a year later is a third. Between them lie different people, different obstacles, and different reasons to stop.

Macdonald, Kleinaltenkamp, and Wilson showed that the value of an enterprise solution arises not at the moment of payment but in use, and depends on the customer's own resources: whether they have data in the right shape, people with the right skills, and time to redesign the process. That is exactly why the same product produces different results at two similar companies. Klein and Sorra treat implementation as a task in its own right, with its own failure conditions that do not coincide with the failure conditions of the purchase.

It follows that all three events need to be studied. Interviews only with those who bought will explain the choice and will not explain why, for half of them, nothing ever worked.

Disagreement among participants is data, not noise

A common mistake when processing a corporate corpus is to average. The user said one thing, the CFO another, procurement a third, and what goes into the report is whatever came up most often.

The divergence is precisely the finding. It shows the line along which the argument runs inside the organization — and that is the very line your proposal will have to close. If the user talks about speed and the person paying talks about risk, you need to sell to both, with different arguments, rather than hunt for a compromise wording that will convince no one.

A report on corporate research is therefore built not as a list of needs but as a map of positions: who wants what, who disagrees with whom, and whose voice decides at which stage.

How to build a corpus around the decision

Two rules that change the outcome more than anything else.

Count interviews per participation function, not per company: five companies with one user each is a study of users, not of purchases. How this turns into a budget line is something we break down in our piece on what research costs. And be sure to include those who didn't buy, and those who bought and never implemented — without them, the corpus consists only of the people you already suit.

From the same logic follows the report's core discipline. The claim "the customer needs" is too broad if the data captures only the position of users, only procurement, or only management. Write down whose need it is, and half of the false conclusions fall away on their own.

What to do next

A corpus like this will show how the decision works at the customers you studied and where exactly you lose it. It will not show what share of the market makes decisions the same way — that requires a quantitative stage, and we say so before the work begins.

In practice this fits into a two-month project: reconstruct five to seven real deals by participation function, assemble the map of positions, and get an answer to who blocks you and at which step. From there, it is either repackaging the offer for a specific function, or a strategy session with the commercial team if it turns out that what blocks you is not an argument but the sales process.