Use virtual customers to uncover adoption gaps before a B2B release

Write two short versions of the same customer task: how it works today and how it is expected to work after the release. Include the trigger, person acting, information needed and next person involved.

Make the difference explicit. A new exception queue might move work from a manager to an analyst. An approval feature might add accountability while also adding a waiting step. A self-service setting might remove a support request but require an administrator to make a decision previously handled elsewhere.

This description keeps the conversation anchored to the release. It also reveals assumptions that a feature list can hide, such as available permissions or knowledge of an unfamiliar term.

Use the same five questions for each relevant role:

1. Trigger: How would this person know that action is needed?
2. Action: What would they need to understand before taking the next step?
3. Permission: Which access rights, approval or responsibility must already be in place?
4. Exception: What happens when the normal path does not fit the situation?
5. Handoff: Who relies on the result, and how would they know it is ready?

Ask about the current routine first. Then describe the planned change and explore where it could interrupt that routine. Keep your wording neutral: a release you call “simpler” may distribute the work differently rather than remove it.

Choose a modeled geography, industry, company size and role that reflect the intended rollout group. Explore the main user’s perspective, then a role responsible for configuration or downstream work.

Keep the release description and core task consistent across conversations. If you change both the customer context and the feature between sessions, you will not know which difference prompted a new concern.

Capture possible handoff gaps in your own release notes. Separate unclear language, missing responsibility, technical uncertainty and an untested assumption about behavior. They require different follow-up actions; not every concern belongs in the backlog as a new feature.

Illustrative scenario, not a customer result.

A product team is adding a shared exception queue to a logistics platform used by mid-sized companies in the United States. Previously, operations managers distributed exception reports by email. The new queue lets analysts take ownership of individual items.

The team explores an analyst’s perspective on finding and claiming work, a manager’s perspective on unresolved items and an administrator’s perspective on access. The proposed feature stays the same in each conversation.

A useful investigation concerns what “claimed” means. Does it signal that someone has started, accepted responsibility or completed a review? The team turns that ambiguity into a task for a real-user walkthrough: identify an item, take ownership and explain what a colleague should do next.

The simulated exploration has helped define the test. It has not demonstrated that customers can use the interface successfully.

For each potential gap, decide where the next action belongs:

• Explain: Clarify a term or responsibility in the release communication, then check comprehension with the intended role.
• Observe: Watch a real user attempt the changed task with a prototype or suitable test environment.
• Investigate: Talk to the person who controls a dependency you do not understand.
• Measure: Define an observable rollout outcome, such as whether ownership is followed by task completion.

A page visit, positive comment or button click is not necessarily completion of the customer task. Choose the observation that corresponds to the behavior the release is intended to change.

Virtual customers support preparation; they do not execute your interface, establish usability or verify production readiness. Use engineering checks for technical behavior and real customer activity for adoption evidence.

Before rollout, name the owner of each unresolved question and the evidence needed to proceed. A reversible pilot may answer some questions more effectively than another discussion. Other gaps, such as unclear responsibility for a consequential action, may need resolution first.

After release, compare the actual pattern of use with your original expectations. Keep surprising outcomes visible rather than explaining them away with the earlier simulated conversation.