A Simple Product Discovery Framework for Early-Stage Founders
Most product discovery frameworks are designed for product managers at established companies. They involve sprint cycles, research repositories, and cross-functional alignment meetings.
That's not what early-stage founders need.
Before you have a team, a roadmap, or a product, you need to answer one question: is this worth building at all? That requires a different kind of framework — one built for speed, honesty, and zero assumptions.
This is the framework we built Scoutr around.
Want to run through this framework right now? Start your discovery process →
The Core Principle
Most founders fail not because they can't build, but because they build the wrong thing. They have an idea, they fall in love with the solution, and they spend months constructing something the market doesn't need.
The antidote is simple but uncomfortable: delay building as long as possible, and spend that time gathering evidence.
Evidence, not opinions. Evidence means behavior — what people currently do, what they currently pay, what they currently tolerate. Opinions ("I'd use that," "sounds cool") are not evidence.
The Six-Question Discovery Framework
This framework draws from three sources: Rob Fitzpatrick's The Mom Test, YC's advice to founders in the earliest stage, and Eric Ries's The Lean Startup. It's structured as six questions because that's the minimum needed to get a complete picture without overwhelming yourself with research.
Question 1: Who specifically has this problem?
Not "small businesses." Not "busy professionals." One specific person: their job title, their company size, their daily context, and why this problem comes up for them specifically.
If you can't describe one real person who has this problem, you don't have a target user — you have a hypothesis. Start there.
What you're looking for: A specific, reachable person whose situation you understand well enough to find them and talk to them.
Question 2: How are they solving it today?
This is the most important question in the framework. If the problem is real and painful, people are already doing something about it. They have a workaround. They're paying for an imperfect solution. They're doing something manual they hate.
Those workarounds are evidence of demand. They tell you that:
- The problem is real (they're motivated enough to work around it)
- There's a market (they're already spending time or money)
- There's an opening (the current solution isn't good enough)
What you're looking for: Active workarounds — especially ones that cost money or time. The more painful the workaround, the stronger the signal.
Question 3: Have you talked to someone with this problem?
Not: "would someone have this problem?" Have you actually had a conversation with a real person who experiences it? Did they describe it without prompting? Did they use emotional language?
This question exists to force the distinction between assumption and evidence. Most founders are operating on assumptions until they have real conversations.
What you're looking for: At least five conversations where the problem came up unprompted, described in specific, emotional terms. Patterns across multiple conversations are meaningful. Individual anecdotes are not.
Question 4: Is anyone already paying to solve this?
Money is the hardest signal to fake. If people are currently paying — for a competitor, for manual labor, for a workaround — you know the problem is worth paying to solve. The question becomes whether you can solve it better.
If nobody is currently paying anything to address this problem, ask why. Sometimes it's because the problem isn't painful enough. Sometimes it's because no solution exists yet. Those are very different situations.
What you're looking for: Evidence of current spend — subscriptions, contractor costs, internal tools — in your target segment.
Question 5: What would they do if your solution disappeared?
This is a future-tense version of the workaround question, but asked differently. If your product stopped existing tomorrow, what would your target user do?
If the answer is "nothing" or "I guess I'd go back to doing it manually," that's a signal the problem isn't acute enough. If the answer is "I'd have to hire someone," "our whole process would break," or "I'd look for an alternative immediately," that tells you something different.
What you're looking for: Evidence that the problem creates urgency — that the user is worse off without a solution and knows it.
Question 6: Why are you the right person to solve this?
This isn't a confidence question. It's a distribution and insight question. Do you understand something about this problem that others don't? Do you have access to users that others don't? Is there a reason you'd be better at solving this than someone who just saw the same opportunity?
Unfair advantages in early-stage startups usually come from domain expertise, distribution, or unique insight into the problem. If you don't have one of these, that doesn't mean you shouldn't build — but it's a relevant thing to understand about your position.
What you're looking for: A specific answer, not a generic one. "I've worked in this space for five years" is a start. "I know the 50 people who have this problem and they already trust me" is stronger.
How to Use This Framework
The six questions work best when answered honestly — not with the answers you wish were true, but with the evidence you actually have.
Run through the framework twice:
First pass: Answer each question with what you currently know. Mark every answer where you're speculating rather than reporting evidence. Those are your research priorities.
Second pass: After two weeks of interviews, community research, and competitor analysis, run through the framework again. The gaps should be smaller. If they're not, that's useful information too.
Scoutr runs you through this framework as a conversation — asking follow-up questions, challenging weak answers, and producing a structured report at the end. The report covers all six areas, plus competitive signals, market sizing, and recommended next steps.
What This Framework Is Not
It's not a substitute for building. At some point, you have to ship something and see how real users interact with it. The framework exists to make sure you're building the right thing — not to give you infinite reasons to delay.
It's not a guarantee. You can answer all six questions well and still build something that doesn't work. Markets are uncertain. The framework reduces risk; it doesn't eliminate it.
It's not a one-time thing. Discovery continues after you launch. The questions change, but the discipline of asking them doesn't.
The Single Most Common Mistake
Founders who run through this framework for the first time often discover that they can't answer Question 3. They've never actually talked to someone with the problem.
That's the single most common failure mode in early-stage product development: building on assumptions without ever testing them in conversation.
If you're at that point — you have an idea, but you haven't talked to real users yet — that's exactly where to start.