Testing Business Ideas: 44 experiments, 100+ sessions (2026)

I know because I’ve watched it happen hundreds of times.

They run experiments that confirm what they already believe. They test the easy assumptions instead of the dangerous ones. They skip the one step that makes everything else worthwhile, setting fail criteria before the experiment starts. And they call it “validated” because they got positive results from an experiment designed to produce positive results.

Over the past 10 years, I have facilitated more than 100 sessions where teams test business ideas with manufacturing companies, industrial B2B enterprises, chemical suppliers, agricultural equipment makers, and leadership teams building new product lines with real budgets and real consequences. I’ve seen experiments that saved companies millions by killing a doomed project early. And I’ve seen experiments that wasted months because the team learned nothing from them.

The difference is never the experiment itself. It’s how you set it up. Which assumption you test. What you decide before you start. And what you do with the results.

This guide covers how to test business ideas properly, not the book-summary version you’ve read elsewhere, but the field version I’ve developed from actually doing it. With specific methods for B2B, industrial, and manufacturing contexts where standard startup advice falls apart.

If your Business Model Canvas or Value Proposition Canvas is complete and you’re wondering “now what?” — this is the answer.

What Does Testing Business Ideas Actually Mean?

Testing business ideas means turning assumptions into evidence before committing major resources. It’s the practice of systematically identifying what you believe about your business model, prioritizing the riskiest beliefs, and running targeted experiments to see if reality agrees with you.

Alexander Osterwalder and David Bland formalized this in their 2019 book Testing Business Ideas, building on Steve Blank’s customer development work and Eric Ries’s lean startup methodology. Their contribution was making experiment selection systematic, creating a library of 44 experiments organized by cost, time, and evidence strength. (For a detailed comparison of these approaches, see Testing Business Ideas vs Lean Startup.)

But testing business ideas is older than any methodology. It’s what smart entrepreneurs have always done: find out whether customers want something before building it.

The problem isn’t that teams don’t know they should test. Every innovation director I meet understands the principle. The problem is execution. The methodology sounds simple on paper:

1. Map your assumptions
2. Prioritize by risk
3. Choose an experiment
4. Run it
5. Learn from the results

In practice, corporate teams face a reality that most guides ignore: political pressure to show progress, budgets that require committee approval before you can spend €500 on a prototype, customers who are difficult to access for interviews, and executives who interpret negative results as failure rather than learning.

This guide addresses that reality.

What testing is NOT

Testing is not market research. Market research tells you what the market looks like. Testing tells you whether your specific idea works. A market report showing €3.2 billion in demand means nothing if your particular product doesn’t solve a problem customers actually have.

Testing is not building and launching. “We’ll test it in the market” is the most expensive way to learn. By the time you’ve built, marketed, and launched, you’ve spent months and potentially hundreds of thousands of euros. Testing should happen before that commitment, not instead of it.

Testing is not asking people what they think. Opinions are not evidence. Rob Fitzpatrick made this point brilliantly in The Mom Test: if you ask someone “would you buy this?” you’ll get a polite yes that means nothing. Evidence comes from behavior — what people do, not what they say they’ll do. Clayton Christensen’s Jobs to Be Done research reinforces this: customers don’t buy products — they hire them to make progress. The question isn’t “do you like this?” but “would you switch from what you’re doing now?”

How testing connects to the Business Model Canvas and Value Proposition Canvas

Testing doesn’t start from nothing. It starts from your canvases.

Your Business Model Canvas contains assumptions across nine building blocks; customer segments, value propositions, channels, revenue streams, key resources, key activities, key partnerships, cost structure, and customer relationships. Each of those blocks is a hypothesis until proven otherwise.

Your Value Proposition Canvas zooms in on two of those blocks with more detail; the customer jobs, pains, and gains you believe exist, and the products, pain relievers, and gain creators you intend to deliver.

The natural flow is: design your business model (BMC) → deepen your understanding of customer value (VPC) → test whether your assumptions are actually true (TBI). That’s the sequence I follow in every innovation engagement. The canvases give you the map. Testing gives you the territory.

