Your IDE is calling. Resist.

I know the feeling. You have an idea. It's exciting. Every fiber of your being wants to open VS Code and start building.

But here's what I've learned after a decade of building products—some successful, many failures:

The ideas that fail aren't killed by bad code. They're killed by bad assumptions.

Assumptions about who wants this. Assumptions about what they'll pay. Assumptions about how they'll find you. Assumptions that seemed obvious—until launch day revealed they were fantasies.

This guide is a pre-flight checklist. Seven questions that, if answered honestly, will dramatically increase your odds of building something that actually matters.

Don't touch your IDE until you can answer all seven.


Table of Contents


Why These Questions Matter

Every question in this guide targets a specific failure mode. Together, they address the most common reasons startups fail:

┌─────────────────────────────────────────────────────────────────┐
│                    FAILURE MODE MAPPING                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   QUESTION                          FAILURE IT PREVENTS         │
│   ──────────────────────────────────────────────────────────    │
│   1. Who is this for?               Building for nobody         │
│   2. What do they pay for now?      No market demand            │
│   3. Why will they switch?          Undifferentiated product    │
│   4. How will they find you?        Distribution failure        │
│   5. What's the minimum?            Scope creep, never shipping │   6. What's success in 90 days?     Vague goals, no momentum    │
│   7. What makes you quit?           Sunk cost trap              │
│                                                                 │
│   Answer all seven → dramatically reduce failure probability    │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

These aren't busywork questions. They're landmine detectors.


Want to answer these questions with real data? NicheCheck provides market analysis to inform your answers →


Question 1: Who Exactly Is This For?

Specificity is a feature, not a bug.

The Wrong Answer

"Small business owners." "Developers." "Marketers." "People who want to be more productive."

These answers feel safe because they describe large markets. But they're actually dangerous because they describe no one in particular.

The Right Answer

"Sarah, a freelance web developer with 3-5 clients, who spends 4 hours every Friday chasing late invoices and feels embarrassed asking for money."

"Marcus, a content marketing manager at a B2B SaaS startup, who manually copies data from 6 tools into a spreadsheet every week and dreads the monthly reporting meeting."

"Jessica, a solo Etsy seller making $3-5K/month, who loses 2-3 hours every Sunday photographing new products and wishes there was a faster way."

Notice the difference? These are people, not demographics.

Why It Matters

When you design for "small business owners," every decision is arbitrary. Should this button be here or there? Should we add this feature? Who knows—"small business owners" is too vague to guide decisions.

When you design for Sarah, decisions become clear. Would Sarah understand this? Would Sarah use this? Would Sarah pay for this?

"You can't build for everyone. You shouldn't try. Pick one person. Build for them."

How to Get the Right Answer

  1. Think of someone you know with this problem. An actual person—not a persona, not a composite, not an imaginary ideal customer.

  2. If you don't know anyone, you don't understand the problem. Seriously. If you can't point to a real person who has this problem, how confident are you that the problem exists?

  3. Give them a name. Refer to them by name. In every product decision, ask: "Would [Name] use this?" It's a better filter than any framework.

For more on identifying your target customer, see our product validation framework.


Question 2: What Problem Are They Paying to Solve Today?

If nobody pays to solve this problem, they won't pay you either.

The Wrong Answer

"They're not paying for anything right now—that's the opportunity!"

"There's no direct competitor, so we have first-mover advantage!"

"People are solving this manually, so there's demand for automation!"

The Right Answer

"They currently use Competitor X for $29/month but constantly complain about the clunky interface and missing [specific feature]."

"They pay a freelancer $200/week to do this manually, which costs them $800/month and takes 3 days to get results."

"They use a combination of Spreadsheets + Tool Y + manual email, which costs them about $50/month plus 5 hours of time."

Why It Matters

Payment behavior is the ultimate validation. If people are already spending money on this problem—even imperfect solutions—you know: - The problem is real enough to warrant spending - People are actively looking for solutions - There's a price anchor you can compare against

If nobody is spending money on this problem, you're trying to create new behavior. That's 10x harder than redirecting existing behavior.

How to Get the Right Answer

  1. Search "[problem] software" or "[problem] tool"
  2. Do results come up?
  3. Do they have visible pricing?
  4. Do they have reviews indicating real customers?

  5. Check freelancer marketplaces

  6. Search Upwork and Fiverr for people offering to solve this problem
  7. What do they charge?
  8. How many jobs have they completed?

  9. Ask directly in your research

  10. "What are you currently using to handle [problem]?"
  11. "How much do you spend on this per month?"
  12. "When was the last time you paid for something related to this?"
