Market Research Methods for Pre-MVP Startup Ideas

That's the whole point of pre-MVP research. It's stress-testing the assumptions holding up your idea before an engineer writes function one, work that's easy to skip and expensive to skip badly. And it works best as a sequence, not a grab bag: broad signal first, specific evidence last. Here's that sequence, in order.

Starting with secondary research to map the terrain before talking to anyone

Secondary research just means using stuff that already exists, industry reports, competitor filings, academic papers, forum threads, instead of generating new data yourself. It comes first because it's cheap, it's fast, and it hands you the vocabulary and categories you'll need before you can ask a good question in an interview.

Where to actually look:

• Analyst firms like Gartner, Forrester, and Statista for market sizing and trend lines
• Reddit threads, niche Slack groups, and Product Hunt comment sections, where people describe their problems in their own words, not marketing language
• Review sites like G2, Capterra, and Trustpilot, where complaints about existing tools point straight at unmet needs
• Job postings, which tell you where companies are putting money and what internal pain they're trying to solve
• App store reviews, a quick and dirty read on what's missing from what already exists

Here's the limit, though: secondary research tells you the shape of the forest. It cannot tell you whether one specific person in that forest will hand you money. Founders trip over this constantly, pulling a market-size number from a Statista report and treating it like validation. A big market and a market that wants your product are two completely different claims. That gap is exactly why you talk to actual humans next.

How to run customer discovery interviews that surface real signal

The mindset shift here matters more than any script: you're trying to understand a problem the person already has, on their own terms, before you've decided what to build. Pitching or testing a solution too early just teaches you what people are willing to say to be polite.

The Jobs-to-be-Done question is the cleanest way to stay on track: what job is this person hiring a solution to do? That framing keeps you asking about context and workarounds instead of drifting into "would you use a feature that does X."

On volume: six to twelve interviews per customer segment usually gets you to thematic saturation, meaning you start hearing the same things repeat. A narrower problem space can get you there faster. Think of that number as a floor, not a finish line; ten to fifteen in-depth conversations per segment is a solid target before you move into anything quantitative.

A few design rules worth following closely. Ask about the last time something happened, not whether they'd hypothetically use a future product ("Tell me about the last time you dealt with X," never "Would you use a product that..."). Chase the workaround, because what someone does today to cope with a problem is the most honest evidence of how much it actually hurts. And write down their exact words. Those phrases become your ad copy, your search terms, your positioning, later.

For finding people to talk to: start with your own network, move to LinkedIn outreach, then dip into the communities where your target persona already spends time. Offer a casual 20-minute call rather than a formal "user study," which scares people off. And watch for what kills signal: leading questions, asking about willingness to pay before you've even nailed down the problem, and recruiting too heavily from friends who'll just tell you what you want to hear.

What you walk away with is a map of real problems, ranked by how often they come up and how much they seem to sting. That ranking is what tells you what to put in a survey.

Using surveys to turn qualitative patterns into measurable evidence

Surveys come after interviews for a simple reason: interviews tell you what to ask, surveys tell you how common it is. Reverse the order and you're measuring things you made up.

Keep the survey narrow. One core question set: what's the problem, how often does it show up, what do people do about it today. Anything longer than five minutes and completion rates fall off fast, so trim ruthlessly. Lean on closed questions, multiple choice, Likert scales, for the numbers, and save one or two open fields for language you might've missed in the interviews.

Pricing deserves its own approach. Asking "how much would you pay for this?" produces garbage data; people are terrible at pricing hypothetical products. The Van Westendorp Price Sensitivity Meter gets around this with four questions that map out a range of acceptable pricing instead of chasing one number. Conjoint questions do something similar by forcing trade-offs between feature bundles and price, which mirrors how people actually decide, rather than how they imagine they'd decide.

Distribute through the same communities secondary research already pointed you toward. Panels like Prolific or UserTesting work when you need speed. LinkedIn covers B2B personas well.

One hard limit to keep in mind: a survey cannot simulate a purchase. Somebody checking a box that says they'd pay a certain amount is not the same event as somebody typing in a credit card number. That gap is real, and it's exactly what the next stage is built to close. What you walk away with here is frequency data on the core problem and a defensible price range, both of which feed directly into positioning and MVP scope.

Behavioral tests that reveal willingness to pay before any product exists

Here's the principle underneath everything in this section: what people do with their attention, their time, and their money tells you more than what they say on a survey. Always has.