Without the canvases, teams test random things. Without testing, canvases are educated guesses. You need both.

I regularly see teams that have beautifully completed canvases, the kind that look great in presentations, but have never tested a single assumption written on them. The canvas gave them confidence. But confidence without evidence is just optimism in disguise.

Why Most Teams Skip Testing (and What It Costs)

About 42% of startups fail because they build products nobody wants. That statistic comes from CB Insights, and it hasn’t changed much in a decade. In corporate innovation, the numbers are similar. I’ve seen internal research from two multinationals showing that 65-75% of innovation projects fail to reach market or fail to hit targets within two years of launch.

The irony is that most of these failures were preventable. The assumptions that killed the projects were testable. Nobody tested them.

Why testing gets skipped

Overconfidence. The team has deep domain expertise. They know their market. They’ve talked to a few customers. They’re sure it’ll work. This is the most dangerous starting point for innovation, just enough knowledge to feel confident, not enough to question your own assumptions.

I worked with a team at an industrial components manufacturer that had 30 years of market experience. They were developing a new product line based on what they were certain customers wanted. The initial assumption: customers would pay a 25% premium for a modular version of their standard product. They were so confident they skipped testing and went straight to tooling. Nine months and €380,000 later, the first customer conversations revealed that modularity wasn’t the pain point. Customers wanted faster delivery, not flexibility. The product eventually found a market, but at a 15% discount with completely different positioning. The testing that could have caught this would have cost about €8,000 and four weeks.

Time pressure. “We don’t have time to test, we need to launch by Q3.” I hear this in almost every engagement. The assumption is that testing slows you down. The reality is that testing the wrong idea fast is slower than testing the right idea at the right pace. Two weeks of experiments can save six months of building the wrong thing.

Political dynamics. In corporate environments, experiments can produce politically inconvenient results. A negative result means someone’s project gets questioned. A positive result justifies continued investment. When careers and budgets are at stake, the incentive is to design experiments that confirm rather than challenge.

The build instinct. Engineers want to engineer. Developers want to develop. Product teams want to ship. Testing feels like not making progress. The team wants to build something tangible, not run experiments that might tell them to build something different.

What skipping testing actually costs

The numbers are consistent across contexts. Testing a business assumption with interviews and lightweight experiments costs between €2,000 and €15,000 and takes two to six weeks. Building a product based on untested assumptions costs €100,000 to €2M+ and takes six to eighteen months.

The ratio is roughly 100:1. For every euro you spend testing, you save up to a hundred euros in avoided waste. Not always. Sometimes the assumptions are right and you could have just built it. But you don’t know which time that is until after the fact.

How to Test Business Ideas: The Step-by-Step Process

Here’s the process I use with clients. It’s informed by Osterwalder, Blank, Ries, and Fitzpatrick, but adapted from hundreds of real sessions where I’ve seen what actually works versus what looks good in a textbook. (For a deeper walkthrough with templates, see How to Test Business Assumptions: The Step-by-Step Process.)

Step 1: Map your assumptions

Every business idea is built on assumptions. Your Business Model Canvas is full of them. Your Value Proposition Canvas is full of them.

“Customers have this pain.” Assumption. “They’ll pay this much.” Assumption. “We can deliver through this channel.” Assumption. “This partnership will give us distribution.” Assumption.

The first step is making those assumptions explicit. I do this by going through the canvas block by block and asking: “What do we believe but don’t yet know for sure?”

In a typical session, a team identifies 25-40 assumptions. That sounds overwhelming, but most of them are low-risk. You know they’re true because you have evidence already. The next step sorts them.

Step 2: Prioritize by risk

Not all assumptions are equal. Some are dangerous, if they’re wrong, the entire business model collapses. Others are inconvenient, if they’re wrong, you’ll need to adjust but you can recover.

I use a simple two-axis framework:

• Importance: How critical is this assumption to the business model? If it’s wrong, does the whole thing fail?
• Evidence: How much do we actually know? Do we have data, or are we guessing?

High importance + low evidence = test this first.

