B2B Product Discovery When Buyers and Users Disagree

A user can love a B2B product that their security team will never approve.

A buyer can sign a contract for a tool that administrators cannot operate. An economic owner can demand savings while frontline users absorb extra work.

Calling all of these people “the customer” hides the decision you need to make.

B2B discovery starts by separating the people who use, choose, fund, review, introduce, and maintain a product. It then studies how their constraints meet in one buying and operating system.

That separation is not an invitation to create six personas for every account. It is a way to find whose evidence is missing before the team mistakes enthusiasm for demand.

One product, six different tests

Consider a fictional workflow product for regional logistics firms. It promises to replace emailed spreadsheets with a shared exception queue.

The apparent user is a dispatcher. Yet adoption also depends on an operations director, an IT administrator, a security reviewer, procurement, and the finance leader who owns the budget.

Each role is testing a different proposition:

Role	Decision or job	Evidence they may require	Failure hidden from other roles
Dispatcher	Resolve exceptions during a busy shift	Faster triage without losing context	More data entry than the spreadsheet
Operations director	Improve flow across depots	Comparable status and clear escalation	Local teams invent workarounds
IT administrator	Introduce and support the service	Identity, access, audit, configuration	Support demand exceeds capacity
Security reviewer	Accept information risk	Data flows, controls, retention, suppliers	A critical control is absent
Procurement	Complete a compliant purchase	Terms, vendor evidence, price structure	Review time breaks the sales cycle
Finance owner	Fund the change	Credible value, total cost, reversibility	Savings rely on unproven adoption

These are possible roles, not a universal cast list.

Webster and Wind described industrial and institutional buying as an organisational decision-making process. Their model is a useful lens, not proof that every purchase follows fixed roles.

Start with the decisions present in this market and account type. Name people only after you understand what must be decided.

Draw the decision topology

A journey map usually follows one actor. A B2B decision topology follows the hand-offs, vetoes, dependencies, and information exchanges between actors.

Put the product change in the centre. Around it, write the decisions required from first interest to routine operation.

For the workflow product, the chain might be:

1. A dispatcher confirms the problem is frequent and costly enough to change.
2. The operations director agrees on a common process across depots.
3. IT confirms the service can fit identity and support arrangements.
4. Security accepts the proposed data handling and controls.
5. Procurement accepts the supplier and commercial terms.
6. Finance releases budget against an expected operating benefit.
7. Depot managers make time for training and transition.

Now mark who can block each decision, who supplies evidence, and who bears the cost if it is wrong.

The map often reveals that influence and consequence sit in different places. Procurement may delay the purchase, but dispatchers may carry the daily cost of a poor workflow.

That difference changes recruitment. High authority does not make someone a reliable witness for frontline work. Frequent use does not make someone a reliable witness for legal review.

Turn conflict into research questions

Do not ask every participant whether they like the same concept. Ask each one for evidence about the decision they actually face.

For dispatchers:

• Show the last three exceptions that crossed teams.
• Where did information go missing or arrive late?
• What must remain visible during a shift change?
• Which step would become harder in the proposed workflow?

For administrators:

• Walk through how a new service enters your estate.
• Which identity and access arrangements are mandatory?
• What creates recurring support work after launch?
• Which configuration must remain under local control?

For security reviewers:

• Which data classifications and flows trigger review?
• What evidence is required before a decision can be made?
• Which controls are absolute, and which allow mitigation?
• How early must supplier evidence be available?

For the economic owner:

• Which cost or risk would justify funding a change?
• Who owns the baseline and can verify movement?
• Which implementation costs are commonly omitted?
• What outcome would make renewal difficult to defend?

The point is not to collect opinions evenly. It is to reduce the uncertainty attached to each necessary decision.

This extends a systematic customer discovery process. In B2B work, the system must cover linked decisions rather than a single interview audience.

Recruit against gaps, not convenience

A convenient sample can make a weak proposition look coherent.

Suppose the team recruits eight dispatchers through a friendly customer and two operations directors introduced by sales. Feedback is positive, and the prototype handles the visible workflow well.

The evidence still has three serious gaps:

• no administrator has assessed support and identity work;
• no security reviewer has examined the data flow;
• no non-customer has explained why a similar purchase previously stopped.

More dispatcher interviews will not close those gaps.

Create a recruitment grid with rows for required decisions and columns for market segments. Mark three states: evidence present, evidence weak, and no access.

Segment deliberately. A regulated enterprise, a regional operator, and a small owner-managed firm may have different buying systems. A single role label does not erase those differences.

Use market segmentation to define meaningful contexts.

Then use user archetypes to represent recurring needs without pretending that a job title predicts them.

Access is itself evidence. If the team cannot reach security or administration during discovery, buyers may face the same coordination problem during a real purchase.

Record the gap instead of replacing the missing voice with an internal expert’s guess.

Reconcile evidence in a role-conflict ledger

After each round, do not merge notes into one average customer view. Keep disagreements visible.

Use a ledger with five fields:

1. Decision: what must be accepted or performed?
2. Role evidence: what did the relevant participants show or report?
3. Conflict: which other role’s need makes this harder?
4. Product response: can design, policy, service, or positioning address it?
5. Residual uncertainty: what remains unknown, and who can answer it?

In the fictional case, dispatchers want open text for speed. Operations wants structured fields for reporting. Security wants restricted data entry to reduce sensitive information in free text.

“Users prefer flexibility” is not a useful synthesis. The product must decide which information is required, where free text is safe, and whether reporting value justifies added effort.

A useful test could compare two task flows using realistic exception cases. It should examine completion, missing context, correction effort, and the downstream report, not just stated preference.

Research-driven concept validation can test the interaction. It cannot settle retention policy or prove financial value. Those require different evidence and owners.

Make the no-go decision before enthusiasm wins

The fictional team completes a second research round.

Dispatchers can resolve common exceptions with less searching. Operations can see cross-depot status. The interaction risk is lower than before.

However, three target firms require customer-controlled encryption keys. The current platform cannot provide them without architectural work that would delay the product by two quarters.

Those firms represent the segment with the strongest stated willingness to buy. Smaller firms do not require the control, but their problem is less frequent and their budgets are lower.

The honest decision is not “continue discovery”. It is a conditional no-go for the original segment and proposition.

The team now has three explicit options:

• invest in the missing control and reassess cost and timing;
• choose a segment where the control is not required and revalidate value;
• stop the initiative because neither route fits strategy.

Positive user feedback does not overrule a purchase constraint. A security veto does not prove the user problem is weak. The evidence changes the decision boundary.

What the model cannot tell you

A role map can become theatre if it is copied from a generic buying-centre diagram.

One person may hold several roles. A champion may influence the process without formal authority. A procurement gate may appear late or not at all. Power may shift when the purchase changes from trial to enterprise rollout.

Interview accounts also have limits. Participants may not remember an approval path accurately, and stated willingness to buy is not a transaction.

Triangulate interviews with artefacts where access allows: security questionnaires, approval checklists, support tickets, contracts, implementation plans, and records of abandoned evaluations.

Do not collect sensitive commercial or security material without permission and a clear handling plan.

The result of B2B discovery is not agreement among roles. It is a defensible view of which linked decisions can pass, which cannot, and which evidence is still missing.

That is enough to choose the next research move without inventing a single, convenient customer.

Sources

• Webster and Wind: a model of organisational buying decisions
• GOV.UK Service Manual: start by learning user needs
• GOV.UK Service Manual: plan user research for your service

Read next

• How to approach customer discovery systematically
• How to build a winning market segmentation approach
• A practical guide to user archetypes
• Research-driven concept validation