┌─────────────────────────────────────────────────────────────────┐
│                    PAYMENT EVIDENCE HIERARCHY                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   STRONGEST EVIDENCE                                            │
│   └── Competitors with visible pricing and customers            │
│                                                                 │
│   STRONG EVIDENCE                                               │
│   └── Freelancers/agencies charging for manual solutions        │
│                                                                 │
│   MODERATE EVIDENCE                                             │
│   └── Adjacent products with payment behavior                   │
│                                                                 │
│   WEAK EVIDENCE                                                 │
│   └── People saying they "would pay" (hypothetical)             │
│                                                                 │
│   NO EVIDENCE                                                   │
│   └── No spending behavior anywhere in the ecosystem            │
│                                                                 │
│   If you're in "no evidence" territory: major red flag          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Question 3: Why Will They Switch to You?

"Better" isn't a reason. "10x better at the thing they care most about" is a reason.

The Wrong Answer

"Our UX is better." "We're cheaper." "We have AI." "We're faster." "Our tech is superior."

These are features, not switching reasons. Every startup claims these things. Customers have heard it all before.

The Right Answer

"Competitor X requires a 15-minute setup for every new client. We do it automatically in 10 seconds. For agencies managing 50+ clients, that's 12 hours saved per month."

"Current solutions are designed for enterprises and cost $500+/month. We're purpose-built for freelancers at $29/month—no features they don't need, just the ones they do."

"Existing tools don't integrate with [critical tool]. We're the only solution that connects [Tool A] to [Tool B] without manual data entry."

Why It Matters

Switching costs are real. People have: - Invested time learning current tools - Built workflows around existing solutions - Trained team members on the current way - Stored data in current systems

They don't switch for "marginally better." They switch for dramatically better at something specific.

How to Get the Right Answer

  1. List the top 3 complaints about current solutions
  2. Read reviews obsessively
  3. Search "[competitor] sucks" on Twitter
  4. Ask users what frustrates them

  5. Pick ONE to solve dramatically better

  6. Not all three—focus
  7. Not "solve similarly well"—dramatically better
  8. 10x better, not 10% better

  9. Quantify the improvement

  10. Hours saved
  11. Money saved
  12. Errors eliminated
  13. Steps removed

  14. If you can't quantify it, it's not compelling enough

  15. "Better UX" isn't quantifiable
  16. "Complete a task in 2 clicks instead of 12" is quantifiable

For more on competitive positioning, see competitor analysis strategies.


Need help understanding your competitive landscape? NicheCheck analyzes competitor positioning →


Question 4: How Will They Find You?

Distribution is harder than product. Plan it first, not last.

The Wrong Answer

"We'll do some marketing." "Word of mouth." "SEO." "Social media." "We'll figure it out after we launch."

The Right Answer

"I'll post our launch in [specific community] where 50,000 of my target customers gather. I've seen three similar products launch there successfully, and I've been active in the community for 6 months."

"We'll target the keyword '[specific phrase]' which has 8,000 monthly searches and a CPC of $2. Our competitors rank poorly and we have domain expertise to create better content."

"I have 3,000 Twitter followers in this niche and have already validated interest through polls. Launch announcement should reach our target audience directly."

Why It Matters

"Build it and they will come" is the biggest lie in tech.

Great products fail all the time because nobody finds them. Distribution is often harder than building the product—and yet most founders think about it last, not first.

How to Get the Right Answer

  1. List 5 places your target customer hangs out online
  2. Subreddits
  3. Discord servers
  4. Slack communities
  5. Facebook groups
  6. Twitter hashtags/accounts they follow
  7. Newsletters they read
  8. Conferences they attend (virtual or in-person)

  9. For each, note:

  10. Size (members, followers, traffic)
  11. Activity level (posts per day/week)
  12. Rules about promotion (some ban it, some welcome it)
  13. Examples of similar products that launched there

  14. Rank by: (Audience Size) × (Relevance) × (Promotion-Friendliness)

  15. Pick your launch channel

  16. The one that scores highest
  17. Have a backup plan