The assumptions in the upper-left corner, critically important and completely untested, are the ones that kill projects. These are where you start.

I worked with a team developing a subscription service for industrial spare parts. They had 32 assumptions. We prioritized and found that the number-one risk was willingness to switch from their current pay-per-order model. Everything else in their business model depended on customers accepting a subscription. That one assumption had never been tested with a single customer. They had spent four months on the technology platform.

We tested the subscription assumption in two weeks using letters of intent with five existing customers. Three said no. That was the answer they needed, before they built a platform for a business model their customers didn’t want.

Step 3: Choose the right experiment

Not every assumption needs the same type of experiment. The key is matching the experiment to what you need to learn. I organize experiments into three categories based on the strength of evidence they produce:

Discovery experiments — Learn about the problem. These produce insights, not proof. – Customer interviews (face-to-face, 45-60 minutes) – Customer observation (watching people work in their context) – Desk research (market reports, competitor analysis, patent searches)

Discovery experiments are cheap and fast. They’re the starting point for testing assumptions about customer needs, pains, and jobs. But they produce weak evidence; what people say, not what they do. In B2B, customer interviews require a different approach than what most books describe.

See Customer Discovery Interviews for B2B.

Validation experiments — Test whether customers will take action. These produce behavioral evidence. – Landing pages with sign-up forms (does anyone click?) – Letters of intent (will B2B customers commit on paper?) – Concierge MVP (deliver the value manually before building automation) – Wizard of Oz (the customer sees a product, but you’re operating it manually behind the scenes) – Pre-orders (will they pay before you build?)

Validation experiments cost more and take longer, but they produce stronger evidence. A signed letter of intent from a procurement director is worth more than a hundred “yes, we’d be interested” responses in interviews.

Confirmation experiments — Prove that the model works at scale. – Pilot programs with real customers – A/B tests on pricing, positioning, or features – Limited launches in controlled markets – Beta programs with usage tracking

Confirmation experiments are the most expensive and time-consuming. Only run them after discovery and validation have given you confidence. Too many teams jump straight to pilots, the most expensive type of experiment, without doing the cheaper experiments first.

Step 4: Set fail criteria BEFORE you start

This is the single most important step in the entire process. And it’s the one most teams skip.

Fail criteria define the minimum outcome that would convince you the assumption is wrong. Not success criteria. Fail criteria. The distinction matters.

Success criteria create a slippery slope. If your target is 30% conversion and you get 28%, someone on the team will argue “that’s close enough.” If your target is 50 sign-ups and you get 43, someone will say “the weather was bad that week.” Success criteria get negotiated upward after the results come in.

Fail criteria work differently. They define the floor: “If fewer than 5 out of 20 potential customers agree to a pilot, we will stop this project.” That’s unambiguous. Before the experiment runs, everyone agrees on what “bad enough to stop” looks like. After the results come in, the number either crosses the line or it doesn’t.

Three methods for setting fail criteria:

Early adopter benchmarks. Early adopters (the people who actively want a solution) should respond at high rates. If your target customers are early adopters and fewer than 60-70% show interest, you have a problem. The mass market will respond at a fraction of the early adopter rate.

Industry analogs. What conversion rates are normal for your type of offering? B2B landing pages convert at 2-5%. SaaS free trials convert at 3-8%. B2B pilot programs convert to contracts at 40-60%. Use these benchmarks as your fail line.

Back-of-napkin profitability. Calculate what conversion rate you need for the unit economics to work. If you need 15% of your target market to sign up to break even, and your experiment shows 3% interest, the math doesn’t work.

Set these before the experiment starts. Write them down. Get team agreement. This one practice has saved more projects and killed more doomed ones than any other technique I use.

For more on this, see How to Set Fail Criteria for Business Experiments.

Step 5: Run the experiment

Run it. Actually run it. With real customers.

Not with colleagues. Not with your boss. Not with your spouse. With the actual people who would buy the product, use the service, or approve the purchase order.

This is where I see corporate teams stall. “We can’t approach customers yet — the product isn’t ready.” “We need legal approval to contact prospective customers.” “The sales team won’t give us access to their accounts.”

