Explore B2B customer problems before designing a solution

Imagine a team considering an AI tool to improve how manufacturers manage supplier information.

The initial assumption is that supplier data is scattered across too many systems. But is that the problem customers experience?

Perhaps collecting the information is straightforward, but getting someone to verify it causes delays. Perhaps suppliers provide incomplete documents. Or perhaps the existing process works well enough, and other operational problems deserve more attention.

Each possibility points toward a different problem, and potentially a different solution.

Starting discovery with a description of the proposed AI tool can narrow the conversation too early. Instead, begin with what the customer is responsible for, how the work happens today and what makes it difficult.

First understand the work. Then investigate what, if anything, needs to change.

A useful problem-discovery conversation moves from everyday responsibilities to specific difficulties, consequences and priorities.

What to explore · Questions to ask

• Responsibilities: What are you responsible for? What does successful work look like in this area?
• Current workflow: Walk me through how this task normally happens. Who and what is involved?
• Difficulties: Where can things become complicated, delayed or uncertain?
• Consequences: What happens when something goes wrong? Who is affected?
• Workarounds and alternatives: How do you handle these situations today? What works well about the current approach?
• Priorities and triggers: When does this become important enough to require attention? What other problems compete for your time?

Notice that none of these questions assumes a new system is necessary.

That matters because a problem can exist without being important enough to solve. A process may be inconvenient but reliable. A workaround may look inefficient from the outside while serving an important purpose.

Understanding these distinctions is more useful than collecting agreement that an imagined improvement sounds attractive.

The way you ask a question can determine which problems appear in the answer.

Compare these approaches.

Leading question: "Would automating supplier information save your team time?"

Neutral question: "How does your team collect, update and check supplier information today?"

Or consider:

Leading question: "Isn’t it frustrating when different departments use separate systems?"

Neutral question: "Which people and systems are involved, and how is information passed between them?"

The neutral versions leave room for answers that challenge the original assumption.

In real customer interviews, follow up by asking for a recent specific example. Find out what triggered the situation, what the person did, what happened next and whether anything needed correcting.

When exploring with a virtual customer, a described incident is simulated, not an observed event. Use it to develop better questions rather than treating its details as evidence of what customers have experienced.

Virtual Customer lets you hold structured conversations with virtual customers representing specific roles, industries, geographic markets and company sizes.

A practical first exploration has four steps:

1. Choose a customer situation. For example, supplier information management in a mid-sized UK manufacturer. Begin with the work area rather than an assumed need for automation.
2. Select a relevant role. Start with someone responsible for the process, such as a procurement operations manager or supplier quality lead.
3. Explore the work openly. Discuss responsibilities, activities, dependencies, exceptions, current approaches and competing priorities. Avoid introducing your proposed solution during this initial exploration.
4. Challenge the emerging problem hypotheses. Ask what already works, when the difficulty does not occur, whether anyone is trying to change the process and what alternative explanations might exist.

These conversations can help a team recognize gaps in its thinking before committing time to solution design.

You can also explore another role when responsibility for the problem is unclear. The aim isn’t to find a persona that agrees with the idea. It’s to investigate whether the problem has been framed from the right perspective.

Illustrative scenario, not an actual customer study or a reported Virtual Customer result.

A product team believes industrial companies could benefit from an AI-based supplier information assistant.

Before discussing that concept, it explores the work of a procurement operations manager at a UK manufacturing company with several production sites.

The opening question is simple:

"Can you walk me through how your team handles supplier information, from receiving it to making it available to the people who need it?"

The team then investigates how information is requested, checked, updated and shared. It explores what happens when something is missing, who resolves exceptions and what workarounds exist.

Several different hypotheses could emerge:

Possible problem hypothesis · What the team needs to find out

• Information is difficult to locate.: Where is it stored, and when does finding it cause a meaningful problem?
• Supplier documentation creates delays.: What causes the delay, how is it currently resolved and what are the consequences?
• Ownership is unclear.: Who is responsible for checking and updating information, and where do handoffs break down?
• Existing processes are adequate.: Does the assumed problem matter enough to justify any change?

None of these hypotheses should be treated as a finding merely because a simulated persona describes it convincingly.

The useful outcome is a clearer set of possible problems, including the possibility that the original assumption is weak.

After the exploration, bring the potential difficulties together in a short research brief.

For each candidate problem, describe the situation in which it might occur, who experiences it, its possible consequences, how it is handled today and what remains unknown.

Then prepare real customer interviews around specific past events.

For the supplier information example, that might mean asking a procurement manager to reconstruct a recent supplier onboarding process, reviewing the actual information handoffs or speaking with the people responsible for checking documentation.

Look for evidence that helps answer three questions:

Does the problem occur? Can qualified customers describe concrete examples or show relevant work?

Does it matter? What consequences does it create, and how does it compare with other priorities?

Have we framed it correctly? Is the underlying difficulty really information management, or something else, such as unclear responsibility, external delays or approval requirements?

Real interviews, observations and relevant operational data can establish or challenge these hypotheses. Simulated conversations help prepare that investigation, not replace it.

Should I explore problems even if I already have a solution idea?

Yes. You don’t have to abandon the idea. Keep it as a hypothesis while investigating whether the customer’s work and difficulties support it. An existing product can also benefit from this approach when exploring new use cases.

What if the customer doesn’t seem to have a serious problem?

That’s useful information to investigate. The problem might be less important than assumed, occur in different circumstances or belong to another role. You may need to reconsider the problem, the customer context or whether to pursue the opportunity.