Plan a first round of customer discovery before building. Timelines and the evidence needed depend on your market and the risks you are testing.
Before building, make two assumptions explicit: who has the problem, and whether they will pay to solve it. Interviews, observed workflows and purchase outcomes provide different kinds of evidence. No single generated report establishes demand.
Most startup validation guides tell you to "talk to customers" or "run surveys." That's not wrong, but it's incomplete. People lie on surveys. They overstate their interest. They say they'll buy when they won't.
A survey might show 80% of respondents would "definitely buy" your $49/month tool. You build it. Launch day: 6 people actually pay. That's not validation, that's false confidence.
Don't pitch your product. Don't ask "Would you use a tool that does X?" Instead, focus on their current reality.
As an initial research plan, you might interview 15–20 relevant people. That is a planning suggestion, not a representative sample or a pass/fail threshold for product-market fit. Record selection bias and contradictory evidence.
Here's the test most founders skip: Are people already trying to solve this problem right now? If nobody is paying for alternatives, using hacky workarounds, or actively searching for solutions, the pain isn't real enough. You want customers who are "on fire" with the problem, not ones you need to convince have a problem.
If the problem is real, people are already trying to solve it. Your job is to build something 10x better than their current workaround, not to create a market from scratch.
Interest means nothing. You need to test if people will actually pay. Here's how to do it without building anything.
Build a landing page that clearly states the product is not yet available. Show proposed pricing and an honest waitlist or pilot invitation. Explain what you will do with submitted information and collect it with appropriate consent.
Track two numbers:
Interpret rates with their sample size, traffic source and uncertainty. Define decision criteria before the test. A signup rate alone cannot diagnose positioning or establish product-market fit.
Rob Fitzpatrick's book "The Mom Test" has one core insight: you can't trust people's opinions about your product, but you can trust their behavior and past actions.
Your friends will lie to you. They want you to succeed, so they'll say your idea is great even if they'd never use it. Talk to strangers in your target market instead. Join industry Slack groups, Reddit communities, or LinkedIn groups. Offer to buy them coffee for 30 minutes of their time.
If possible, build something you personally need. You immediately know if your solution works. You don't need to schedule user interviews. You ARE the user. Many successful startups (Dropbox, Stripe, Reddit, Airbnb) started this way. If you're building for others, every feature decision requires research. It's 10x harder. Not impossible, but harder.
Launch in weeks, not months. Your first version should be embarrassingly simple. Most founders spend 6 months building features nobody asked for. Launch with the minimum feature set, then let real users tell you what to build next. If you're not a little embarrassed by your first version, you probably launched too late.
A landing page or prototype can test some assumptions before a larger build. Signups are not paid demand, and a fixed signup threshold does not determine whether a product can succeed.
Stated interest can differ from actual behavior. Surveys can still provide useful evidence when sampling, question wording and limitations are clear; do not treat responses as guaranteed purchases.
Instead of asking "Would you buy this?", track revealed preferences: What are they currently paying for? What workarounds have they built? What competitors are they using?
In the early days, do everything manually. Don't build automation. Don't worry about scale. Focus 100% on making a few users ridiculously happy. This is counterintuitive but essential for validation.
The pattern: manual work proves the concept. Once you know people will pay, then you build the automation.
Consider a small, explicitly described concierge pilot. Payment for a manual service is useful evidence, but does not prove customers will pay for a different automated product.
Label a proposed feature as not yet available and invite interest. Record clicks and sample limitations without misleading users about availability. Low response can have many explanations.
Find 3-5 competitors. Check their pricing pages, read their customer reviews, join their communities. If customers are complaining about specific gaps, that's your opportunity.
Search Reddit for your problem area. Read 50+ posts. Are people actively asking for solutions? Complaining about existing tools? Sharing DIY workarounds? That's validation.
BuyerIQ can organize audience and pricing hypotheses from product context. Scores are heuristic compatibility scores, not purchase probabilities. Generation time varies; the output is not a validation test or a substitute for customer evidence.
The single most important validation habit: talk to users weekly. Not just early on. Forever. Most founders stop doing user interviews after they have 100 customers. That's exactly when you should double down on them.
Start with the smallest viable market. Find 10-100 people who desperately need your product. Make them love it. Then expand. This is counterintuitive but essential.
Bad approach: "We're targeting all e-commerce businesses."
Better approach: "We're targeting Shopify stores doing $100K-$1M annually selling physical products to consumers, run by solo founders who hate dealing with returns."
A narrower scope makes it easier to recruit relevant people and describe what your evidence covers. Verify that the proposed channels reach those people, and do not generalize a small sample to the entire market.
Useful signals to investigate—not universal validation thresholds—include:
Decide what evidence would justify the next investment and what would change your mind. Keep user-reported observations separate from assumptions and generated hypotheses. In BuyerIQ, field evidence can inform new immutable company versions; prior reports remain a record, not proof of accuracy.
BuyerIQ generates market hypotheses and field-validation plans. No product-specific predictive accuracy benchmark is published; real calibration requires representative, consented outcomes and remains future work.
Plan Your Customer Research →