These are real obstacles, but they’re solvable:

• Approach ex-customers or prospects who didn’t buy
• Partner with the sales team; frame it as market intelligence, not selling
• Use industry events, trade shows, or LinkedIn to find the right profiles
• Start with five conversations, not fifty

One good interview with the right person is worth more than a hundred survey responses from the wrong audience.

Step 6: Capture learnings

After each experiment, document three things:

1. What did we learn? Not what happened, but what does it mean?
2. What was surprising? The surprises are often more valuable than the expected results.
3. What should we test next? Every experiment should either close a question or open a better one.

Use an experiment canvas to track this. The canvas has eight fields: tested assumption, impacted business model block, cohort, experiment design, fail criteria, timebox, result, learning, and decision. It takes ten minutes to fill in after an experiment and it prevents the team from losing insights in email threads.

Step 7: Make the decision

This is where it gets hard.

Based on the results, you have four options:

Persevere — The evidence supports the assumption. Continue building on this direction.

Pivot — Part of the model works, but a key assumption is wrong. Change one element: the customer segment, the value proposition, the channel, the revenue model, and test again. A pivot is not failure. It’s a data-driven directional change.

Stop — The evidence consistently shows this won’t work. The customer doesn’t have the pain. They won’t pay the price. The channel doesn’t reach them. Stopping is the hardest decision in corporate innovation, but it’s also the most valuable. Killing a doomed project early frees resources for ideas that can work.

Scale — Rare after early experiments, but sometimes the evidence is so strong that you can move directly to scaling. This usually happens when validation experiments produce revenue (pre-orders, paid pilots, signed contracts).

The decision should be based on data, not politics. That’s why fail criteria matter. They make the decision transparent.

For more on making this decision in corporate environments, see Pivot or Persevere: How to Make the Decision.

The Experiment Library: Which Experiment for Which Situation

Osterwalder’s experiment library contains 44 experiments. That’s useful but overwhelming. In practice, I find that most teams need to know about ten experiment types and match them to what they’re testing.

The key principle: start with cheap, fast experiments that test desirability (do they want it?), then move to more expensive experiments that test viability (will they pay?) and feasibility (can we build it?).

I see teams jump to pilot programs as their first experiment. That’s like doing a clinical trial before checking whether the drug dissolves in water. Start cheap. Learn. Then invest.

For the full breakdown, see The Experiment Library: Which Experiment Type for Which Assumption.

Testing Business Ideas in B2B and Industrial Contexts

This is where most testing guides fall apart. They assume you’re building software, iterating weekly, and A/B testing with thousands of users. Industrial B2B doesn’t work that way.

You can’t iterate weekly on a physical product

When your product is a packaging machine that costs €800,000 and takes 14 months to manufacture, “build-measure-learn” loops need to look very different. You can’t release a minimum viable packaging machine.

What you can do: – Test desirability with interviews and letters of intent before engineering starts – Use digital mockups and 3D renders as “prototypes” for customer feedback – Run pilot installations with a manually supported version (concierge MVP adapted for hardware) – Test pricing and willingness-to-pay with structured conversations, not surveys

The experimentation cycle is longer (weeks instead of days) but the principles are identical. Test the riskiest assumption first. Set fail criteria. Make data-driven decisions.

Long buying cycles mean long experiment cycles

A B2B equipment purchase can take 6-18 months from first contact to signed contract. Your experiment design needs to account for this:

• Compress the feedback cycle by testing with customers who are already in the evaluation phase, not starting from scratch
• Use letters of intent as a fast proxy for purchase decisions — they don’t require procurement approval but they signal real commitment
• Run parallel experiments rather than sequential ones — test three assumptions at once with different customer cohorts

Multiple stakeholders, conflicting evidence

In consumer testing, you ask one person and get one answer. In B2B, you interview the plant manager, the procurement officer, the finance director, and the end user and get four different answers.

This is not a bug. It’s the reality of multi-stakeholder buying. Your evidence needs to account for it:

