How to test business assumptions: the step-by-step process that actually works

Every business idea is built on assumptions. Your Business Model Canvas is full of them. Your Value Proposition Canvas is full of them. Customers want this. They will pay that price. We can deliver through this channel. Each of those statements is an assumption until you have evidence.

The problem is not that teams fail to test. Most innovation teams I work with run experiments. The problem is how they test business assumptions. They pick the easy ones. They skip the step where you define what failure looks like. They run a test, get ambiguous results, and call it a success because nobody set a threshold beforehand.

After 100+ sessions with teams testing business ideas, I have seen the same pattern. Teams that follow a structured process for assumption testing get clear answers in weeks. Teams that skip steps get busy work that teaches nothing. This is the step-by-step process that actually works.

Why most assumption testing fails

Before walking through the process, it is worth understanding why most teams get this wrong. It is not a knowledge problem. Most innovation teams have read Testing Business Ideas or know the basics of Lean Startup. The failure is a process problem.

Three things go wrong most often:

Teams test what is comfortable, not what is risky. Building a prototype feels productive. Asking potential customers whether they actually have the problem you think they have feels uncomfortable. So teams default to feasibility experiments (“can we build it?”) and avoid desirability experiments (“does anyone want it?”). I wrote about this pattern in detail in business experiment mistakes.

Teams skip assumption prioritization. A typical Business Model Canvas contains 15 to 30 assumptions. Testing all of them is impossible. But without a method for deciding which ones to test first, teams either test randomly or start with whatever feels most natural. The result: three months of experiments that tested things that did not matter.

Teams do not define failure before they start. This is the single biggest problem. Without fail criteria set before the experiment runs, every result can be reinterpreted as success. “We said 30%, but 22% is close enough.” That is not testing. That is storytelling.

The process below fixes all three.

Step 1: Map your assumptions from your canvases

Assumptions do not appear out of thin air. They come from your business model and value proposition design. Every box on your Business Model Canvas and every section of your Value Proposition Canvas contains assumptions that need to be true for the idea to work.

Start by going through each building block and asking one question: “What needs to be true here for our model to work?”

For the Value Proposition Canvas, focus on customer jobs, pains, and gains. Are these the right jobs? Are these pains painful enough to drive action? Do customers actually value these gains, or did you project your own priorities onto them?

For the Business Model Canvas, work through every block. Key areas where assumptions hide:

Write each assumption as a clear statement. Not “customers” but “procurement managers at food processing companies with 200+ employees will prioritize reducing packaging waste over cost savings.” The more specific the assumption, the easier it is to test.

A typical mapping session produces 15 to 30 assumptions. That is normal. You are not going to test all of them. The next step decides which ones matter.

Step 2: Prioritize by risk (which assumption kills the model?)

This is the step most guides skip entirely. And it is the step that determines whether your testing produces real evidence or just activity.

Not all assumptions are equal. Some, if wrong, are minor inconveniences. Your channel assumption is wrong? You find another channel. Your cost assumption is off by 10%? You adjust your pricing. But some assumptions, if wrong, mean the entire business model collapses. Those are the ones you test first.

I use a simple 2x2 matrix for assumption prioritization:

The top-right quadrant is where your first experiments should focus. High importance, low evidence. These are the assumptions where you are mostly guessing about something that could destroy the project.

In practice, I see teams resist this. They want to test the assumptions in the bottom-left: low importance, low evidence. Why? Because those are often the easiest to test. A quick survey. A simple prototype. Fast results. But fast results about things that do not matter are worse than no results at all. They create a false sense of progress.

A B2B industrial company I worked with had 22 mapped assumptions. After prioritization, three stood out as model-killers: the assumption that plant managers would pay for predictive maintenance data (willingness to pay), the assumption that existing sensor data was accurate enough to power the algorithm (feasibility), and the assumption that IT departments would approve a third-party data connection (organizational buy-in). Everything else was secondary. We tested those three first. The third one failed. IT departments were not willing to open their networks. That killed one version of the model and redirected the team to an offline solution, saving months of development time.

That is what assumption prioritization does. It points you at the experiments that actually change decisions.

Step 3: Choose the right experiment type

Once you know which assumption to test, you need to pick the right experiment. Different assumption types require different tests.

