Start with the problem before you choose the persona
Teams often begin with a role because it feels plausible: “This sounds like an HR problem” or “Finance should care about the savings.”
Turn that assumption around. Start with the problem and ask what happens inside the customer organization when it occurs.
Who experiences the friction directly? Who is accountable for the outcome it affects? Who coordinates the workaround? Who would notice if the problem disappeared?
Those questions help you create a short set of credible role hypotheses before refining the solution for one persona.
Compare roles inside the same customer context
A useful role comparison changes the role while keeping the surrounding business context stable.
For each candidate role, explore the same five lenses:
Lens · What to investigate
- Problem exposure: How directly does this role encounter the problem?
- Outcome ownership: Is this person accountable for an outcome the problem affects?
- Current response: What can this role do today when the problem occurs?
- Value connection: What improvement would matter from this role’s point of view?
- Responsibility and resources: Does this role control relevant people, process, authority or budget, or would another function need to act?
The goal is not to find the role with the most enthusiastic simulated response. It is to understand how the logic of the problem changes across functions.
Separate the primary customer question from stakeholder mapping
Choosing the right role is not the same task as mapping the whole buying group.
At this stage, you are asking: Which customer perspective should we understand first because it is closest to the problem, outcome or responsibility we care about?
Later, you may need to investigate users, champions, approvers, procurement, IT, security and other stakeholders around a purchase or implementation. That is a different discovery question.
Keeping the tasks separate prevents a long stakeholder list from hiding a more basic uncertainty: whether you started with the right customer function.
Example: is employee planning an HR, finance or operations problem?
Illustrative example, not a customer result.
A team is exploring a B2B product intended to improve employee planning in multi-site service companies. Three customer roles seem plausible: HR, finance and operations.
The team keeps the company type, size, region and underlying planning problem consistent. It then explores the problem through three AI-simulated role perspectives.
With HR, the questions focus on workforce policies, staffing capability and employee impact. With finance, they focus on cost visibility, forecasting and financial consequences. With operations, they focus on getting enough people with the right capabilities into the right work at the right time.
The purpose is not to ask which role “likes” the product. The team compares where the problem appears, who owns the consequences, what each role can change and what would make the issue important enough to act on.
If the comparison suggests that operations is closest to the recurring problem while HR controls important inputs and finance cares about the economic consequence, that is still only a hypothesis. The next step is to investigate the most consequential role assumptions with real people.
Build a role hypothesis, not a buyer verdict
After comparing the roles, capture the result as a team-compiled role hypothesis.
For each role, record how close it appears to the problem, which outcome it owns, what value it might recognize, what authority or resources it controls, and what remains uncertain.
Then choose the role where real customer research could answer the most important open question.
You may discover that the role experiencing the pain is not the role with budget. That does not make either one wrong. It may mean the offering has a user-value question and a separate commercial question that should be investigated in sequence.
Let real customers determine where ownership actually sits
Virtual Customer can help expose competing role hypotheses and sharpen the questions you take into customer research. It cannot prove that a particular function owns the problem, controls budget or will sponsor a purchase.
Real organizations divide responsibilities differently. Job titles can hide different mandates, and the same responsibility may sit in different functions across companies.
Use real customer conversations to validate where the problem is experienced, who is accountable for the outcome and who can act on it. Once that is clearer, you can go deeper into the solution and map the broader stakeholder group around adoption and buying.
Start with three plausible roles
Choose one problem and one customer context. Compare three functions that could plausibly experience, own or care about the problem, then identify the role assumption that real customer research should test first.