• Interview all relevant stakeholders, not just the one who’s friendly
• Map evidence by stakeholder role, not by individual
• Look for convergence: where do stakeholders agree?
• Identify dealbreaker stakeholders: whose “no” kills the deal regardless of what others say?

I worked with a company testing a predictive maintenance service. The operations director loved it. The IT director blocked it. Integration with their existing SCADA system would take six months and three FTE. If they’d only interviewed operations, they would have had false confidence. The real experiment was testing IT feasibility, not customer desirability.

Testing without hurting the brand

Corporate teams face a constraint that startups don’t: brand reputation. An established manufacturer can’t run a half-baked experiment that makes them look unprofessional to existing customers.

I’ve used several techniques to manage this:

Informed consent. Tell customers upfront that you’re testing a concept. Most appreciate being asked for input. “We’re exploring a new service offering and we’d value your perspective” is flattering, not damaging. In my experience, customers who participate in testing become more loyal, not less, they feel like co-creators.

The innovation sandbox. Test with a limited, controlled group of customers who’ve agreed to participate in early-stage experiments. One agricultural equipment client I worked with created a “Customer Innovation Panel” of twelve customers who agreed to evaluate new concepts quarterly. The panel gave them a repeatable testing channel without risking the broader brand.

White label testing. For ideas that are genuinely risky to the brand, test under a different name. A chemical supplier I worked with tested a digital ordering platform under a neutral brand before connecting it to their main company name. The test revealed critical UX issues that would have damaged their reputation if they’d launched under the corporate brand.

Alpha/beta framing. Position the experiment as an early version. Customers understand “beta.” They expect rough edges and are willing to provide feedback rather than judge. Gmail was in beta for five years. In B2B, even calling something a “pilot program” signals that imperfections are expected.

The key insight: brand protection and experimentation are not in conflict. They’re in tension, and that tension is manageable with the right framing.

For the full guide, see Testing Business Ideas in Manufacturing and Testing Business Ideas for B2B.

The Mistakes I See Over and Over

After 100+ sessions, the patterns are depressingly consistent. Here are the ones that waste the most time and money.

Mistake #1: Testing the easy assumptions

The assumption “customers have this pain” is usually the least risky thing on your canvas. You probably chose the idea because you’ve seen the pain. The dangerous assumptions are further down the model: “customers will switch from their current supplier,” “they’ll pay €15,000/year for this,” “we can deliver with our current team.” Teams test what’s comfortable, not what’s critical.

I once ran a session where the team had designed eight experiments, all testing customer desirability. “Does the customer have this problem? Does the customer want this feature? Would the customer prefer version A or B?” All useful questions. But the riskiest assumption on their canvas, whether their logistics partner could deliver within the 48-hour window the value proposition required, hadn’t been tested at all. They’d been running experiments for six weeks and hadn’t addressed the thing most likely to sink the project. We shifted the next experiment to a logistics feasibility test. The partner couldn’t do 48 hours. That one finding changed the entire product design.

Mistake #2: Not setting fail criteria

I’ve already covered this, but it’s the number-one mistake and it deserves repetition. Without fail criteria, every experiment produces a “pass.” 28% conversion? “Close to our 30% target.” Three out of twenty customers interested? “Three is a start.” Fail criteria force honesty.

Mistake #3: Confirmation bias in experiment design

Designing an experiment to confirm what you already believe is human nature but terrible science. Asking customers “would you be interested in a solution that saves you €50,000 per year?” is not a test. Of course they’re interested. The test is whether they’ll take action, sign a letter of intent, agree to a pilot, allocate budget.

Mistake #4: Testing with the wrong audience

Your colleagues are not your customers. Your boss is not your customer. Even your sales team’s opinion is not evidence, they know what customers say, not necessarily what customers do. Test with the actual people who will make or influence the purchase decision.

This happens more often than you’d think in corporate innovation. I worked with a team that had “validated” their concept by presenting it at three internal innovation board meetings. Senior leaders said it was promising. The team reported it as validated. But not a single person who would actually buy or use the product had been consulted. When we ran our first five external interviews, the feedback was completely different from what the internal audience had predicted. The innovation board was evaluating the idea as a strategic concept. Customers evaluated it as a procurement decision. Different criteria entirely.