There are three categories of assumptions, and each maps to a different set of experiments:

Desirability assumptions (do customers want this?): Test with customer interviews, landing page tests, surveys, ad campaigns, concierge experiments, or pre-sales. These are the fastest and cheapest to test. Five to ten customer conversations can demolish or confirm a desirability assumption in a week.

Viability assumptions (can we make money?): Test with pricing experiments, letter of intent tests, pre-orders, financial modeling with real data, or willingness-to-pay interviews. These are harder because people lie about willingness to pay. The best evidence comes from situations where customers take a real action: signing a letter of intent, placing a pre-order, or choosing between pricing tiers.

Feasibility assumptions (can we build and deliver this?): Test with technical prototypes, supplier negotiations, proof-of-concept builds, or partner commitment letters. These are the experiments that feel most natural to engineering-driven companies, which is exactly why they get over-prioritized.

Matching the right experiment to the right assumption type is critical. I cover this in depth in the experiment library: which experiment type for which assumption.

The common mistake is using the same experiment type for everything. Teams that love building prototypes test every assumption with a prototype. Teams that love customer interviews test every assumption with interviews. Neither approach works. A customer interview cannot validate a technical feasibility assumption. A prototype cannot validate willingness to pay. Match the experiment to the assumption.

For manufacturing and industrial B2B, some standard experiments do not apply. You cannot A/B test a production line. You cannot run a landing page test for a €2 million industrial system. But you can test with letters of intent, supplier feasibility conversations, and pilot agreements with lighthouse customers. The principle is the same. Only the experiment format changes.

Step 4: Set fail criteria before you start

This is the most important step in the entire process. It is also the most skipped.

Fail criteria are specific, measurable thresholds that you define before running the experiment. They answer one question: what result would tell us to stop?

Not “what does success look like.” Fail criteria. What would make us kill this direction?

The reason this matters: after running an experiment, teams are emotionally invested. They spent time, effort, and sometimes budget. They want the idea to work. Without predefined criteria, the interpretation of results becomes a negotiation. “22% is close to 30%.” “Only 3 out of 15 were interested, but they were really interested.” “The data is mixed, but the trend is positive.”

I have watched this negotiation happen in dozens of sessions. It always ends the same way: the team convinces itself the results are good enough, and the project continues without real evidence.

Here is how to set fail criteria that hold:

Be specific. Not “positive customer response” but “at least 5 out of 20 target customers say they would pay €X in a structured interview.”

Be measurable. The result should be a number or a clear yes/no, not a qualitative impression.

Get agreement before you start. Everyone on the team, including the project sponsor, agrees to the criteria before the experiment runs. Write it on a whiteboard. Put it in the experiment document. Make it visible.

Set the bar honestly. The criteria should reflect what you actually need for the business model to work, not what feels achievable for a first test. If your model requires 10% conversion and your experiment shows 3%, that is a fail. It does not matter that “it was just the first test.”

I go much deeper into how to set different types of fail criteria in how to set fail criteria for business experiments.

Example fail criteria for different experiment types:

The fail criteria are what turn an experiment from an activity into a decision tool.

Step 5: Run the experiment with discipline

This step sounds obvious. It is not.

Running an experiment with discipline means: testing with the right people, collecting the data you said you would collect, and not changing the experiment design halfway through.

Three rules that keep experiments honest:

Test with real target customers. Not colleagues. Not your network. Not people at a trade show who stopped by your booth because they know you. Real prospects who match your customer segment and have no relationship with your company. If you cannot find them, that tells you something about the segment.

Collect the data you defined in advance. Do not add new metrics after seeing early results. If your fail criterion is based on conversion rate, collect conversion data. Do not suddenly pivot to measuring “engagement” because the conversion numbers look bad.

Do not change the experiment after it starts. If you realize halfway through that the experiment design is flawed, finish it, document what went wrong, and design a better one. Modifying the test while it is running invalidates whatever data you already collected.

In B2B and manufacturing contexts, running experiments takes longer because customer access is harder. Getting 15 interviews with procurement directors at industrial companies takes more effort than getting 15 interviews with consumers. Plan for it. Build in two to four weeks for B2B customer access instead of the one week that works in consumer markets. The discipline is the same. Only the timeline changes.

