How to interview B2B users, buyers, and internal champions

A person who uses a product, a person who wants it introduced, and a person who approves its purchase may have different reasons for caring. Sometimes they are the same person. Your research needs to establish who does what in this organization, rather than infer authority from a job title.

Start with one real workflow and one recent change to it. Map the participants in those events. Then ask each person about the part they witnessed or controlled. This produces a more useful account than sending the same “Would you buy this?” script to every contact.

The National Science Foundation describes customer discovery in its I-Corps program as engagement with potential customers, partners, and other industry stakeholders. The useful lesson for a B2B founder is that learning about an opportunity extends beyond interviewing the eventual end user. Read NSF’s description of customer discovery.

Map functions before titles

The following role map is a practical research aid, not a claim that every company has five separate people or follows the same procurement process.

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

Ask “Who was involved last time?” before “Who would be involved?” The first question can reveal an actual process. The second is still useful, but its answer may be a forecast.

A worked example: a quality issue tracker

Consider a fictional team developing software for a small manufacturer’s quality issues. These are illustrative research notes, not findings from an Instant Expert customer.

An inspector records the initial issue. A production supervisor decides whether work can continue. An operations manager is interested in clearer reporting and proposes a new tool. The owner approved the last software purchase. An external 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 required more setup time than expected.

Calling these “four requests for quality software” erases the differences. They are four views of the same proposed change, with different consequences. The next research artifact should show where those views interact.

Use a different question path for each responsibility

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

For the workflow owner, follow exceptions. “Tell me about the last issue that did not follow the normal process. What decision did you make? What did you need to see first? Who could reverse or override that decision?” This reveals constraints a happy-path demo can miss.

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? Did anything delay the proposal? If so, what?” 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 were not involved, do not 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 could not proceed until that was done? Did any work need to be repeated? If so, what happened?” Capture requirements in their words and verify details with the appropriate specialist later.

These paths should stay connected to the original decision. You are not conducting a complete organizational audit. Stop a tangent when it no longer changes your understanding of the workflow, the proposed change, or its adoption.

Recruit for responsibility, not seniority

A written recruitment brief helps keep this map useful. GOV.UK recommends specifying participant criteria and checking that a recruiter’s screening questions actually match the research need. Read the recruitment brief guidance.

For the fictional tracker, a criterion might be: “Personally recorded or reviewed a production quality issue during the last completed work cycle.” For a purchase interview, it might be: “Participated in selecting, approving, or implementing a comparable workplace tool.” Adjust the timeframe to the activity; do not use an arbitrary recentness rule that excludes the relevant purchase.

Screen with a brief example of what the person did. Avoid requiring them to send internal records just to qualify. You can understand the decision mechanism through a description or a permitted, redacted artifact.

If a champion introduces colleagues, give each participant room to disagree. A group call with their manager may be useful for reconstructing a shared handoff, but it can obscure differences in private priorities. Choose the format deliberately and record who was present.

Resolve contradictions at the workflow level

Do not settle conflicting answers by taking 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.

Write the conflict as 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. This is more actionable than declaring one stakeholder resistant to change.

Keep a record with five fields: role, event, statement, consequence, and unanswered question. Add the organization so several colleagues describing one process do not masquerade as independent market examples. Expand to other organizations before making claims about how common that process is.

End the round with an adoption map: who does the work, who carries the proposal, who decides, and what must happen before use begins. Mark unknowns explicitly. Your next contact should address a missing responsibility or a disputed handoff, not simply add another friendly name to the research list.