How to Test a Business Plan Assumption Before You Build

Go through the page line by line and rewrite each statement as something that could be shown false. "We will serve small accounting firms" is not testable. "At least 10 of 40 small accounting firms we contact will pay a deposit for the service within three weeks" is testable.

A workable extraction covers five families of claim, which map onto the standard one-page sections:

Expect 15 to 30 claims from a single page. If you get fewer than 10, you are summarizing rather than extracting, and the ranking in the next step will not discriminate between anything.

Two rules keep this honest. First, write the claim in the customer's or the market's terms, not yours ("customers renew" not "the product is good"). Second, keep the number in the claim. A claim with a number can pass or fail; a claim without one can only be argued about.

The interesting question is not "how likely is this to be true" but "what happens to my time and money if it is false." There are three cost buckets worth separating:

• Sunk cost. Money and hours already committed that cannot be recovered if the claim fails. A signed lease, a completed build, a paid deposit on equipment.
• Rework cost. What you have to throw away and redo. If your channel assumption is wrong, the landing page, ad creative and onboarding emails built around it all need rebuilding.
• Delay cost. How long the correction takes before revenue can start. A pricing error discovered before launch costs a week of rework; discovered after, it costs a cohort of customers and every contract you signed at the wrong number.

Assign each claim a rough dollar figure or a person-week figure. Precision is not the point. BDC's guidance to show detailed assumptions and break them down is aimed at the same target: you need something concrete enough to compare BDC on assumptions. Order-of-magnitude is enough to sort claims into three bands.

A small worked table

Take a fictional service that does bookkeeping cleanup for small accounting firms, with a plan built on the SCORE and HubSpot one-page structures. Four of its claims might look like this:

The ranking says to test price first, not the channel. That is usually the right answer for services businesses, and it is almost never the first test people run. Most founders test whether they can get attention (cheap, low cost if wrong) and then discover at the point of payment that the price or the willingness to pay was the fragile assumption all along.

The decision rule

Rank by cost-if-wrong multiplied by uncertainty, where uncertainty is a 1 to 5 score for how little evidence you currently have. If two claims score within about 20 percent of each other, test the one you can test faster. Booking five paid deposits takes days; a full unit-economics study can take weeks. Speed of evidence is a legitimate tiebreaker because the only thing a test buys you is information before the next decision.

Before committing to a ranking, sanity-check your claim list against a model of the business. The Business Model Canvas has nine blocks: customer segments, value propositions, channels, customer relationships, revenue streams, key resources, key activities, key partnerships and cost structure Wikipedia on the Business Model Canvas. Strategyzer, the company behind the canvas, frames business model work as prototyping and testing rather than one-off planning Strategyzer on business models.

The check is simple: does your claim list touch all nine blocks? If it is all customer and channel claims with nothing on cost structure or key partners, you have a blind spot. A good example is a founder who tests demand for a physical product exhaustively but never tests whether a supplier will hold pricing at low volume, which is a partnership claim with high cost if wrong.

The Lean Canvas will surface a different category of gap. Maurya replaced key partners, key resources, key activities and customer relationships with problem, solution, key metrics and unfair advantage to make the canvas more entrepreneur-focused Maurya on the Lean Canvas. The unfair advantage box is worth mining for a claim you would otherwise miss: "a competitor cannot copy this within 12 months." Canva's guide to the Lean Canvas notes that its problem-solution framing helps founders avoid spending years building a product nobody needs Canva on Lean Canvas.

If you have several customer segments, produce a separate claim list per segment. IdeaScale's overview of the canvas recommends splitting segments precisely because their needs and problems differ IdeaScale on Lean Canvas. A single ranked list for two different buyer types will force the high-cost claim from one segment to compete unfairly against the other.

For the top-ranked claim, the test has to meet four conditions:

