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. Early-stage founders work at a different scale and need a different kind of framework.
Before you have a team, a roadmap, or a product, the question is whether the idea is worth building at all. The framework that answers that question has to be cheap, fast, and honest about what you actually know.
This is the framework we built Scoutr around.
If you want the broader theory behind why discovery works this way, what is design thinking covers the double diamond structure that underpins all of this.
Want to run through this framework right now? Start your discovery process →
The Core Principle
Discovery is the part of product development where most founders waste months. The build comes after the discovery work has been done; the failure mode is investing build time before you have evidence that anyone wants the result.
The signal you're looking for is behavior. "I'd use that" comes for free in a conversation, so it carries no weight. Behavioral evidence is different: what people currently pay for, what they hacked together over a weekend, what they tolerate about their current workaround. That's the data discovery is built to surface.
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, what you have is a hypothesis to test rather than a target user. 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.
The bar isn't one conversation; it's five, where the problem came up unprompted in specific and emotional language. One person ranting about it could be a bad day. Five people independently describing the same pain is a pattern worth building around.
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.
The clearest version of this signal: someone in your target segment has a line item for this on their company card. SaaS subscription, contractor invoice, freelancer retainer, internal tool maintenance — anything where money is already moving to address the gap.
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," 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," the problem creates real urgency.
What you're looking for: Evidence that the user is worse off without a solution and knows it.
Question 6: Why you?
The real question is whether you have unfair distribution or unfair insight. Knowing the 50 people with this problem and being trusted by them already counts as unfair distribution. Four years inside the workflow and seeing the gap nobody else has noticed counts as unfair insight. "I'm passionate about productivity" doesn't.
If you don't have one of those today, you can still build, but you're starting without a moat and the next year of your life will be about earning one.
How to Use This Framework
The six questions work best when answered honestly, against the evidence you actually have rather than the answers you wish were true.
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.
A few caveats
The framework reduces risk; it doesn't eliminate it. You can answer all six questions cleanly and still build the wrong thing because the market shifts under you. The framework also doesn't replace shipping. At some point you have to put something in front of real users, because the answers from the framework only take you so far. Discovery doesn't end at launch either; the questions just change shape.
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.