Buyer versus user in B2B

The person who uses it is often not the person who pays. Building only for the user gets you loved and unpaid.

What is it?

In B2B there are usually several people involved in a purchase:

The user — uses it daily, feels the pain The buyer / economic buyer — controls the budget and signs The champion — advocates for you internally The blocker — IT, security, procurement, legal

They care about entirely different things.

Why does a founder care?

Because a product that delights users and has no answer for the buyer does not get bought. And a product sold to the buyer that users resent gets cancelled at renewal.

Most first-time B2B founders build only for the user, because the user is who they interviewed and who gives the warmest feedback.

Example

The scheduling tool.

The ops manager (user) cares about getting Friday back. Their pitch is 'build the rota in ten minutes instead of three hours'.

The ops director (buyer) does not build rotas. They care about on-time delivery, overtime spend and not losing a manager to burnout. Their pitch is 'cut overtime by 8% and reduce scheduling errors'.

IT (blocker) cares about where the data lives, SSO, and whether this creates work for them. If you cannot answer, the deal stalls indefinitely regardless of how much the manager loves it.

Same product, three different conversations. A founder who only has the first one gets enthusiastic users and no signed contracts — and usually concludes the product is not good enough, when the actual gap is that nobody ever made the case to the person with the budget.

The common mistake

First-time founders often assume an enthusiastic user will do the internal selling for them. Champions need ammunition — a business case in the buyer's language, ideally something they can forward without editing.

The second mistake: not asking who signs. It is a completely normal question — 'who else would need to be involved in a decision like this?' — and asking it in the first call saves months.

The third: ignoring blockers until late. Security review is not a formality in most organisations; it is a gate that can add two months.

How it works

Step 1: Map the buying group early

For your ICP, list who uses, who signs, who influences, who can block.

Step 2: Ask directly in the first call

'Who else would need to be involved in a decision like this?' Normal, expected, and saves months.

Step 3: Write a different pitch for each

User: time and frustration. Buyer: money, risk, outcomes. Blocker: compliance and effort.

Step 4: Arm your champion

Give them a one-page business case in the buyer's language that they can forward without editing.

Step 5: Handle blockers before they block

A basic security overview and a standard data-processing answer prepared in advance removes weeks of delay.

Step 6: Keep users happy for renewal

The buyer signs the first contract; the users decide whether there is a second one.

When to use this

Any B2B sale above roughly $200/month, where more than one person is involved.

When not to use it

Not relevant for consumer products or genuinely self-serve B2B where a user pays by card without approval. It becomes relevant the moment there is a procurement step.

Do this now

Apply this to your own startup in My Full Journey (free account).