Rehearse Before You Commit – Testing the Assumptions That Get Expensive Later

Most bad business decisions are not wrong on the day they are made. They turn wrong later, once the commitment has grown large enough that unwinding it costs more than living with it. A founder signs a two-year lease. An agency rebuilds its whole delivery model around one flagship client. A product team ships nine months of work that solves a problem almost nobody had.

What makes that pattern frustrating is that the information needed to avoid it usually existed earlier. It just did not exist in a form anyone was willing to act on. Opinions are cheap and there are always plenty of them. Evidence costs time, and time feels like the one thing a growing company cannot spare, so teams substitute confidence for testing and hope the gap closes quietly.

The commitment curve nobody plots

Every decision has a point where changing your mind stops being cheap. Before that point, being wrong costs an afternoon. After it, being wrong costs a quarter, a team, or a relationship you cannot get back.

The trouble is that the curve is invisible in most businesses. In heavy industry it is easy to see, because it usually involves capital equipment and a shutdown, which is why manufacturers built an entire discipline around proving a process works before committing to it. Some run dedicated pre-production validation facilities where a process is rehearsed on real materials in a simulated environment, specifically so the first failure happens somewhere a failure is cheap.

In a service business or a startup, the same curve exists, but it hides in softer places: a hire, a positioning statement, a pricing page, a promise made in a sales call that the delivery team then has to honor for two years. Nobody schedules a shutdown for those. They simply become permanent by default, one small commitment at a time, and the cost of reversing them climbs quietly while everyone is busy.

That invisibility is the whole problem. If you cannot see where your decisions stop being reversible, you cannot know which ones deserve a test.

What makes a test worth running

Plenty of companies say they test things. Most of what gets called testing is closer to reassurance, designed so that the comfortable answer is the likely one. The difference between the two usually comes down to a handful of choices made before the test starts.

A test that reassures you	A test that tells you something
Asking friendly customers whether they would buy	Asking one customer to commit to something real now: a deposit, a calendar slot, a signature
Running it against your best-case client	Running it against the most awkward client on your books
Continuing until the result looks encouraging	Setting the stop date before you begin
Deciding afterwards what the outcome meant	Writing down in advance which result would kill the idea

The last row carries most of the weight. A test you were never going to act on is theatre, and expensive theatre at that, because it buys false confidence at the price of real time. Deciding the kill condition in advance is uncomfortable for exactly the reason it works: it removes the option of reinterpreting a bad result once you have seen it.

The second row matters nearly as much. Testing an idea against an imagined average customer tends to produce agreeable, useless results. Testing it against one real, difficult, specific case is where the surprises live, and surprises found early are the point of the exercise.

Why the culture usually blocks it

If this is obviously sensible, it is worth asking why so few companies bother. Stefan Thomke of Harvard Business School spent years on that question and concluded that the barrier is rarely tools or technology. In his work on building a culture of experimentation, he points out that for every online experiment that succeeds, close to ten do not, and that organizations built around efficiency and predictability tend to read those failures as waste rather than as information.

That reading is the real obstacle. A team rewarded for being right will avoid any process designed to prove it wrong. A team rewarded for learning quickly will run toward it. The difference shows up in how leaders react the first time a small test kills a favorite idea, which is a moment most founders remember more clearly than any strategy offsite.

Leaders also underestimate how closely people watch that moment. Whatever happens to the first person who brings back an inconvenient result sets the price of honesty for everyone else, and that price tends to hold for years.

A version you could run this quarter

You need one real case, one constraint you have been assuming away, and a deadline short enough that nobody can quietly turn the test into a project.

Pick the assumption that would be most expensive to get wrong, and design the smallest thing that could disprove it. Give it two weeks rather than a quarter, because a long test is usually a decision being postponed. Then hold yourself to the kill condition you wrote down at the start.

Companies that skip this step often discover the problem much later, when growth itself starts exposing the cracks, which is roughly the failure mode described in why fast-growing startups fail to scale.

The cost of finding out late is rarely dramatic. It will not make the news. It will just quietly be larger than it should have been, in a quarter when you could least afford it.