1. It can fail. If no plausible result would make you abandon or reprice the claim, it is not a test.
2. It is cheaper than being wrong. A test that costs 60 percent of the rework cost is not worth running. Aim for roughly 10 to 20 percent.
3. It reads real behavior. Someone clicking a button is evidence; someone saying "I'd buy that" is not.
4. It finishes inside your decision window. If you need to decide next week, a test that takes six weeks has no decision value.

That third condition is the one people break most often. The Railsware walkthrough of the Lean Canvas makes the point through the problem box: respondents should describe how they solve the problem today, which reveals whether the problem is real and urgent, not hypothetical Railsware on the Lean Canvas. A claim about willingness to pay is best tested by asking for money, or at least a deposit or a signed letter of intent with a price in it.

Here is the shape of a test brief. Keep it to one page so it can be shared with a partner or a lender:

Claim: 5 of 30 firms will prepay a $300 deposit for a cleanup
         priced at $900 on completion.
Cost if wrong: $4,000 (rework of pricing page, proposal
         templates, and 3 weeks of delay).
Test: Direct email to 30 firms from a purchased list of
         200, offering the cleanup at the planned price,
         with a link to a deposit page.
Pass threshold: 5 deposits within 14 days.
Fail threshold: 2 or fewer deposits in 14 days.
Inconclusive: 3 or 4 deposits, extend to 60 firms.
Cost of test: approx. $600 of time plus list cost.
Decision window: 3 weeks.

Note the inconclusive band. Real tests produce ambiguous results, and a pre-written rule for the middle zone stops the result from being rationalized after the fact.

A threshold is only useful if it was written down before the data arrived. The Foundation Sprint, created by the people behind the Design Sprint, frames the earliest stage of a startup as the highest-leverage moment, and its process compresses months of validation questions into a two-day exercise the Foundation Sprint discussion. The compression works only because the questions and the pass criteria are fixed before the sprint begins.

Three practical rules for thresholds:

• Tie the threshold to the claim, not the effort. If your plan needs 5 deposits to hit the revenue forecast, the threshold is 5, not "a few."
• Choose a sample size you can afford to lose. A failure on a sample of 30 stings; on 300 it might end the business. Start with the smallest sample that can distinguish a clear pass from a clear fail.
• Record the result even when it supports you. The value of the log is that six months from now, you can see which parts of the plan are still guesses. This is the same discipline BDC describes when it says the plan should be revisited often and evolve with the business BDC on business plans.

One more consideration: cost claims deserve a different test design from demand claims. A demand claim can be tested with a landing page and a deposit link. A cost claim has to be tested by actually delivering the work, even a small amount of it. Do ten deliveries by hand and time them. Manually delivered jobs are the cheapest possible version of your unit economics, and the hours you record are the number your pricing has to survive.

When the top claim passes, remove it from the list and promote the next highest-scoring claim. Do not skip back to building because one test passed. The score table is the build gate. Building starts when the claims whose failure would be most expensive have passed or been repriced.

Repricing is a legitimate pass. If your deposit test returns 3 of 30 rather than 5, the claim about price was wrong but the claim about demand was right. That is a useful outcome and should change the plan: a lower price, a different package, a narrower segment. Revisit the financial section with the new number and rerun the ranking, because the cost of being wrong on adjacent claims shifts when the price changes.

If you get to build, the cheapest first version is the one that tests the fewest remaining assumptions. A landing page with a payment link tests demand and pricing at once. A manual delivery tests cost and quality. A working app tests neither of those things first. The sequence is demand, price, cost, then product, and only the first three can be tested before you write code.

Not every expensive claim is about customers. A team building on top of several model providers has an operations claim with real cost if wrong: that switching or combining providers does not require rewriting the integration. That kind of claim is testable in a day by sending the same request through two providers and comparing the payloads. The design pattern that makes this test cheap is a single interface in front of multiple providers, so a provider swap is a configuration change rather than a refactor.

If your plan depends on sending text, image, audio, video or embedding requests through more than one model, Quanta Inference offers one OpenAI-compatible API key for those model types, which makes the provider-swap test a short exercise rather than a build.