┌─────────────────────────────────────────────────────────────────┐
│                    DISTRIBUTION PLANNING                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   Channel: _______________________________________________      │
│   Audience size: ___________                                    │
│   Relevance (1-10): ___                                         │
│   Can you promote there? Yes / No / With conditions             │
│   Similar products launched there? Yes / No                     │
│   Your existing presence: None / Lurker / Active / Authority    │
│                                                                 │
│   If you can't fill this out for at least 5 channels:           │
│   You don't know your customer well enough yet.                 │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

For more on early distribution, see finding first customers.


Question 5: What's the Minimum Version That Delivers Value?

Every feature you add before launch is a feature you might delete later.

The Wrong Answer

"We need authentication, payments, a dashboard, an API, mobile apps, integrations with 10 tools, analytics, team features, and AI capabilities."

"It won't be good enough without [extensive feature list]."

"Users will expect [feature competitor has]."

The Right Answer

"One screen that does one thing. If this one thing works, everything else can wait."

"The smallest possible version that solves the core problem for one person."

"What's the one feature that, if it worked perfectly, would make people pay—even if nothing else existed?"

Why It Matters

Pre-launch features are guesses. Post-launch features are informed decisions.

Every feature you build before talking to users is a bet. Some will be wrong. The more features you build, the more wrong bets you make.

The goal of v1 is learning, not perfection.

How to Get the Right Answer

Ask yourself: "If I could only build ONE feature, which one would make people pay?"

That's v1. Literally just that. Everything else is v2+.

Real Examples

Product v1 Was... Everything Else Came Later
Dropbox File syncing Sharing, teams, apps, integrations
Buffer Schedule tweets Analytics, team features, multi-platform
Stripe Accept payments Subscriptions, invoicing, identity verification
Basecamp Message board To-dos, schedules, file storage, check-ins

These companies would be worth less today if they'd tried to launch with all their current features. They'd probably have never launched at all.


Question 6: What Does Success Look Like in 90 Days?

Vague goals lead to vague effort which leads to vague results.

The Wrong Answer

"As many users as possible." "Going viral." "Getting featured on Product Hunt." "Lots of traffic."

The Right Answer

"10 paying customers at $29/month = $290 MRR, with at least 3 responding to a survey saying they'd be 'very disappointed' if the product disappeared."

"50 email signups with a 15%+ open rate, leading to 5 scheduled demo calls and 2 closed deals by day 90."

"$500 in pre-orders collected before writing any code, with a clear path to $1,000 MRR by month 3."

Why It Matters

Specific goals create specific actions. They also create specific accountability.

"Get users" can mean anything, so you can rationalize anything as progress. "$290 MRR" is binary—you either hit it or you don't.

How to Get the Right Answer

Fill in these blanks:

  • Revenue goal: $_____ MRR by day 90
  • Customer count: _____ paying customers
  • Retention signal: _____% still paying after 30 days
  • Satisfaction signal: _____% "very disappointed" if product gone

Write these numbers down. Put them somewhere you'll see them.

┌─────────────────────────────────────────────────────────────────┐
│                    90-DAY SUCCESS METRICS                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   Metric             Target          Stretch                    │
│   ──────────────────────────────────────────────────────        │
│   MRR:               $______         $______                    │
│   Paying customers:  ______          ______                     │
│   30-day retention:  ______%         ______%                    │
│   "Very disappointed": ______%       ______%                    │
│                                                                 │
│   Date to measure: _______________                              │
│   Person who will hold you accountable: _______________         │
│                                                                 │
│   If you hit these numbers: You have something.                 │
│   If you don't: You have data about what to fix.                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Question 7: What Will Make You Quit?

Boundless persistence isn't admirable. It's a trap.

The Wrong Answer

"I'll never quit. I believe in this." "I'll keep going until it works." "Quitting is for losers."

The Right Answer

"If after 6 months I have fewer than 20 paying customers and churn is above 10% monthly, I'll either pivot dramatically or move on."

"If after 90 days I can't get 5 people to pay, I'll take that as a strong signal this isn't working."

"If I'm consistently miserable working on this for 60+ days straight, I'll pause and reassess."

Why It Matters

Here's the uncomfortable truth: most ideas don't work. The successful founders aren't the ones who never fail—they're the ones who fail fast and try again.

Setting kill criteria in advance—when you're rational—protects you from sunk cost fallacy later—when you're emotional.

How to Get the Right Answer

Define your failure conditions NOW:

  • Time limit: I'll give this _____ months maximum
  • Revenue floor: Below $_ MRR by month ___ = failure
  • Customer floor: Fewer than _ paying customers by month ___ = failure
  • Churn ceiling: Above _____% monthly churn = failure
  • Personal limit: If I hate working on this for _____ days, I stop

