Research-Driven Customer Discovery

I spent six months building a feature customers asked for, shipped it etc.. Usage was 8%. Turns out what customers said they wanted and what they actually needed were completely different things. Surprise, huh?

Welcome to customer discovery: where asking the wrong questions gives you confidently wrong answers.

Why Most Customer Discovery Fails

We did everything right. Talked to 20+ customers. Asked what they needed. Built a roadmap based on feedback. Shipped features. Customers were happy we listened. Nobody used the features.

The problem: we asked “what do you want?” when we should have asked “what problem are you trying to solve?”

Customers are excellent at describing their problems. They’re terrible at prescribing solutions. When you ask “what features do you want,” you get a shopping list. When you ask “what’s frustrating about your current workflow,” you get insights.

Understanding the Fundamentals

What Customer Discovery Actually Is

Most teams think customer discovery means talking to customers. Wrong. Customer discovery is forming hypotheses about customer problems, testing those hypotheses through research, and updating your beliefs based on evidence.

The framework:

1. Form a hypothesis about a customer problem
2. Design research to test that hypothesis
3. Run the research
4. Analyse what you learned
5. Update your hypothesis or move to solution exploration

Why This Matters for PMs

Product managers live in a bubble. We talk to power users, read support tickets, attend industry conferences. Then we build products for a market we barely understand.

I’ve made this mistake repeatedly. Built features for problems I assumed existed. Prioritised based on what seemed obviously important. Ignored signals that contradicted my beliefs.

The antidote is systematic customer discovery. Not occasional research. Continuous learning that informs every product decision.

Common Pitfalls and How to Avoid Them

Mistake One: Confirmation Bias in Interview Questions

Classic trap: ask questions that confirm what you want to hear.

“Don’t you find project estimation frustrating?” versus “How do you currently estimate projects?”

First question leads the witness. Second question is neutral. The answers you get are completely different.

Mistake Two: Only Talking to Friendly Customers

Your happiest customers are not representative. They’re outliers who love your product despite its flaws.

We spent months interviewing customers with 90+ NPS scores. Got glowing feedback about features. Built more of what they wanted. Churn stayed high because we were optimising for the 20% who already loved us, ignoring the 80% who churned.

Then we started talking to churned customers and detractors - and learned completely different things. The happy customers tolerated clunky workflows because they valued our core differentiator. Churned customers left because those workflows were dealbreakers.

Who to talk to:

• Recent signups (before they’ve formed strong opinions)
• Churned customers (brutally honest feedback)
• Customers who use competitor products alongside yours
• Non-customers in your target market

Friendly customers are dessert. Detractors are vegetables. You need both.

Mistake Three: Research Theater

Doing research to check a box versus doing research to learn. Research theater looks like customer discovery. It generates artifacts that feel rigorous. But nobody’s beliefs actually change.

Real discovery is uncomfortable. You learn things that invalidate your roadmap. You discover your assumptions were wrong. You have to throw away work.

At one company, we spent three months building a reporting dashboard. Week before launch, did customer interviews for “feedback.” Customers were polite. Nobody got excited. Realized we’d built something nobody asked for based on our assumptions.

A Practical Framework

Step One: Define What You’re Trying to Learn

Not “talk to customers.” Something specific.

Good research questions:

• How do you run daily stand-ups?
• What triggers the decision to look for a tool like ours?
• Why do customers churn in months 3-6?
• How do enterprise buyers evaluate security features?

Bad research questions:

• What do customers think about our product?
• What features do they want?
• How can we improve?

The first set has clear success criteria. You’ll know if you learned something. The second set generates endless feedback without insights.

Step Two: Choose Your Research Method

Different questions need different methods.

Problem discovery: Contextual inquiry, diary studies, shadowing. Watch people work. Understand their actual workflow, not their idealized description.

Solution validation: Prototype testing, fake door tests, concierge MVP. Don’t ask if they’d use it. Show them something concrete and see if they actually use it.

Market sizing: Surveys, analytics, public data. Need quantitative data to understand how common a problem is.

Step Three: Actually Do The Research (Stop Planning, Start Learning)

Most teams spend weeks planning perfect research. Then something urgent comes up and research never happens. Better approach is: rough research fast beats perfect research never.

Your future weekly discovery rhythm:

• Monday: Identify this week’s research question
• Tuesday-Thursday: Schedule and run 5 conversations
• Friday: Synthesize findings, share with team

Not perfect. But you’ll learn every week instead of planning quarterly research projects that never happened.

Key Takeaways

Let’s make this concrete:

• Form hypotheses, then test them - Customer discovery is science, not surveys. Start with clear beliefs you want to validate or invalidate.
• Ask about problems, not solutions - Customers know their pain. They don’t know the cure. “What’s frustrating?” beats “What features do you want?”
• Talk to detractors and churned customers - Happy customers are outliers. Learn from people who left or almost left.
• Watch behavior, not just words - Contextual inquiry and observation reveal truth. What people do matters more than what they say.
• Make discovery continuous, not episodic - Weekly conversations, not quarterly research projects. Small consistent learning beats big occasional studies.
• Don’t do research theater - If the research won’t change your plans, don’t do it. Real discovery means being willing to kill work based on what you learn.

Final Thoughts

Customer discovery feels inefficient. It takes time away from building. It generates uncertainty. It forces you to question your convictions.

All of this is the point.

The teams that do discovery well ship fewer features. But the features they ship actually solve real problems. Their roadmaps adapt based on learning. They pivot before spending six months building the wrong thing.

Start this week: pick one assumption you’re making about customers. Turn it into a hypothesis. Talk to five people to test it. Actually listen to what they tell you, even if it contradicts what you wanted to hear.

Customer discovery isn’t about validating your roadmap. It’s about building products people actually need.

Have questions or thoughts? Get in touch - I’d love to hear from you!