Most founders treat market research like homework, something you do to feel responsible before you build the thing you already decided to build.
I know because I did it too.
When I started building Noder, I was my own customer. I'd been learning mostly through YouTube. Great content, but brutally slow and completely fragmented. One video here, another there, no thread connecting any of it. I wanted something more linear: a way to find connected resources, follow a progression, and actually feel like I was moving forward rather than just consuming.
So I assumed I understood the problem. It was a content discovery problem. An organization problem. I needed to build something that took all this scattered information and made it linear.
It took conversations with other learners to realize I was solving the wrong thing entirely. The problem wasn't that learning resources were disorganized. The problem was that they were being delivered by the wrong people. When you learn from a genuine expert, someone 10 years ahead of you, the gap is too wide. Their explanations are technically accurate but contextually useless. You can't attach what they're saying to anything you already know.
The person who can actually teach you is the one who's just a level above you. They remember what it felt like not to understand. They know which parts are confusing because they were confused by them recently. Their explanations might not be perfectly precise, but you get it. And getting it, even imprecisely, is how learning actually works.
That was the real problem. Not organization. Not discovery. The gap between the teacher and the learner.
That experience taught me that real market research isn't about confirming your idea. It's about stress-testing it until only the true parts survive. Here's how I actually do it now.
01 Start With a Falsifiable Hypothesis, Not a Question
Most founders go into research asking "is there a market for this?" That's the wrong question; it's too easy to answer yes.
Instead, write down the one thing that has to be true for your startup to work. Not a vague hope, but a specific, falsifiable claim.
Your research should be trying to kill that hypothesis. If it survives, you've learned something real.
02 MECE is your Best Friend
McKinsey uses a framework called MECE, which stands for Mutually Exclusive, Collectively Exhaustive, for breaking down complex problems. It sounds like consultant jargon, but it's one of the most practical tools a founder can use before going into the market.
Here's what it means: every assumption behind your hypothesis should be separated into buckets that don't overlap (mutually exclusive) and together cover the full problem (collectively exhaustive). The point is to make sure you're not testing the same thing twice under different names, and not leaving blind spots you haven't thought to check.
In practice, this means taking your hypothesis and listing every assumption baked into it, then checking that those assumptions are clean and complete.
Using the Noder example: my original hypothesis was that learners need better-organized content. The assumptions underneath that were:
- Learners can't find good content (discovery problem)
- Learners can find content but can't sequence it (organization problem)
- Learners can find and sequence content but can't retain it (comprehension problem)
- Learners can find and understand content but lack accountability (motivation problem)
MECE forces you to split these cleanly, because if you conflate discovery with organization, you'll design research that confirms both even when only one is true. And if you don't list comprehension and motivation as distinct buckets, you might solve the wrong layer entirely.
When I ran this for Noder, I realized my research had only been testing buckets 1 and 2. Bucket 3 (comprehension) was where the real problem lived, and it was a completely different root cause: not bad content, but content delivered by people too far ahead of the learner to be useful.
Before you talk to anyone, MECE your hypothesis. List every assumption, make sure they don't bleed into each other, and make sure together they cover the full problem space. Then go test each one independently. You'll come back with signal, not noise.
03 Talk to People Before You Touch Secondary Research
The instinct is to start with Google, industry reports, and TAM calculations. Resist it.
Secondary research tells you what the market looked like when someone else studied it. Customer conversations tell you what's true right now, in the words your future users actually use.
Here's the rule I follow: no reports until I've done 15 conversations.
For those conversations, the goal isn't to pitch; it's to understand the shape of the problem.
But here's the mistake almost every founder makes: they ask customers to diagnose themselves. "What's your biggest pain point?" "What problem are you trying to solve?" Those questions feel useful. They're not. Customers are terrible at naming their own problems; they'll tell you what they think sounds reasonable, or what they've already rationalized, not what's actually making their life harder.
Instead, ask questions that make the problem visible, questions that put them in the moment rather than in their head:
- "Walk me through the last time this came up. What actually happened?"
- "What did you do about it, step by step?"
- "How long did that take? How often does it happen?"
- "What have you already tried? Why didn't it stick?"
You're not asking them what's wrong. You're watching them describe what they do, and finding the friction yourself. The pattern you're hunting for isn't in their words; it's in the gap between how they describe things working and how they actually work. When five different people describe the same workaround, the same moment of frustration, the same exact step where things fall apart, that's your signal. You found the problem. They never had to name it.
04 Find the Customers Who Are Already Solving It Badly
The best signal you can find in early research isn't someone who says "I love this idea." It's someone who has already built a janky workaround: a spreadsheet, a Zapier hack, a process that takes way too long.
Those people have revealed their pain. They've put effort into solving something. They're your earliest adopters, and they'll tell you more in one conversation than ten enthusiastic early responses ever will.
When I was talking to learners while building Noder, almost everyone I spoke to had the same workaround: they'd find a YouTube video on a topic, then spend 20 minutes in the comments trying to find someone who'd explained it differently. They weren't looking for better content; they were looking for a different angle. Someone who framed it in a way that clicked.
That's not a content problem. That's a proximity problem. They needed someone closer to their level, not someone better at the subject. The workaround told me everything, and none of them would have named it as the problem if I'd asked directly.
05 Use NotebookLM to Think Through What You've Gathered
Once you've run a handful of conversations, you're sitting on raw material: messy notes, half-formed observations, quotes that feel important but you can't yet explain why. This is where most founders lose momentum. They either overthink it alone or skip synthesis entirely and jump to building.
NotebookLM changes this. It's a Google tool that lets you upload your research sources (interview notes, transcripts, competitor teardowns, industry reports) and then have a real conversation with that material. Not a search, a conversation. You can ask it "what's the common thread across these interviews?" or "where do people seem most frustrated?" and it reasons across everything you've fed it.
The goal isn't to outsource your thinking. It's to compress the pattern-recognition step that would otherwise take days of re-reading and sticky notes. When you can see the themes clearly, you stop fooling yourself about what you heard.
06 Use Secondary Research to Sharpen, Not to Justify
Once you've done the conversations, secondary research becomes genuinely useful. You're no longer looking for permission; you're looking for structure.
At this stage I look for three things:
Market size signals. Not to calculate a TAM slide for investors, but to understand whether the market is growing or shrinking, and why. A growing market hides a lot of mistakes. A shrinking one punishes them.
Competitive landscape. Who's already solving this, at what price point, and for which customer segment? If there's no competition, that's not a good sign; it usually means the pain isn't that sharp. If there's a dominant player, figure out who they're ignoring.
Regulatory and structural constraints. These kill startups quietly. Know what compliance, procurement cycles, or switching costs you're building into.
07 Validate Demand Before You Validate the Product
Founders conflate these two. You can have massive demand for a problem category and still build the wrong product. They're separate bets.
To validate demand, you need some version of someone paying, or committing to pay, before the thing exists. That looks different by market:
- A waitlist with a deposit
- A letter of intent from a design partner
- A pre-sale or presale cohort
- A paid pilot with a defined scope and timeline
If you can't get any of these, it doesn't mean your idea is bad. It means you haven't found the right framing yet, or you haven't found the right customer yet. Both of those are things market research can fix.
08 The Signal That Tells You You're Done
You'll know your market research is working when you stop getting surprised. When you talk to your eighth potential customer and they say the exact same thing the third one said, in almost the same words, you've found a real pattern.
That pattern is the foundation of everything: your positioning, your ICP, your first feature set, your go-to-market motion.
For Noder, the pattern showed up after maybe eight or nine conversations. Every single person described the same frustration in different words: they could find information, but it never quite landed the way they needed it to. Too advanced, too abstract, too detached from where they actually were.
What they needed wasn't better content. They needed a teacher who remembered being where they are now. That became the core of what we built: not a learning platform, but a proximity network. And I would never have found it if I'd trusted my original assumption.
Research doesn't end there. But it changes character, from exploration to validation. And that's when building gets a lot less scary.
The uncomfortable truth about market research is that it's not a phase you complete. It's a habit you build. The founders who stay closest to their customers always know something their competitors don't.