Early in a product’s life, there is a temptation to start building as soon as you identify a problem.

You talk to a few potential customers, hear an interesting idea, and suddenly the roadmap starts taking shape.

But one of the biggest advantages of Voice of Customer research is that it can help you slow down before you build.

In early-stage product discovery, VoC isn’t about collecting a long list of feature requests.

It’s about understanding the problems, motivations, behaviours, and constraints that exist before you’ve decided what the solution should be.

Start With Problems, Not Features

Imagine you’re building a product for sales teams.

During an interview, someone says:

“We need an AI assistant that automatically writes follow-up emails.”

It’s tempting to add “AI email generation” to the backlog.

But that’s not yet the problem.

Ask why.

Maybe salespeople spend too much time writing emails.

Maybe they don’t know what information to include.

Maybe follow-ups are inconsistent.

Maybe they’re unsure when to contact prospects.

The requested feature is only one possible solution.

VoC helps you understand the problem before committing to the solution.

Look for Problems That Already Exist

Early-stage discovery should focus on what customers are doing today.

Ask questions such as:

• How do you handle this today?
• What happens when the problem occurs?
• How frequently does it happen?
• What makes it difficult?
• What have you tried already?
• What does the current workaround cost you?

Workarounds are particularly interesting.

If customers are using spreadsheets, manual processes, multiple tools, or complicated internal workflows to solve something, that can be evidence that the problem is meaningful.

People often reveal the importance of a problem through the effort they’re willing to invest in solving it.

Don’t Treat Every Interview as Validation

There’s another common trap.

You have an idea and conduct interviews looking for confirmation.

When someone says, “Yes, I’d use that,” it feels like validation.

But hypothetical enthusiasm isn’t the same as demonstrated need.

A better question is:

“Tell me about the last time this happened.”

Real examples reveal much more.

You can understand frequency, consequences, workarounds, and existing behaviour.

The goal isn’t to convince customers that your idea is good.

It’s to discover whether the underlying problem is important enough to solve.

Look for Patterns Across Customers

One customer can provide an interesting insight.

Several customers independently describing similar problems provide stronger evidence of a pattern.

But don’t simply count how many people mentioned the same phrase.

Look for similarities in:

• Problem
• Context
• Frequency
• Severity
• Existing workaround
• Desired outcome

Two customers may request completely different features while actually experiencing the same underlying problem.

Conversely, ten customers may request the same feature for completely different reasons.

The Product Manager needs to identify the common problem, not just the common wording.

Combine VoC With Behaviour

What customers say is valuable.

What they do is valuable too.

Suppose customers tell you that a particular workflow is extremely important.

Then you look at product or operational data and discover that most customers rarely use it.

That doesn’t automatically mean the customers are wrong.

It means you have something to investigate.

Perhaps the workflow is valuable but difficult to use.

Perhaps customers only need it occasionally.

Perhaps they’re using another process instead.

VoC becomes much stronger when combined with behavioural evidence.

Use VoC to Define the Problem

A good outcome from early discovery isn’t necessarily a feature specification.

It might be a clear problem statement.

For example:

Weak:
“Customers want automated reporting.”

Stronger:
“Operations managers spend several hours each week manually combining information from different systems before they can understand team performance.”

The second statement gives the team much more room to explore solutions.

That’s exactly what you want early in discovery.

Don’t Build for Everyone

Early-stage products rarely need to solve every version of a problem.

VoC can help you identify who experiences the problem most intensely.

Maybe the problem is particularly painful for:

• Small businesses
• Enterprise administrators
• Frequent users
• Specific industries
• Particular roles

This can help narrow the initial target segment.

A focused problem for a specific customer group is often more useful than a vague problem affecting everyone.

Final Thought

Voice of Customer research is particularly powerful early in a product’s life because the cost of being wrong is high.

Once you’ve invested months building something, it’s harder to question the original assumption.

Early discovery gives you the opportunity to ask:

Is this actually a problem?

Who experiences it?

How important is it?

How are they solving it today?

What outcome are they really trying to achieve?

The best early-stage VoC work doesn’t tell you exactly what to build.

It gives you enough understanding to build the right thing for the right problem and the right customer.