How to interview B2B buyers, users and champions (they want different things)

To interview B2B buyers, users and champions, ask each person only about the part of the purchase they actually did, because each role cares about different things. Sometimes one person holds all three roles. Your job is to find out who does what in this organization instead of guessing authority from a job title.

Start with one real workflow and one recent change to it. Map who took part, then ask each about the part they saw or controlled. That beats sending the same "Would you buy this?" script to every contact, which mostly measures who is polite.

The National Science Foundation describes customer discovery in its I-Corps program as engagement with potential customers, partners and other industry stakeholders (NSF's description of customer discovery). For a B2B founder, the end user is only one of the people to learn from.

1. Map functions before titles

This role map is a research aid, not a claim that every company has five separate people or one buying process.

A founder can be user, owner, champion and approver at once. In another business, a team lead may champion a product with no spending authority. Record the overlaps instead of recruiting someone for each label just to fill the table.

Ask "Who was involved last time?" before "Who would be involved?" The first question reveals an actual process. The second is still useful, but its answer is a forecast.

The example: a quality issue tracker

Here is a made-up example. A team is building software for a small manufacturer's quality issues. These are illustrative research notes, not findings from an Instant Expert customer.

An inspector records each issue. A production supervisor decides whether work can continue. An operations manager wants clearer reporting and proposes a new tool. The owner approved the last software purchase. An outside IT provider helped set up access.

The inspector's complaint is repetitive entry. The supervisor worries about someone marking an unresolved issue complete. The operations manager wants visibility across shifts. The owner remembers a previous rollout that took more setup time than expected.

Calling these "four requests for quality software" erases the differences. They are four views of one proposed change, and your next research notes should show where they meet.

2. Ask each role about the event they own

For the user, follow the work. "Walk me through the last issue you recorded. What information did you have? Did you bring in anything from elsewhere? What happened after you submitted it?" Ask which steps they did themselves and which they only heard about.

For the workflow owner, follow exceptions. "Tell me about the last issue that didn't follow the normal process. What did you decide? What did you need to see first? Who could reverse or override that decision?" This finds constraints a happy-path demo misses.

For the champion, follow the internal effort. "When you last proposed changing a tool, what did you have to prepare? Who needed to be involved? What delayed it?" Enthusiasm matters, but the work of carrying a change through the organization is a separate subject.

For the approver, follow a comparable decision. "What was your role in the last purchase of this kind? What alternatives were considered? What made the proposal ready for a decision?" If they weren't involved, don't ask them to invent the organization's budget process.

For a reviewer or implementer, follow a rollout. "What did you check or configure last time? What couldn't proceed until that was done? Did any work need redoing?" Capture requirements in their words and verify details with the right specialist later.

Keep every path tied to the original decision; you are not auditing the whole organization. Drop a tangent once it stops changing what you understand about the workflow, the change or its adoption.

3. Recruit for responsibility, not seniority

Write a recruitment brief. GOV.UK recommends specifying participant criteria and checking that a recruiter's screening questions match the research need (the recruitment brief guidance).

For the made-up tracker, one criterion might be: "Personally recorded or reviewed a production quality issue during the last completed work cycle." For a purchase interview: "Participated in selecting, approving or implementing a comparable workplace tool." Fit the timeframe to the activity, so an arbitrary recency rule doesn't exclude the very purchase you need.

Screen with a short example of what the person did. Don't make them send internal records to qualify; a description or a permitted, redacted document shows how the decision works.

If a champion introduces colleagues, give each one room to disagree. A group call with their manager can help reconstruct a shared handoff, but it can hide private priorities. (Few people call the boss's favorite project a mess with the boss on the line.) Choose the format on purpose and record who was there.

4. Settle contradictions with a design question, not a vote

In the example, the inspector wants fewer required fields while the supervisor needs enough information to decide whether work can continue. Both accounts can be accurate.

Turn the conflict into a concrete design question: "Which information must exist before the supervisor makes the continuation decision, and which can be added afterward?" Then investigate a recent case. That gets further than declaring one person resistant to change.

Keep a record with five fields: role, event, statement, consequence and unanswered question. Add the organization too, so several colleagues describing one process don't pass for independent market examples. Talk to other organizations before claiming how common a process is.

End the round with an adoption map

Finish with a map of who does the work, who carries the proposal, who decides and what must happen before use begins. Mark the unknowns. Your next interview should fill a missing role or a disputed handoff, not add another friendly name to the list.