Step 6: Capture learnings (not just data)

An experiment produces data. But data is not learning.

Learning happens when you interpret the data against your original assumption and fail criteria, then document what you now know that you did not know before. This step is where most teams rush. They look at the numbers, make a quick judgment, and move on.

Slow down. For each completed experiment, document four things:

What did you assume? Restate the original assumption exactly as you wrote it in Step 1.

What did you find? Report the actual data. Numbers, not impressions. “7 out of 15 interviewees described the problem unprompted” not “most people seemed to relate to the problem.”

Does the evidence pass or fail your criteria? This should be a straightforward comparison. You set the threshold in Step 4. The data either meets it or it does not.

What did you learn that you did not expect? This is the most valuable part. Every experiment reveals something beyond the original question. A customer mentions a pain you had not considered. A pricing test shows that customers would pay more for a different version of the product. A feasibility test reveals a technical dependency nobody had mapped. Capture these. They often become the inputs for your next round of assumption mapping.

Build a simple experiment log. It does not need to be complicated:

This experiment log feeds directly into innovation accounting, which is how you report progress to leadership in terms they understand: risk reduced, evidence gathered, decisions made.

This documentation matters beyond the immediate experiment. When you run your next round of tests, or when leadership asks how the project is progressing, you have a clear evidence trail. Not opinions. Not PowerPoint narratives. Actual evidence linked to specific decisions.

Step 7: Make the decision: pivot, persevere, or kill

Every experiment should end with a decision. Not “interesting, let’s keep going” but a clear choice based on evidence.

There are four possible outcomes:

Persevere. The evidence supports the assumption. Move on to testing the next riskiest assumption on your prioritized list. Do not celebrate too early. One passed experiment does not validate a business model. It validates one assumption out of many.

Pivot. The evidence contradicts the assumption, but the learnings suggest a different direction that might work. Modify the specific building block of your Business Model Canvas or Value Proposition Canvas that the assumption belongs to, and start the process over from Step 1 for that modified element.

Kill. The evidence contradicts a core assumption and there is no viable alternative direction. This is the hardest decision, especially in corporate environments where projects have sponsors, budgets, and teams attached. But killing an idea based on evidence after two weeks of testing is infinitely better than killing it after 18 months of development.

The decision between pivot, persevere, and kill is where politics usually takes over from evidence. I cover how to handle that dynamic in pivot or persevere: how to make the decision.

Run another experiment. Sometimes the result is inconclusive. The experiment was not designed well enough, or the sample size was too small. That is fine. Redesign the experiment and run it again. But be honest about why you are re-running it. “The data was genuinely inconclusive” is a valid reason. “We did not like the answer” is not.

This is where the process loops. After each decision, you return to your assumption map (Step 2), pick the next highest-priority assumption, and repeat the cycle. Each loop reduces uncertainty. After three to five loops, you either have enough evidence to move to a business case, or you have learned that the idea does not work in its current form.

That learning is not failure. That is the entire point of testing business ideas.

The full process at a glance

The process is not complicated. What makes it work is doing every step in order and not skipping the ones that feel uncomfortable, especially Steps 2 and 4. Assumption prioritization and fail criteria are where the real value lives. Skip those and you are running experiments that feel productive but change nothing.

For B2B teams running this process, customer discovery interviews for B2B covers how to get access to the right people and ask the right questions in multi-stakeholder buying environments.

If you want to see how this assumption testing process fits into the broader methodology alongside the Business Model Canvas and Value Proposition Canvas, start with the testing business ideas overview. For teams comparing this approach to Lean Startup or design thinking, see testing business ideas vs Lean Startup.

For organizations managing multiple ideas at different stages, innovation portfolio management covers how to use evidence from assumption testing to make investment decisions across an entire portfolio. And if you are wondering whether your organization is ready to run this kind of disciplined testing process, the innovation readiness assessment is a good starting point.

Written by

Ton van der Linden

Founder and strategic innovation advisor. 25+ years in strategy, innovation and marketing, 100+ sessions with teams designing and testing business ideas at 50+ companies, and the only official Strategyzer coach in the Netherlands since 2016.

More about me →