The Questions Great Founders Answer Before Building

The quality of your product is determined before a single line of code is written. It is determined by the specificity of the questions you answer and the honesty of the answers you give.

Editorial note: Founder quotes throughout this article are composites drawn from multiple EB Pearls engagements. The numbers and decisions are real. Identifying details have been changed.

Why We Wrote This

After 1,400+ client engagements, we can predict project outcomes from the founder's answers to seven questions. Founders who answer these questions with evidence ship faster, spend less, and build products with higher retention. Founders who answer with assumptions spend more, ship later, and build products that solve the wrong problem.

This article gives you the seven questions, explains why each matters, and shows what good versus weak answers look like.

 

Introduction: Why Pre-Build Questions Determine Post-Launch Outcomes

Software development is an amplifier. It amplifies good decisions into successful products and bad decisions into expensive failures. The decisions that matter most are not made during development. They are made before development: in the positioning, user definition, success criteria, and risk identification that shape the scope document. For more, see what discovery calls actually reveal.

A widely cited heuristic from Barry Boehm’s research in IEEE Software suggests that the cost of fixing a requirement error increases by 10x to 100x as a project progresses from requirements to maintenance — the exact multiplier varies, but the direction is consistent. A wrong answer at the pre-build stage costs AU$500 to fix. The same wrong answer discovered during QA costs AU$5,000 to $50,000. These seven questions are designed to catch wrong answers when the cost is lowest.

The Seven Questions

Question 1: What is your positioning statement?

Template: "For [target user] who [specific problem], [product name] is a [category] that [key benefit], unlike [primary alternative] because [core differentiator]." For more, see the first build mistake.

Weak answer: "We are building an app for businesses that helps them be more efficient." This is a category description, not a positioning statement. It could describe 10,000 products.

Strong answer: "For solo tradespeople in Australia with 5 to 20 weekly jobs who currently schedule via text message, QuickJob is a mobile-first job management tool that eliminates double-bookings, unlike Tradify because it requires zero desktop setup and works entirely from the phone on-site."

Why it matters: the positioning statement constrains every scope decision. If a feature does not serve the target user, solve the specific problem, or reinforce the differentiator, it belongs in Phase 2 or never.

Question 2: Who is your user (with evidence)?

The specificity test: can you find 10 of them in a week? "Business owners" fails. "Solo electricians in Sydney who run 8 to 15 jobs per week and currently use a combination of Google Calendar and handwritten notes" passes. For more, see the true cost of waiting.

The evidence test: have you spoken to at least 10 of them? If not, your user definition is an assumption, not a finding.

Question 3: What is your success metric?

One metric. Not five. The metric should describe a behaviour change: users who were doing X are now doing Y through your product. "Downloads" is a vanity metric. "Weekly active users who complete at least one core task" is a behaviour metric. For more, see the compounding clarity framework.

At EB Pearls, the success metric becomes the acceptance criterion for the RAT and the primary KPI for post-launch iteration. If you cannot define it, you cannot test it.

Question 4: What is the riskiest assumption?

The single assumption that, if wrong, makes the product irrelevant. Not risky as in technically hard. Risky as in existentially wrong. "Users will pay AU$29/month for scheduling" is an existential risk. "We can build real-time notifications" is a technical risk.

The RAT tests the existential risk in Sprint 1. Technical risks are managed through architecture review (Pillar P03).

Question 5: What is the competitive landscape?

Not just direct competitors. The real competitive landscape includes: direct competitors (products solving the same problem), indirect competitors (products solving the adjacent problem), workarounds (spreadsheets, email, manual processes), and inertia (doing nothing, which is the strongest competitor of all).

Question 6: What are your budget and timeline constraints?

The honest version: total available budget, how it is split between build and post-launch (75/25 recommended), hard deadline if any, and runway remaining. These constraints shape the scope. Withholding them produces proposals that miss reality.

Question 7: Who makes the decisions, and how fast?

Slow decision-making is the silent timeline killer. A founder who takes 5 business days to approve a design mockup adds 5 days to the timeline for every design review. Over an 8-week project with 6 review points, that is 30 business days (6 weeks) of added timeline from decision latency alone.

Pre-Build Readiness Checklist

• Positioning statement completed with template structure

• User defined with enough specificity to find 10 in a week

• Success metric is a behaviour change, not a vanity metric

• Riskiest assumption identified (existential, not technical)

• Competitive landscape mapped: direct, indirect, workarounds, inertia

• Budget and timeline constraints shared honestly

• Decision-maker and decision speed documented 

Frequently Asked Questions

Final Thought

Great founders are not the ones with the best ideas. They are the ones who ask the hardest questions about their ideas before writing the first line of code. The seven questions in this article are not a formality. They are the foundation that every successful product is built on.

The most expensive code is the code that answers the wrong question. These seven questions exist to make sure yours answer the right one.