Buyer, User, Approver, Blocker: Customer Discovery for Complex B2B Products

The B2B customer is often a decision system

A consumer can discover, buy, configure, use, and cancel a product as one person. In B2B, those actions are often divided across a group. The operations director wants an outcome. A frontline employee performs the workflow. Finance approves the budget. IT evaluates integration. Security reviews controls. Procurement negotiates terms. An executive sponsor may support the project without ever logging in.

LinkedIn defines a buying committee as a cross-functional group that evaluates and selects products for an organization. Its sales-oriented role labels are useful, but product discovery must go further. The product manager needs to understand not only how the deal closes, but how value is created after the signature.

This is why one polished persona is insufficient. A persona can represent a meaningful group of users; the existing guide to creating a user persona remains useful for behavior, goals, and context. The mistake is asking that persona to represent a purchasing system it does not control.

Six roles worth mapping

Titles vary by company, so map roles by behavior and authority rather than by job title. One person may hold several roles in a small business. In a large enterprise, one role may contain several teams.

The six-role map below is a Data Panda synthesis, not a universal organizational taxonomy; adapt it to the decision and company context.

‘Blocker’ does not mean difficult person. It means somebody with the authority, expertise, or operational exposure to stop progress. A security lead rejecting shared administrator accounts is not blocking innovation; that person may be preventing an incident. Product discovery should reveal the risk behind the objection.

Start with the decision, not the org chart

An org chart shows reporting relationships. It rarely shows how a product is selected, approved, implemented, and renewed. Begin with a specific decision: ‘How does this organization adopt a new workforce-scheduling platform?’ Then trace the sequence.

1. Who first experiences or quantifies the problem?
2. Who searches for alternatives?
3. Who participates in the evaluation?
4. Who controls budget?
5. Who approves security, legal, architecture, or operational change?
6. Who implements and supports the product?
7. Who uses it in normal and exceptional conditions?
8. Who decides whether to expand or renew?

The sequence may reveal that the “buyer” is a champion or that a peripheral team controls the schedule. NASA’s stakeholder-expectations guidance similarly notes that customers and users are usually easy to identify, while less-obvious stakeholders may impose constraints or provide lifecycle support. NASA is describing systems engineering, not a B2B buying taxonomy; the bounded product-discovery analogy is to map implementation, support, policy, and renewal roles before their constraints become surprises.

When one workforce schedule has six customers

The following example is hypothetical. A SaaS company builds workforce-scheduling software for multi-location service businesses. Discovery starts with operations leaders—the economic buyers. They report unfilled shifts, overtime surprises, and spreadsheet schedules. They like a cross-location staffing dashboard. The team concludes that forecasting and executive reporting should lead the roadmap.

The conclusion is reasonable—and incomplete.

The buyer sees coverage; the user sees another obligation

Research expands to location managers and hourly workers. The manager, often administrator and champion, must cover absences and reconcile late changes. Workers check schedules between jobs and need to give availability or decline shifts quickly. Wall schedules and messages are fragmented but familiar; the proposed workflow requires individual accounts and repeated confirmations.

The dashboard helps the buyer only if managers and workers record availability and accept changes. If input is burdensome, managers return to text threads and forecast quality deteriorates. A buyer-loved feature can fail because users carry its cost.

An operations leader can explain objectives in an interview; an hourly worker’s workflow is better observed through recent shift-change events. The customer discovery interview guide explains open-ended interviewing; pair interviews with observation, rosters, and shift-swap messages.

The approver sees commitment, not interface quality

Finance asks where the benefit appears and who owns the budget. Procurement asks whether pricing grows by location, administrator, or active worker. HR asks about data retention and labor rules. These are product and packaging questions, not late paperwork.

If value is fewer uncovered shifts but pricing is per named user, the customer may share manager accounts or exclude hourly workers from self-service. That weakens audit history and adoption. The pricing unit has changed user behavior—and it was not in the prototype.

The evaluator and blocker see lifecycle risk

Payroll and IT ask how worker identifiers, pay codes, approved hours, and accounts fit existing systems. Security asks about shared devices, permissions, and employee data. A labor-policy owner asks whether rest, overtime, notice, and union rules can be represented safely. A location leader needs a fallback when the service is unavailable during a callout. Payroll integration, policy configuration, and fallback are product requirements.