Mistake #5: Running too many experiments at once

Three experiments in parallel is productive. Eight is chaos. When you’re running too many experiments simultaneously, you lose the ability to make sense of results and act on them. Prioritize ruthlessly, run two or three, learn, decide, then run the next batch.

Mistake #6: Designing experiments to prove you’re right

This is the political version of confirmation bias. In corporate environments, the person championing the idea has career incentives to show positive results. The experiment gets designed (sometimes unconsciously) to maximize the chance of a “yes.” Independent experiment design, where someone other than the idea champion designs the test, is one of the most effective countermeasures.

For more on these patterns, see Business Experiment Mistakes: Why Most Teams Learn Nothing from Testing.

Innovation Accounting: Measuring What Matters

Traditional KPIs (revenue, ROI, market share) are meaningless for early-stage innovation. By definition, a new business idea has zero revenue, infinite negative ROI, and no market share. Measuring it on those terms guarantees it looks like a failure.

Innovation accounting provides an alternative measurement system:

Risk reduction. How much uncertainty have we eliminated? If we started with 30 untested assumptions and have now validated 18 of them, we’ve reduced risk by 60%. That’s progress worth measuring.

Learning velocity. How fast are we learning? If we’re running two experiments per week with clear results, we’re learning faster than a team running one experiment per month. Speed of learning, not speed of building, is the relevant metric.

Evidence strength. Not all evidence is equal. Opinions are weak evidence. Stated intentions are moderate evidence. Actual behavior (purchases, sign-ups, signed commitments) is strong evidence. Track the progression from weak to strong evidence over time.

Cost per learning. How much did each validated or invalidated assumption cost? If an interview-based experiment cost €1,500 and answered a critical assumption, that’s efficient. If a six-month pilot cost €200,000 and answered the same question, that’s expensive learning.

These metrics are what innovation directors should be reporting to boards, not revenue projections for something that doesn’t exist yet, but evidence of systematic risk reduction and learning.

For more detail, see Innovation Accounting: How to Measure What Matters.

When Testing Business Ideas Goes Wrong

I should be honest: testing doesn’t always produce clear answers. Sometimes the results are ambiguous. Sometimes the fail criteria need adjustment because the original benchmarks were wrong. Sometimes a great experiment design produces data that you can’t interpret cleanly.

Three situations where I’ve seen testing go wrong:

False positives. Customers say yes in interviews but don’t follow through with behavior. This is extremely common in B2B where a manager says “we’d definitely use that” but never gets budget approval. The fix: only count behavioral evidence (commitments, money, time invested), not verbal interest.

False negatives. The experiment says no, but the real problem was the experiment design, not the idea. You tested with the wrong audience, asked the wrong question, or ran the experiment for too short a period. The fix: before killing an idea based on a negative result, run one more experiment with a different design. If both say no, believe them.

Analysis paralysis. The team keeps running experiments because the results are never “conclusive enough.” Eight experiments in and they still haven’t committed to building or stopping. At some point, you have to decide with the best available evidence. Perfect information doesn’t exist. Three good experiments with consistent results are enough to act on.

Testing is a discipline, not a guarantee. It dramatically improves your odds, but it doesn’t eliminate all risk. What it does is replace the most expensive form of testing (building the wrong thing) with the cheapest form (running targeted experiments before you build).

Frequently Asked Questions

What are the testing business ideas experiments?

The experiments range from low-cost discovery methods to high-investment confirmation tests. Common experiments include customer interviews, landing page tests, letters of intent, concierge MVPs (delivering value manually), Wizard of Oz tests (manual backend with automated frontend), pre-orders, prototypes, A/B tests, and pilot programs. The key is matching the experiment to the assumption you’re testing — desirability experiments first (do they want it?), then viability (will they pay?), then feasibility (can we build it?). Start with the cheapest experiment that can answer your most important question.

How do you test a business idea before launching?

