Product Strategy
12 Discovery Questions Every Founder Should Ask Before Building
Every founder we work with has conviction. They’ve spotted a problem. They have a solution. They’re ready to build.
That conviction is necessary. But conviction without validation is just expensive optimism.
The best founders balance conviction with curiosity. They ask hard questions before committing resources. They’d rather kill a bad idea in week one than discover it’s bad in month six.
Here are the 12 questions we ask in every discovery engagement. Answer them honestly before you write a line of code.
The Problem Questions
Before solving anything, make sure you understand what you’re solving.
1. Can You Describe the Problem in One Sentence—Without Mentioning Your Solution?
This sounds simple. It’s not.
Bad: “Small businesses need a better way to manage invoices with AI-powered automation.”
Good: “Small business owners spend 5+ hours per week chasing late payments.”
The bad version smuggles in a solution (AI-powered automation). The good version states the problem neutrally. You can solve “chasing late payments” many ways—automated reminders, better invoice design, payment terms consulting, factoring services.
If you can’t describe the problem without your solution, you might be in love with your solution rather than the problem.
2. How Do People Solve This Problem Today?
Every problem has a current solution—even if it’s “ignore it” or “use spreadsheets.”
Understanding existing solutions reveals:
- Switching cost: What are you pulling people away from?
- Competition: Who else is trying to solve this?
- Baseline: What’s the minimum you need to beat?
If people have no current solution, ask why. Sometimes the answer is “it’s not painful enough to solve.” That’s important to know.
3. Who Has This Problem the Most?
“Everyone” is not a target market. Neither is “small businesses” or “millennials.”
Get specific:
- Demographics: Age, location, income, industry
- Psychographics: Attitudes, behaviors, priorities
- Situation: What triggers the need?
Better: “E-commerce store owners doing $50K-500K/year in revenue, without a full-time finance person, who sell on multiple platforms.”
Specificity helps you find users, write messaging, and prioritize features. You can expand later. Start narrow.
4. How Painful Is This Problem—Really?
Pain exists on a spectrum:
| Level | Description | User Behavior |
|---|---|---|
| Mild | Annoying but tolerable | Complain but don’t act |
| Moderate | Frustrating, wastes time | Look for solutions occasionally |
| Severe | Costs money or opportunity | Actively searching, will pay |
| Critical | Business or personal crisis | Will pay almost anything |
Most problems are mild or moderate. Products built for mild problems struggle to get traction because the pain doesn’t motivate action.
How to assess pain:
- Do people spend money on workarounds?
- Do they complain about it unprompted?
- Have they tried other solutions?
- What happens if they don’t solve it?
The Solution Questions
Once you understand the problem, interrogate your solution.
5. Why Will Your Solution Work Better Than Alternatives?
Not “different.” Better.
Differentiation matters only if it improves outcomes. A purple invoicing app is different. An invoicing app that gets you paid 10 days faster is better.
Categories of “better”:
- Faster: Saves time, quicker results
- Cheaper: Lower cost, better value
- Easier: Simpler, less learning curve
- More complete: Solves adjacent problems too
- More accessible: Available to underserved segments
If you can’t articulate why you’re better in terms users care about, you have a differentiation problem.
6. What’s the Smallest Version That Delivers Value?
Your first version should prove one thing: that users want what you’re building.
That’s it. Not “showcase your vision.” Not “impress investors.” Prove demand.
The minimization exercise:
- List all planned features
- For each, ask: “Can users get value without this?”
- Remove everything where the answer is “yes”
- What’s left is your true MVP
Most MVPs we see are 3-5x larger than necessary. Cut ruthlessly.
7. What Has to Be True for This to Work?
Every product depends on assumptions. Make them explicit:
- Users will pay $X/month
- We can acquire customers for under $Y
- Users will check the app daily
- Integration with Z is possible
- Our target market is growing
These are your killer assumptions—the things that must be true for the business to succeed. If any is false, the product fails.
Next step: Rank assumptions by uncertainty. Test the riskiest ones first.
The Business Questions
Great products can still make bad businesses. Verify the economics.
8. How Will Users Find You?
“We’ll do marketing” is not a strategy.
Identify specific channels:
- Content/SEO: What will you rank for? How long until traffic?
- Paid acquisition: What’s the expected CAC? Do unit economics work?
- Partnerships: Who would promote you? What’s in it for them?
- Community: Where do your users gather? Can you participate authentically?
- Word of mouth: What makes this remarkable enough to share?
Test before building: Can you get 100 people interested in your landing page? If not, how will you get 10,000 to use your product?
9. What Will Users Pay—and Is That Enough?
Two questions here:
Willingness to pay:
- What do they pay for similar solutions?
- What’s the value in dollars of solving this problem?
- What price did they expect when you described the product?
Unit economics:
- Revenue per user vs. cost to acquire
- Lifetime value vs. churn expectations
- Margin after infrastructure and support costs
A product can be loved by users and still fail as a business. Verify the math.
10. Why Now?
Why is this the right time for this product?
Good answers:
- New technology enables what wasn’t possible before
- Regulation changed, creating opportunity
- Market behavior shifted (remote work, mobile-first, etc.)
- Incumbent is vulnerable (outdated, expensive, hated)
Bad answers:
- “I just thought of it”
- “No one’s done it yet” (maybe for good reason)
- “I have time now”
Timing matters more than most founders realize. Being too early is as deadly as being too late.
The Team Questions
Ideas are cheap. Execution is everything.
11. Why Are You the Right Team to Build This?
Investors call this “founder-market fit.”
Strong founder-market fit:
- You’ve experienced the problem personally
- You’ve worked in this industry
- You have relevant technical expertise
- You have unfair access to customers
- You’re irrationally committed to this space
Weak founder-market fit:
- You read about this problem in a blog
- You think the market is big (but have no connection to it)
- You’re excited about the technology more than the problem
You don’t need all strong signals, but you need some. Building a product is hard. Building a product in a domain you don’t understand is harder.
12. What Will You Stop Doing to Do This?
Time is finite. Building something new means not doing something else.
For employed founders:
- When will you work on this? Before work? Evenings? Weekends?
- How long can you sustain that? Months? A year?
- At what point do you go full-time?
For full-time founders:
- What other projects or commitments are you dropping?
- What part of your current routine changes?
- Who’s covering the things you’re giving up?
Starting something is easy. Sustaining it requires sacrifice. Know what you’re trading.
How to Use These Questions
Before You Start Building
Work through all 12 questions. Write your answers. Be honest—you’re only lying to yourself if you fudge them.
Red flags that suggest more validation:
- You can’t articulate the problem without your solution
- You’re guessing about who has the problem
- Pain level seems mild or moderate
- No clear channel to reach users
- Founder-market fit is weak
During Discovery
Revisit these questions as you learn more. Your answers should get sharper and more confident.
If answers get fuzzier—if research reveals your assumptions were wrong—that’s valuable. Pivot before you invest more.
Before Major Investment
Before significant funding, hiring, or development commitment, verify:
- Problem questions have evidence-backed answers
- Solution questions have user validation
- Business questions have data (even rough)
- Team questions are honestly assessed
What Comes Next
These questions reveal whether you’re ready to build. If the answers are strong, move forward with confidence. If they’re weak, more discovery is needed.
Our Blueprint process systematically answers these questions through user research and validation experiments. In two weeks, you’ll know whether to build, pivot, or stop—based on evidence, not hope.
Need help answering these questions? Book a discovery call and let’s talk through your specific situation.
Related Posts
Need help putting this into practice?
Book a Blueprint session and we'll turn the ideas in this article into your next validated release.
Book a Discovery Call