Main idea

In B2B, the person who uses the software and the person who buys it are rarely the same. The buyer pays, arbitrates between competing projects, champions this one before their management, carries the risk if it fails and wonders whether the rollout will hold. Their criteria are therefore not the user's: they are evaluating a decision, not a tool.

Three situations follow, and they are observed routinely. A product appreciated in the field that does not sell. A product that solves a real problem and gets blocked at purchase time. A product that is good, but incompatible with the way the organization decides — procedure, approval thresholds, reversibility requirements, the internal team's capacity to carry the rollout.

Succeeding with the user and succeeding with the customer are therefore two distinct tests, and passing the first does not excuse you from the second.

Why it matters

This separates two diagnoses that get confused when a sale fails. A product that does not sell despite satisfied users does not have a problem of value in use; it has a problem of value for the buyer, and improving the user experience does not fix it.

It also says what has to be discovered beyond usage: what motivates and what blocks the purchase, whom the buyer has to justify themselves to, and what their organization requires before signing.

Nuances and limits

The separation is not always clean: in a small structure, the user and the buyer can be the same person, and the reasoning collapses onto a single set of criteria.

And adoption by users does weigh on the purchase decision — it is an argument for the buyer, not a guarantee.

Open questions

• At what point in a product discovery should you go and see the buyer, when access to the field is easier and richer?