How to Run Customer Discovery When You Don't Have a Product Yet

The Trap of the Imaginary Product

Most founders kill their startups before they write a single line of code. They do this by conducting "pre product customer discovery" that is actually just a thinly veiled pitch.

If you show a mockup to a VP of Engineering and ask, "Would you use this?", they will almost always say yes. They aren't being honest; they are being polite. They want to get off the Zoom call to finish their sprint planning.

Building on a "yes" from a polite person is how you end up with a high-churn product that solves a problem nobody actually cares about. To avoid this, you have to stop talking about your solution and start obsessing over the physics of the prospect’s current mess.

Validate the Budget, Not the Feature

In early-stage B2B, a "problem" isn't real unless it has a line item or a headcount attached to it.

If you're talking to a Director of RevOps about a new lead-scoring tool, don't ask if they like your UI. Ask what happened the last time their lead-to-opportunity conversion dropped by 10%.

• Who got yelled at?
• What manual spreadsheet did they build to fix it?
• How many hours a week does a $140k/year analyst spend cleaning that data?

If they can't point to a specific moment of pain or a specific dollar amount lost, they won't buy your product later. They might "test" it for free, but they won't sign a contract. Real discovery requires you to hunt for the friction that already costs them money.

The "Last Time" Rule

Human beings are terrible at predicting their own future behavior but decent at recalling their past.

Never ask: "How would you solve X?" Always ask: "Tell me about the last time you tried to solve X. What specific tool did you buy, or what workflow did you build?"

If you’re building a devtool for SOC2 compliance, ask a CTO at a Series B startup about their last audit. If they say, "It was fine, we just used a bunch of Google Docs," you don't have a product yet. You have a "nice-to-have" utility. If they say, "It cost us $40k in consultant fees and my Lead Architect was offline for three weeks," you have a business.

Stop Giving Away the Answer

When you describe your pre-product vision too early in a call, you bias the data. You convert a discovery session into a feedback session. Those are different things.

Discovery is about mapping the territory. Feedback is about grading your map.

If you find yourself saying "We're building a platform that...", shut up. You’ve just signaled to the interviewee what the "correct" answers are. Instead, use a platform like BuyerSignal to find verified professionals who are actually in the trenches. By paying for their time through a structured marketplace, you remove the "politeness bias." They are there to give you the honest, ugly truth about their tech stack, not to pat you on the back.

Four Questions That Actually Reveal Demand

If you haven't written code yet, your goal is to find out if the problem is a "Top 3" priority for your buyer. If it's priority number four or lower, it will never get funded. Use these:

1. "What is the current workaround for this problem, and who owns the manual labor involved?" If the answer is "no one," the problem isn't big enough.
2. "If you had the budget to fix this today, whose approval would you need to bypass?" This identifies the internal politics you'll face later.
3. "What else have you tried to fix this in the last six months?" If they haven't tried to fix it with existing tools, they won't try to fix it with yours.
4. "What happens if you do nothing about this for the next year?" If the answer is "nothing much," walk away.

The Contrarian View: Ignore "Feature Requests"

Pre-product founders often keep a spreadsheet of every feature a prospect mentions. This is a mistake.

Prospects are not product managers. They suggest features based on the limitations of the tools they already use. If you build everything they ask for, you’ll end up with a Frankenstein version of the incumbent software.

Instead of recording the feature request, record the trigger. Why did they think they needed that button? What were they trying to achieve 30 seconds before they felt that frustration? The trigger is the data point; the feature request is usually noise.

Moving From Discovery to Design

Once you have 15–20 conversations where the pain points overlap by 80%, you have enough data to build a prototype. Not a product—a prototype.

At this stage, your "pre product customer discovery" shifts. You go back to the people who felt the most pain and show them how you’ve mapped their specific workflow. If they don't immediately ask about pricing or a pilot, you haven't hit the nerve yet.

The goal is to find the "hair on fire" use case. A VP of Product might have a dozen "annoyances," but they only have one or two "career-ending risks." Find the risk.

Reliable discovery depends on talking to the right people without the friction of "fake" interest. BuyerSignal connects you with verified experts who provide the raw, unvarnished truth you need before you commit to a roadmap. Start your research on BuyerSignal today.