Write it down. Tell someone who will hold you accountable. Revisit monthly.

For more on knowing when to stop, see when to kill your idea.


Get clarity before you commit. NicheCheck helps you validate assumptions with data →


The Self-Assessment Scorecard

Now let's see where you stand. For each question, rate how confident you are in your answer:

Question Can You Answer Specifically?
1. Who exactly is this for? Yes / Partially / No
2. What are they paying for now? Yes / Partially / No
3. Why will they switch to you? Yes / Partially / No
4. How will they find you? Yes / Partially / No
5. What's the minimum version? Yes / Partially / No
6. What's success in 90 days? Yes / Partially / No
7. What will make you quit? Yes / Partially / No

Scoring

Score Verdict
7 "Yes" answers You're ready. Build.
5-6 "Yes" answers Close. Spend one more day on the gaps.
3-4 "Yes" answers Not ready. More research needed.
0-2 "Yes" answers Don't touch your IDE. Answer these first.

Putting It Together: A Real Example

Let me show you how these questions work together for a real idea.

Idea: A time-tracking tool for freelance content writers

Question 1: Who exactly?

"Maya, a freelance B2B content writer with 4-6 clients, who bills hourly but often forgets to track time and ends up undercharging. She's been freelancing for 2 years and makes $60-80K/year."

Question 2: What do they pay for now?

"Maya currently uses Toggl ($10/month) but hates that it's designed for agencies. She also uses a Google Sheet to track client hours. Some writers pay for Harvest ($12/user) or use Notion with manual tracking."

Question 3: Why will they switch?

"Current tools require starting/stopping timers, which writers forget when they're in flow. We automatically detect writing activity and associate time with clients based on document names. Writers capture 30%+ more billable time without changing their workflow."

Question 4: How will they find you?

"Post in r/freelanceWriters (285K members), Superpath Slack community (10K+ content marketers), and I have 2,400 followers on Twitter who are mostly content professionals. Will also target 'time tracking for freelancers' (1,800 monthly searches)."

Question 5: Minimum version?

"Desktop app that detects active documents and logs time. Period. No invoicing, no reports, no team features. Just: 'You spent 2 hours in ClientA_blog_post.docx today.'"

Question 6: Success in 90 days?

"25 paying customers at $12/month = $300 MRR. At least 5 customers respond to survey as 'very disappointed' if product disappeared."

Question 7: What makes you quit?

"If by month 4 I have <15 paying customers with >15% monthly churn, I'll either pivot (maybe to a different creative vertical) or abandon and move on."


See how concrete that is? Every decision from here—features to build, copy to write, where to post—flows from these answers.


The Meta-Point

Here's what I want you to take away:

These questions aren't bureaucracy. They're protection.

Every question you can't answer is a landmine waiting to explode—and it will explode later, when fixing it is expensive and painful.

Answer them now, when it's free.

Then build.

┌─────────────────────────────────────────────────────────────────┐
                    COST OF ANSWERING QUESTIONS                  
├─────────────────────────────────────────────────────────────────┤
                                                                 
   ANSWER BEFORE BUILDING:                                       
   └── Cost: A few hours of research and thinking                
   └── Outcome: Clarity, confidence, or kill signal              
                                                                 
   DISCOVER ANSWERS DURING BUILDING:                             
   └── Cost: Weeks of wasted development                         
   └── Outcome: Rework, frustration, pivot or failure            
                                                                 
   DISCOVER ANSWERS AFTER LAUNCH:                                
   └── Cost: Months of life + savings + confidence               
   └── Outcome: Painful failure, discouragement                  
                                                                 
   The earlier you answer, the cheaper the lesson.               
                                                                 
└─────────────────────────────────────────────────────────────────┘

What Happens After You Answer?

Once you can confidently answer all seven questions, you're ready to:

  1. Build your minimum version — The one feature that matters most
  2. Launch to your identified channel — The place where your customers already gather
  3. Measure against your 90-day targets — The specific metrics you defined
  4. Iterate or kill based on your kill criteria — The honest assessment you pre-committed to

For a complete validation process before building, see our product validation framework.


Resources

Free tool: Quickly check if your niche is already taken with our free niche checker -- no signup required.


Ready to answer these questions with real data? NicheCheck validates ideas in minutes, not months →