The team reframes the first release. It keeps cross-location reporting, but prioritizes fast availability and shift confirmation, a manager exception flow, payroll export, role-based access, auditable schedule changes, and a roster import. It tests pricing against active locations or workforce bands, not named users. The decision is not ‘buyer versus user.’ It is a coherent value chain in which each role must do its part.

Run discovery as a role-by-question matrix

Do not ask every role the same interview script. Shared questions are useful for comparing perspectives, but each role sees a different slice of reality.

Questions for users

• Walk me through the last time you completed this task.
• What interrupted the normal process?
• Which information did you not have?
• What happens when the system is unavailable?
• Which step feels pointless, risky, or duplicated?

Questions for champions and buyers

• Why is this problem important now?
• Which measurable outcome justifies change?
• What other initiative competes for the same budget?
• Who must believe the case before funding is released?
• What result would make expansion an easy decision?

Questions for approvers, evaluators, and blockers

• What must be true before you can approve this?
• Which evidence is required, and in what format?
• Which integration or policy has caused problems before?
• Who owns the system after implementation?
• What would make the risk unacceptable even if the business case is strong?

Ask about a recent decision, not an abstract preference. ‘Tell me about the last vendor security review that failed’ produces evidence. ‘Would good security be important?’ produces a very agreeable answer.

The GOV.UK Service Manual recommends interviewing and observing actual or likely users, reviewing existing evidence, and treating suggestions that do not come from users as assumptions to be tested. It also notes that teams should understand people who provide or support a service, not only a typical end user. That principle fits complex B2B products well: a stakeholder opinion can be valuable evidence about approval or operations without becoming evidence of user behavior.

Synthesize disagreement instead of averaging it

After discovery, create one row per consequential need and one column per role. Record the evidence, strength, consequence, and unresolved conflict. Do not count mentions and call the most frequent statement the winner.

Suppose hourly workers want a quick way to decline a shift, while the labor-policy approver requires reasons for regulated exceptions and an audit trail. These needs conflict only if the team assumes every decline requires the same manual fields. Alternatives include defaults, progressive disclosure, payroll data, or collecting detail only when a policy exception is triggered.

This is where laddering and the 5 Whys help. The technique can move a role from a proposed solution—‘We need a PDF report’—toward the underlying outcome—‘An auditor must verify who approved the change.’ Once the outcome is visible, the product team has more design freedom.

Four common discovery failures

1. Interviewing whoever sales can reach

Accessible contacts are not necessarily representative contacts. Start with them, but mark role gaps explicitly. If no user has been observed, do not label buyer feedback as user validation.

2. Treating the loudest objection as the blocker

The real veto may sit with an uninvited team. Ask each participant, ‘Who else can stop or delay this decision?’ Repeat until the map stabilizes.

3. Mixing needs, approval criteria, and feature requests

A user need describes an outcome in context. An approval criterion defines an acceptable boundary. A feature request proposes a solution. Keep all three, but do not confuse them. The article on requirements-gathering mistakes explains why prematurely copying solutions into requirements creates weak products.

4. Stopping at purchase

A signed contract is not product adoption. Include implementation, normal use, exception handling, support, renewal, and exit. A product that passes procurement but cannot survive daily work has not completed discovery.

Before discovery closes: nine role-map checks

• Define the organizational decision or adoption journey being studied.
• Map user, champion, economic buyer, approver, evaluator, and blocker roles.
• Identify people who implement, support, renew, and retire the product.
• Choose a method appropriate to each role’s knowledge.
• Separate direct observation, reported experience, policy, and opinion.
• Trace each important need to a product, packaging, evidence, or implementation consequence.
• Document conflicts rather than averaging them away.
• Mark missing roles and weak evidence.
• Test the full value chain: purchase, implementation, use, support, and renewal.

In complex B2B products, there may be one customer logo but there is rarely one customer perspective. The product manager’s job is not to make every stakeholder equally happy. It is to design a system in which enough value reaches each necessary role—and no hidden constraint quietly stops the whole thing.