Stop Outsourcing the Solution in Customer Interviews

Customers are experts in their problems. They are not automatically experts in your product strategy.

The outsourcing-the-solution mistake happens when a founder asks customers to design the product:

"What features should it have?"

"What would your dream tool do?"

"Should I build this integration?"

"Would it be better if it also had reports?"

Those questions can produce lively conversations. They can also produce a roadmap made of guesses, politeness, and local preferences.

Why feature requests are tempting

Feature requests feel concrete. A customer asking for dashboards, templates, AI summaries, or Slack integration sounds more useful than a customer describing a messy workflow.

But a feature request is usually a clue, not a requirement.

When a customer says, "It should integrate with Slack," they might mean:

• "I forget to check another dashboard."
• "My team ignores email."
• "Approval happens informally."
• "I do not have authority to introduce a new tool."
• "Slack is the only shared surface everyone uses."

The feature is the surface. The motivation is the evidence.

The better follow-up is "why?"

Do not reject feature requests. Translate them.

Customer:

"It would need a reporting dashboard."

Founder:

"What would you need the report to prove? Who would look at it?"

Customer:

"Can it integrate with Salesforce?"

Founder:

"What breaks today when this data is not in Salesforce?"

Customer:

"I would want AI recommendations."

Founder:

"What decision are you trying to make when you need a recommendation?"

Each follow-up moves from imagined solution to real job.

Customers can be wrong and still useful

There is a lazy version of this advice that says "customers do not know what they want." That is too dismissive. Customers often know what hurts. They often know what they tried. They often know what would be politically impossible. They can describe the moment when the current process breaks.

What they may not know is the best generalizable product solution.

A Hacker News thread on asking customers what they want includes a common product lesson: users may not understand the solution they need, and proving demand requires more than collecting stated wants. That does not make the customer irrelevant. It makes interpretation the founder's job.

The danger for AI-built products

Outsourcing the solution is even more tempting with AI app builders. If a customer asks for a feature, the founder can often build a rough version quickly. That speed can turn every request into a task.

Fast implementation is useful after you know the request represents a repeated, painful need. Before that, it creates product sprawl.

The better loop is:

1. Hear the feature request.
2. Ask what situation caused it.
3. Ask how often that situation happens.
4. Ask what they do today.
5. Ask what would happen if nothing changed.
6. Look for the same underlying need across multiple customers.
7. Then build the smallest product response.

How Vera trains this

In Vera, outsourcing the solution causes the AI customer to brainstorm. They may become helpfully speculative and list features. That feels like progress, but it does not reveal the hidden facts you need: past behavior, workaround, and payment history.

The founder's job is to pull the conversation back:

"Why would that matter?"

"What happened the last time you needed it?"

"How are you coping without it today?"

The customer owns the problem. The founder owns the synthesis. Mixing those up is how a discovery call turns into an accidental roadmap meeting.