I was doing customer interviews wrong.

One of the easiest ways to “validate” a product idea is to describe it to customers and ask:

“Would this be useful?”

Some people will say yes.

Some people will say no—their existing process works.

And you may walk away believing you've either discovered product-market fit or should discard the idea altogether.

What you found isn’t necessarily the truth.

I've been talking to coaches while exploring the problem space for CoachOS. I made the same mistake of naming what I was building in the first few minutes of the 1:1 customer interview.

I didn't necessarily find the truth. I found some polite users who thought it sounded useful, and others who couldn't see what was wrong with their existing process.

A good customer interview is not about collecting opinions. It is about collecting evidence.

Instead of asking:

❌ “Do you struggle with X?”

Ask:

“Walk me through the last time you did X.”

And when they reveal something difficult:

“Tell me about the last time that happened.”

Instead of:

❌ “Would an AI tool that does Y be useful?”

Ask:

“How do you do Y today?”

Or, in my case:

“Walk me through your last coaching session—from how you prepared to what you did after it.”

Then keep digging.

“What happened?”

“How often does that happen?”

“What did you do about it?”

“How long did that take?”

“What happens if you don't solve it?”

“Have you tried anything else?”

“What are you paying for today?”

The conversation changes completely.

You move from:

I think I have this problem.

to:

This happened last Tuesday.

to:

It happens every week.

to:

Here's the spreadsheet/workaround I created.

to:

I'm already paying someone to help me solve it.

Those are very different levels of evidence.

1. Start with their world, not your product

One of my favourite questions is deceptively simple:

“Walk me through the last time you did this.”

Then reconstruct the workflow.

What happened before?

What happened during?

What happened afterwards?

What tools did they open?

Where did they switch systems?

Where did they wait?

What did they manually copy?

What did they forget?

Who else became involved?

Where did they create a workaround?

This is often where unmet needs hide.

Customers may never say:

“I need cross-session contextual intelligence.”

They might say:

“Before every meeting I spend 20 minutes going through my old notes because I can't remember what we discussed three months ago.”

The first is a product concept.

The second is customer evidence.

Your job as a product manager is to connect the two.

2. Workarounds

When someone has built:

a spreadsheet,

a Notion database,

a collection of prompts,

a WhatsApp process,

a manual checklist,

or hired another human to solve something...

pay attention.

The customer is effectively saying:

“This problem matters enough that I built my own product.”

An ugly workaround can be a stronger signal than an enthusiastic response to your prototype.

3. Follow the money

Asking:

“Would you pay Rs. X/month for this?”

produces hypothetical data.

Asking:

“What are you paying for today to solve this?”

produces behavioral data.

Maybe they pay for software.

Maybe they hired a consultant.

Maybe they bought a course.

Maybe they employ an assistant.

Maybe they spend five hours every Friday doing it manually.

All of those reveal the economic value of the problem.

Past behavior is usually more useful than hypothetical willingness to pay.

4. Don't introduce the solution too early

This is hard—especially when you're excited about what you're building. I know I was.

But if you introduce your solution at the beginning, the rest of the interview becomes contaminated by it.

Instead:

Context → actual behavior → problems → workarounds → consequences → priority → economics → solution

Only toward the end should you test the concept.

And even then, don't ask:

“Do you like it?”

Ask:

“What would you do next if this existed?”

That moves the conversation back toward behavior.

5. Force prioritization

Customers have many problems.

Your job isn't to create a backlog containing all of them.

Near the end of an interview, summarize the problems they mentioned:

“You've talked about A, B, C and D. If you could eliminate only one tomorrow, which would you choose?”

Then ask:

“Why?”

And one question I particularly like:

“Which of these would you never pay to solve?”

Prioritization creates information that “How important is this from 1–10?” rarely does.

6. Look for disconfirmation

This might be the most important part. And probably the hardest.

Once you've spent time thinking about a product, it's surprisingly difficult to separate yourself from how awesome you think the idea is.

But finding evidence that your idea isn't needed can be more valuable than finding evidence that it is.

What would have to be true for me to abandon this hypothesis?

If you're testing whether people struggle with a particular workflow, actively search for customers who say:

“This isn't a problem.”

Then understand why.

Maybe their workflow is different.

Maybe another tool already solves it.

Maybe the problem exists only for beginners.

Maybe it exists only at scale.

Maybe the customer experiences it but simply doesn't care enough to fix it.

Contradictory evidence isn't bad research.

It's the point of research.

The hierarchy of customer evidence

I increasingly think of interview evidence roughly like this:

“That sounds useful.” ↓

“Yes, I have that problem.” ↓

“It happened recently.” ↓

“It happens repeatedly.” ↓

“There are meaningful consequences.” ↓

“I've created a workaround.” ↓

“I've tried multiple solutions.” ↓

“I'm already spending meaningful time or money solving it.”

The further down you get, the more interesting the problem becomes.

Not every pain deserves a product.

Customer discovery isn't about asking customers what to build.

The irony is that I'm doing these interviews to figure out what CoachOS should become. The more useful interviews have been the ones where I stopped trying to validate CoachOS.

It's about understanding their world well enough that you can make a better decision about what not to build—and recognize the few problems that may genuinely be worth solving.

That's a very different kind of validation.