Understanding Falsifiable Tests

At the heart of building an early-stage startup is identifying and validating assumptions. And the foundation of assumption validation is the development of falsifiable tests.

Falsifiable tests are important because every early-stage startup sits on a foundation of unvalidated assumptions of varying levels of risk. Some of those assumptions carry so much risk that if they are wrong, there is no business. It's not a bad thing; it's just the nature of early-stage startups.

As an early-stage investor, I routinely meet with founders who are unable to identify the core assumptions they've made that, if wrong, would leave them with no business. This is often because founders believe there must be a business, and therefore treat what are truly assumptions to be tested as already proven facts. When I see founders who attempt to identify and validate their assumptions, they often structure their validation to prove what they believe is right, rather than truly test their assumptions.

However, being able to honestly and thoughtfully identify the core assumptions your business rests on, and to develop experiments to test those assumptions, is critical to the success of early-stage startups. This is where falsifiable tests come in.

I. What Is a Falsifiable Test?

Definition · Falsifiable Test

A time-bounded, real-world experiment designed to invalidate a specific, high-risk external assumption by observing measurable buyer behavior under realistic conditions.

Essentially, a falsifiable test is an experiment where a clear, observable outcome would prove the core assumption wrong within a defined timeframe, using real-world signals from actual or representative buyers.

II. Key Components of a Falsifiable Test

1. It Targets an External Assumption

External assumptions are beliefs external to the business, such as buyer behavior, not internal beliefs, such as your technical ability.

Examples of external assumptions:

• +Buyers are willing to pay for this.
• +Buyers are willing to switch from the product they are currently using to this.
• +Buyers feel purchasing urgency now.

Valid external assumptions:

• +The VP of marketing can approve the budget for this product within 30 days.
• +15 operations managers will move their workflow from their current platform to this product over the next 14 days.

Invalid assumptions:

• +We can build the technology infrastructure needed for the platform.
• +We can build a large language model that works for our ICP.

2. Disprovable, Not Confirmatory

A true falsifiable test is designed to kill the assumption, not validate it. If the test cannot clearly fail, it is not falsifiable. To be falsifiable, a test must include:

• +A specific failure condition.
• +A binary or threshold-based outcome.

3. Behavioral, Not Opinion-Based

A falsifiable test must measure what people do, not what they say.

• +Weak: “10 users say they will use it.”
• +Strong: “5 users committed to pilots with defined success criteria.”

4. Time-Bounded (No More Than 14 Days)

Being time-bound prevents infinite research loops.

Keeping tests to no more than 14 days forces urgency, prioritization, and realism. It also works within the scope of getting to product-market fit as quickly as possible. The longer your tests take, the longer it takes to learn what's necessary to get to product-market fit.

5. Realistic Conditions

Tests must utilize actual buying conditions:

• +Pricing.
• +Friction.
• +Switching cost.
• +Stakeholders.

6. Clear Unit of Measurement

Tests must have a defined metric:

• +Number of paid conversions.
• +Number of signed pilots.
• +Percentage of users who complete a workflow.
• +Time-to-action.

III. The Structure of a Falsifiable Test

1. What is being tested: the explicit assumption, which must be external and high-risk.
2. Test design: the exact action being taken, who is targeted, and what they are being asked to do.
3. Failure condition (critical): the line that, if crossed, invalidates the assumption.
4. Timeline: must be 14 days or less.

IV. A Template for Structuring Your Falsifiable Tests

V. Questions to Ask When Evaluating Your Falsifiable Tests

When evaluating the falsifiable tests your team are building, you should ask:

• +Is this actually the riskiest assumption, or a convenient one?
• +Does failure collapse the entire business case?
• +Is the test behavioral, fast, and real-world?
• +Is the failure condition explicit and strict enough?
• +Could this test produce false positives?

VI. A Real-World Example: FlowOpsAI

Company: FlowOpsAI (a fictitious pre-seed company).  Concept: an AI-powered workflow system that automates monthly close processes for mid-market finance teams.

Step 1: Identify the Riskiest Assumption

Why this is the true risk. It captures multiple existential risks:

• +Trust risk: the use of AI with a company's financial data.
• +Switching cost: deeply embedded workflows.
• +Timing and urgency: monthly close is painful but tolerated.

Step 2: Falsifiable Test Design

Assumption being tested: controllers are willing to initiate a real workflow migration (pilot) to an AI-based close automation tool.

Action:

• +Identify 25 target companies (mid-market, $50M to $500M revenue).
• +Reach out to controllers via LinkedIn, warm intros, and email.

Offer:

• +A 2-week “close acceleration pilot.”
• +Requires uploading real (sanitized) close data.
• +Requires running one portion of their workflow through FlowOpsAI.
• +Positioning: “Reduce close time by 30% this month.”

Friction intentionally included:

• +Data sharing.
• +Workflow change.
• +Time commitment.

Implicit success criteria:

• +5 or more companies agree to run a pilot.
• +3 or more complete onboarding and begin usage.

Failure Condition

Fewer than 3 out of 25 qualified controllers agree to start a pilot involving real workflow or data within 14 days.

Timeline

• +Days 1 to 3: outreach and scheduling.
• +Days 4 to 10: calls and pilot setup.
• +Days 11 to 14: pilot commitments confirmed.

Why This Is a Good Falsifiable Test

1. Directly tests behavior, not interest or feedback. It tests actual workflow commitment.
2. Includes real friction: data sharing (trust barrier), process change (switching cost), and time investment.
3. Has a clear failure condition that is binary and measurable, leaving no room for interpretation.
4. Provides a fast feedback loop, with 14 days to an immediate signal.
5. Has high signal density. Even if it passes, the team can extract objection patterns, trust barriers, stakeholder blockers, and sales cycle realities.

VII. What Weak Tests Look Like

• +“We'll interview 20 controllers to see if they like the idea.”
• +“We'll build an MVP and see if people sign up.”
• +“We'll run ads and measure clicks.”

These fail because there is no real commitment, no switching friction, and no clear failure condition.