Landing page smoke test. Build one simple page describing the core value of the thing you want to build. No product behind it, none. Drive a small amount of targeted traffic, paid ads on Google, Meta, or LinkedIn depending on your persona, or posts in relevant communities. Measure sign-ups, email captures, waitlist clicks. A strong response tells you there's interest. It does not tell you there's purchase intent, that's a different question, answered by adding friction, which is what the next two tests do.

Concierge MVP. You deliver the core value by hand, to a handful of real users, with zero automation behind the curtain. Airbnb's founders famously photographed early listings themselves and stayed with hosts to figure out what was breaking. The "product" was their own labor, full stop. This reveals what surveys can't: operational headaches, what people actually value in the moment of use, and whether they come back for more.

Wizard of Oz MVP. The user sees what looks like an automated system. Behind the scenes, your team is doing everything manually. Zappos started this way: Nick Swinmurn photographed shoes sitting on shelves in local stores, posted them online, and when someone ordered, he bought the shoes himself and shipped them. Zero e-commerce infrastructure, real demand data. This approach works best when the automation would be expensive to build and you can substitute human sweat for a while instead.

Pre-order or paid pilot. This is the highest-friction test there is, and that's exactly why it's the most honest one. Asking someone for money before you've built anything cuts through every polite survey answer you've ever collected. A handful of actual paid commitments beats hundreds of "yes, I'd probably buy that" responses, no contest.

Across every one of these, you're measuring whether someone cares enough to act, not whether they'd merely use the thing. That's the entire distinction, and it's the one that matters.

Competitive analysis as a check on positioning, not a reason to stop

A market full of competitors is a market that's already proven demand exists. So drop the question "does competition exist?" It's the wrong question. Ask instead where the gap is that nobody's filled yet.

What to actually map: direct competitors solving your exact problem (how they price, what their customers gripe about in reviews), indirect competitors like the spreadsheets and manual processes people cobble together as workarounds (often your real competition), and adjacent players solving a related problem for the same type of customer, which tells you the customer is real and has budget to spend.

Pull this from review platforms, competitor job listings (which show where they're investing), their landing page copy (which shows how they frame the problem), and, again, the actual words their customers use in reviews.

What you're after is a positioning gap, a specific combination of segment, problem framing, and value proposition nobody else is nailing. Avoid the trap of building a feature comparison spreadsheet and deciding you need to match every row on it. That's how first releases turn into bloated messes nobody asked for. The gap you find here is what your MVP needs to prove, not the full list of things it needs to solve.

Deciding what the research is actually telling you to build first

By now you've run secondary research, interviews, surveys, and behavioral tests, and mapped the competition. What you should have is a ranked list of assumptions, ordered by how much your business depends on each one being true.

Start with the riskiest one: the assumption that kills the whole idea if it turns out false, regardless of how fun or easy it would be to build something else first.

The Jobs-to-be-Done lens sorts features into three buckets. Essential features directly complete the job the customer hired you for. Supporting features make that job faster or easier. Nice-to-have features add polish but don't change whether the job actually gets done. Your MVP lives entirely in that first bucket. Everything else waits.

In practice, the lean validation stack looks like this: a short survey, ten to fifteen interviews, and a landing page test. That combination answers most of what you need to know before building, without turning research into a six-month side project of its own.

Watch for a specific red flag: if your interview themes, survey numbers, and behavioral test results point in different directions, your segment probably isn't as uniform as you assumed. Narrow it before you build, not after.

"Done" looks like a one-page document. Top three assumptions, evidence for and against each, and a plain statement of what the MVP is meant to prove. That page should exist before any engineering does.

Where structured learning resources and community can accelerate the process

Knowing these methods on paper is one thing. Having a repeatable process, some accountability, and peers doing the same grind at the same time is another thing entirely, and it's usually the piece founders are missing.

YC's Startup School fills that gap directly. It's a free, self-paced curriculum taught by YC partners and operators who've run this playbook with hundreds of companies. The content stays concrete: building an MVP, getting your first users, launching, raising money. There's a weekly progress-tracking tool built in too, which does more for accountability than any amount of good intentions.

There's also a co-founder matching platform inside it that has facilitated a large number of matches. That matters more than it sounds like it should. CB Insights' same 2024 analysis found the wrong team makeup showed up in 23% of startup post-mortems, meaning a co-founder gap is its own risk, one that structured matching can chip away at before you've written a single line of code.

The underlying idea is straightforward: solid startup education should be free and open to anyone, anywhere. The same discipline that helped Airbnb, Stripe, and DoorDash validate their early ideas is available now without an MBA or a warm introduction to an accelerator.

Pre-MVP research decides whether anything built after it is worth doing at all, which is what makes it real work rather than a box to check before the "real" work begins.