Treat company size as a clue to complexity, not a customer type
Employee count alone does not tell you how a company makes decisions.
A large organization might be centralized, decentralized or somewhere in between. A local business unit may have considerable autonomy, while another company of similar size coordinates technology, procurement or processes centrally.
Start with a controlled comparison. Keep the industry, geography, offering and initial customer role as comparable as possible. Change the company-size and organizational context, then ask what else appears to change.
Retest the assumptions that scale can affect
Use the same questions in both customer contexts.
Area · What to revisit
- Problem and scope: Does the problem stay within one team, or connect to work across teams, sites or business units?
- Authority: Can the person experiencing the problem make the relevant decision, or does approval sit elsewhere?
- Governance: Which policies, standards or controls affect how the work is changed?
- Implementation: What systems, teams, data or rollout steps could the product depend on?
- Support and ownership: Who administers the product, supports users and owns problems after launch?
- Buying process: Which commercial, technical, legal or procurement questions must be resolved?
- Value: Does coordination, consistency, risk or scale change the business case?
Do not assume every row becomes more complicated. Find out which ones matter in the customer context you are targeting.
Keep the role constant first, then follow the dependencies
If smaller customers are typically championed by a department manager, compare that role with an equivalent manager in a larger organization. Ask the same core questions about goals, current work, constraints, authority, implementation and success.
Then follow the dependencies that emerge.
The larger-company perspective may raise another role that needs investigation, such as central operations, IT, security, procurement or an executive sponsor. Or it may show that the department remains largely autonomous.
Do not add an enterprise buying committee because the org chart is large. Add roles because the decision or implementation depends on them.
Example: the same workflow product in two organizational contexts
Illustrative example, not a customer result.
A B2B workflow product is already used by operations managers in smaller industrial service companies. A manager can configure the product and adapt the workflow with relatively little coordination.
The company now wants to serve multi-site enterprise customers.
The product team compares two AI-simulated operations managers in the same industry and region: one in a smaller company and one responsible for a business unit inside a multi-site enterprise.
The questions stay consistent. How is work coordinated today? Who can change the process? Who is affected by implementation? What would make adoption difficult? How would success be judged?
If the enterprise conversation introduces dependencies on central systems, standardized processes or other stakeholders, the team records those as hypotheses. It does not assume every large customer will have them.
Build a size-transfer map before you build enterprise features
After the comparison, sort what you learned into three groups.
Keep: assumptions that still appear plausible and do not currently need special enterprise treatment.
Retest: assumptions where organizational scale could materially change the problem, workflow, value or adoption path.
Add: roles, requirements or implementation questions that were not important in smaller customers but may now influence the decision.
Your team can compile this as a working comparison, not an automatic Virtual Customer score.
This also helps prevent one enterprise prospect from turning every request into an “enterprise requirement.” A request might represent a broad pattern, a particular operating model or a one-account exception. Discovery should identify which explanation needs evidence.
Validate the enterprise assumptions that could change your strategy
Virtual Customer can help expose hidden dependencies and prepare sharper questions before you invest in an enterprise roadmap or sales motion. It cannot establish that all enterprises behave alike, prove demand, verify procurement or security requirements, or predict whether a large account will buy.
Use real enterprise customer conversations, implementation experience, product data and relevant technical, security or procurement expertise for decisions that depend on them.
The useful outcome is a smaller set of explicit questions: what still transfers from smaller customers, what genuinely changes in the target enterprise context, and what must be true for your product to serve that context without becoming a collection of one-off exceptions.
Start with one role in two company contexts
Choose a customer role you already understand. Compare that role in a smaller company and a larger, more complex organization while keeping the industry, geography and product constant. Then identify the additional stakeholder or implementation assumption that most needs real customer validation.