Three founders walk into a co-working space. Two of them are carrying a deck that says "billion-dollar TAM" and a competitor grid they built from other people's pitch decks. The third one has a spreadsheet with 34 names of potential customers and has already spoken to 21 of them. Guess which one survives the next twelve months.
Market research for a startup before launch is not a business school exercise. It is the difference between building something twenty people want right now and something a thousand people might want someday. And the single most common failure I see in early-stage teams is not a lack of research; it's research done wrong: too broad, too late, and built on questions that guarantee comfortable answers.
Here is how I actually do it, what it costs, and which parts of the classic playbook I think you should throw out.
Key takeaways
- Talk to 20 to 30 potential customers before writing a line of code. Fewer than that and you're pattern-matching on noise.
- Secondary research is a warm-up, not the main event. Public data tells you the shape of the market; only conversations tell you the shape of the pain.
- Pre-sales and waitlists are the only research signals that cost the respondent something. Treat them accordingly.
- The 80/20 rule in early-stage research means 80% of your useful insight comes from 20% of the questions—so build the interview around a handful of behavioural ones.
- Define your go/no-go thresholds before you collect data. Otherwise you'll rationalise whatever numbers land in the sheet.
How to conduct startup market research before launch
The short version: you run it in phases, in this order, and you refuse to skip to the fun part. Market shape first, then people, then price. Most founders start with the fourth or fifth step because it feels like progress.
Phase one: map the market from the desk
This is secondary research, and it should take you a week, not a month. You are not looking for a market size number to put on slide 4. You are looking for three things: who already sells here, what vocabulary customers use, and where the obvious cracks are.
Sources I actually use:
- Competitor pricing pages, and their changelogs—changelogs reveal what they keep fixing, which is where the pain lives
- Public regulatory filings, where they exist in your market, for real revenue and churn figures of listed or filing companies
- Review sites and app stores, sorted by lowest rating
- Job postings from your target buyers—the tasks they hire for tell you what tools they lack
- Community archives: forum threads where people describe a workaround they built themselves
That last one is gold. When someone has built a spreadsheet macro, a Notion template, or a manual process to solve a problem, they've already paid for your research for you.
Phase two: run the customer interviews
Twenty to thirty conversations, thirty minutes each, and none of them with people who love you. Friends and former colleagues will tell you your idea is brilliant because they like you. That is not data.
The interview structure that has worked best for me, in order:
- Ask about the last time they faced the problem. Not the problem in general—the most recent specific instance. "When did this last happen? Walk me through that day."
- Ask what they did about it. Specifically.
- Ask what it cost them: money, time, or a frustrated colleague.
- Ask if they've tried to fix it, and what they tried.
- Only at the end, describe what you're building and ask how it maps to what they just described.
That last ordering matters enormously. If you pitch first, every answer afterwards gets filtered through politeness. I learned this the hard way during an early project where I led with the demo and got eleven enthusiastic "yes, that's a great idea" responses that translated into precisely zero sign-ups.
Which brings up an obvious problem: founders hear what they want to hear.
Phase three: test willingness to pay
Opinions are cheap. Behaviour is expensive. Once you've done the interviews, put something concrete in front of the same people and see what they actually do.
- A pre-sale page with real pricing and a payment link. Even ten deposits at 50 currency units is a stronger signal than fifty survey responses.
- A waitlist with a filter. Make people answer a qualifying question to join. You'll lose half of them and learn which half actually cares.
- A concierge version: deliver the outcome manually to five customers for a reduced price. If you can't deliver it manually, you don't understand it well enough to automate it.
Set your thresholds beforehand. I use a rough rule of thumb: if fewer than 5% of the audience you deliberately targeted converts to a pre-sale or a qualified waitlist entry, that's a no-go signal for the current framing—not necessarily for the problem. If it's between 5% and 15%, you have a messaging problem. Above 15% against a small, well-targeted list, you have something worth building.
| Signal | What it costs the respondent | How much weight to give it |
|---|---|---|
| "Great idea, I'd use that" | Nothing | Almost none — polite agreement |
| Survey answer on a 1–10 scale | A minute | Low; good for framing, bad for commitment |
| Waitlist sign-up with email | Thirty seconds | Moderate; watch the drop-off after the first email |
| Qualified waitlist entry (answers questions) | Three minutes | Solid |
| Pre-sale deposit, real money | Money and trust | Very high; the closest thing to a launch you'll get early |
| Concierge customer who pays and uses the thing | Money, time, and workflow change | Highest — this is your real validation |
Real talk: I once ran a waitlist campaign that collected 240 email addresses in two weeks and converted exactly nine people when we launched. The landing page had promised a feature we hadn't specified, and the sign-ups came from a broad paid channel targeting the wrong persona. The list looked like validation. It was decoration.
How to do market research before launching a product
Product research is narrower than startup research, and that's precisely where it gets useful. You already have a market; now you need to find out whether this product earns a place in someone's workflow.
Map the existing alternative first
Every product has a competitor, even if that competitor is "a spreadsheet and a Monday morning phone call." Write down what your target user does today, step by step, including the ugly parts. Then ask: what breaks in that process most often?
If your product doesn't fix the break, you're competing on convenience. Convenience rarely justifies a purchase in a market where budgets are reviewed.
Test the message before the product
You can test positioning in a few days without building anything. Run two or three versions of a landing page with different headlines against small, targeted traffic, and watch which one gets more of the desired action—sign-up, demo request, whatever. What you're measuring isn't conversion at scale; it's whether your core claim lands.
The catch: traffic tests are noisy at small volumes. Treat them as directional. Six sign-ups across two variants tells you almost nothing; a clear difference after a few hundred visitors per variant starts to mean something.
Is it true that 90% of startups fail?
The "90%" figure gets repeated everywhere, and it's a rough approximation of long-run failure rates rather than a precise statistic. What's more useful than the exact number is the reason: the dominant cause of early failure is building something nobody wants—no market need—far more often than running out of money or being outcompeted.
The practical implication is straightforward. Your research should spend most of its effort on demand, not on the competitive landscape. Founders love mapping competitors because it feels safe. Demand is the thing that kills you.
What is the 80/20 rule for startups?
In a startup context, the rule means that a small share of the work produces most of the results. For research specifically it lands like this: roughly 80% of your decision-relevant insight comes from about 20% of your questions and conversations.
In practice, that means you should identify early which handful of things could actually change your plan. For most pre-launch teams it's four:
- Does the pain exist, frequently?
- Who feels it most acutely, and can you name twenty of them?
- Are they already spending money or time on a workaround?
- Will a meaningful share pay before the product exists?
Everything else—market size modelling, detailed competitor matrices, feature gap analysis—is supporting material. Useful, but not the 20%.
Doing this on a pre-seed budget (and with AI)
Hiring a research agency for a pre-launch study will run you a five-figure sum in most markets, and that money is usually better spent on engineering. The cheap version isn't worse—it's just slower, because you do the synthesis yourself.
Where AI actually helps
AI has changed secondary research substantially, and it's worth being specific about the split.
Good uses: summarising thirty competitor review pages into a list of recurring complaints; clustering open-ended survey answers by theme; turning interview transcripts into structured notes; drafting interview questions for you to rewrite; translating competitor documentation so you can read it in your language.
Bad uses: asking a model to estimate your market size, generate statistics, or tell you what customers want. It will produce confident numbers with no grounding. I've seen a generated market-size figure make it into a live pitch deck; the founder couldn't find its origin when an investor asked. That conversation ended the meeting.
Use it as a research assistant. Never as a source.
Free data worth digging into
- Public procurement portals, where they exist, show what buyers are already paying for adjacent services
- Trade association yearly summaries—often free, often containing the customer vocabulary you need
- Community archives going back years; search for phrases like "I wish there was" and "does anyone know a tool for"
- Your own network, used properly: ask for introductions to people who have the problem, never for opinions about your idea
Budget honestly: expect three to five weeks of part-time work for phases one through three, plus modest costs for a domain, a landing page tool, and a scheduling app. Money spent on paid participant incentives—a small voucher per interview—is usually the best-value line in the whole budget, because it lets you recruit people who don't owe you a favour.
What not to do (I've done most of these)
The list of research mistakes is longer than the list of methods, but a few of them account for most of the damage.
- Researching after the decision is made. If you're looking for confirmation, you'll find it. That's not research, it's a ritual.
- Interviewing only your own demographic. Convenient, and quietly fatal. Your twenty-something peers are not the buyer.
- Treating a competitor's funding round as proof of demand. It's proof that other people also believe in the market. That's different.
- Ending the process too early, at the first signal of encouragement. The interesting information tends to sit with the respondent who says "actually, we tried that and stopped."
- Skipping the write-up. If you don't produce one page of findings per phase, the insight evaporates within a fortnight.
And the process isn't finished when you launch. The most useful thing in this whole article is to keep a running log of every conversation for the first six months and re-read it every four weeks. The pattern that changes your roadmap is usually in there for weeks before you notice it.
Which is the uncomfortable part. Research doesn't tell you what to build. It removes some of the ways you'd otherwise be lying to yourself—and if it hasn't done that at least once, you probably haven't done it properly.