Start by identifying the assumptions in your business model; what you believe but haven’t proven. Prioritize the riskiest ones (critical to success + lowest evidence). Choose a cheap, fast experiment to test each assumption. Set fail criteria before you run the experiment. Run it with real potential customers, not colleagues. Capture learnings. Then decide: persevere, pivot, or stop. The whole cycle for one assumption takes two to six weeks and costs €2,000-€15,000. Far less than building and launching something customers don’t want.

What is the best way to validate a business idea?

There is no single best way. The right approach depends on what you’re validating and who your customer is. For B2B, I recommend starting with five to ten customer interviews to test whether the problem exists, then moving to letters of intent or paid pilot proposals to test whether customers will commit resources. For consumer products, landing page tests and pre-orders are effective early validators. The best validation always tests behavior rather than opinions. People saying “I’d buy that” is interesting. People signing a letter of intent or placing a pre-order is evidence.

How do you test business model assumptions?

Map every assumption in your Business Model Canvas explicitly. Write each one on a sticky note. Classify each by importance (how critical to the model?) and evidence (how sure are we?). Test the high-importance, low-evidence assumptions first. For each, choose an experiment type that matches the assumption: interviews for customer pain assumptions, letters of intent for willingness-to-pay assumptions, prototypes for feasibility assumptions. Set fail criteria before running the experiment. Document results on an experiment canvas.

What is the difference between testing and validating?

In practice, people use these terms interchangeably, and that’s fine. If you want a distinction: testing is the activity (running an experiment), and validation is the outcome (confirming that an assumption holds true). You test a hypothesis; the result is either validation (the assumption is supported) or invalidation (the assumption is wrong). Invalidation is not failure. It’s learning that prevents you from building on a flawed foundation. Both outcomes are valuable.

How do you know when to pivot or persevere?

By comparing experiment results against your pre-set fail criteria. If the results fall below your fail line, the assumption is invalidated, time to pivot or stop. If the results meet or exceed your criteria, persevere. The decision is hard when results are close to the line, which is why setting fail criteria before the experiment matters. In corporate environments, the pivot decision also involves organizational politics, I recommend building the decision process into the project governance from day one, not waiting until results come in. For more, see Pivot or Persevere: How to Make the Decision.

What is an experiment canvas?

An experiment canvas is a one-page tracking tool for documenting business experiments. It typically contains eight fields: the assumption being tested, which business model block it affects, the target cohort, the experiment design, the fail criteria, the time-box, the actual result, the key learning, and the decision (persevere, pivot, or stop). I use it after every experiment to ensure learnings aren’t lost. It takes ten minutes to complete and creates a permanent record of what you tested, what you learned, and what you decided. Over time, a stack of experiment canvases tells the story of how a business idea evolved from hypothesis to evidence.

How do you test business ideas with no budget?

Start with the experiments that cost nothing: customer interviews (you need time, not money), desk research (market reports, competitor analysis, patent searches), observation (visit customers, attend trade shows, watch how people work). Then move to very low-cost experiments: a simple landing page (€50-200 with Squarespace), social media posts testing messaging, or email outreach to gauge interest. In B2B, a letter of intent costs nothing but the conversation. The most expensive input in early testing is your time, not your budget.

What to Do Next

If your innovation project has untested assumptions (and it does) start here:

1. Go through your Business Model Canvas or Value Proposition Canvas. Mark every assumption with a confidence level: green (evidence), yellow (thin evidence), red (guess).
2. Pick the riskiest red. The assumption that is most critical to your model and least supported by evidence.
3. Design the cheapest experiment that could prove it wrong. Not the experiment that confirms it, the one that could kill it.
4. Set your fail criteria. Write them down. Get your team to agree. Before the experiment runs.
5. Run it. With real customers, not colleagues.

If you want a structured approach to assessing which assumptions matter most, download the Innovation Readiness Checklist. It walks through the questions most leadership teams skip.

And if you’d like to work through this with someone who has run these experiments hundreds of times in industrial B2B: Let’s talk. Book a (free) Strategy Call.