How to test business assumptions before they become expensive surprises

Some growth initiatives are not really initiatives. They are bets. They may have a business case, a project plan and management approval. The team may have completed a successful pilot. The dashboard may be green. Still, success depends on things that have not been established yet.

For example, the assumptions that customers change how they work; Sales gives the new offer enough attention; Existing capabilities can be stretched to support it; The business unit will take ownership; The company can deliver at the cost and scale assumed in the business case.

Usually, nobody has deliberately decided to gamble on these things. They have simply found their way into the plan as facts.
I call them hidden assumptions.

When an initiative depends on success-critical hidden assumptions, it becomes a hidden bet.
One case from my work illustrates the problem particularly well.

An industrial equipment manufacturer had developed a digital service that I will call Remote Uptime. Using equipment data, the service identified potential failures early and helped customers avoid unplanned downtime. The pilot results with six customers were encouraging.
The company also had advantages that a startup would envy. Thousands of machines were already installed at customer sites. It had long-standing customer relationships, an established salesforce and a large service organization.

The plan was to use this position to roll Remote Uptime out across the installed base within two years. At first sight, this looked like an execution challenge. Refine the product, prepare Sales, build the rollout plan and get moving.
The issue that I was called in to solve was not that the pilot had failed. It had done its job. It showed that Remote Uptime could create value for customers. The pilot showed: We can make Remote Uptime work. However, it did not show the pathway to Scaling-Up success.

When teams talk about testing business assumptions, the discussion usually starts with the market. Do customers have the problem? Will they buy? Who holds the budget? Is the price acceptable?

Remote Uptime had questions of this kind. But the assumptions that concerned me most were different. The company believed that because it owned the assets required for scaling, it could use them for the new business.

Take the installed base. On a strategy slide, thousands of machines at customer sites were an obvious advantage. In reality, the machines came from different generations. Data availability and quality varied. Installation effort varied. Some equipment needed considerable additional work before Remote Uptime could use its data reliably.

The service organization presented a similar issue. It was excellent at maintaining industrial equipment. Remote Uptime added software, data, alerts and support questions that crossed some of the existing organizational boundaries. Having a service network did not automatically mean having the delivery capability required for the new service.

Market access and delivery capability are two different things. Existing customer relationships, a strong brand and an installed base can get a new business into the room. They do not establish that the company can deliver the new value proposition once it gets there.
Sales brought another assumption into view. The account directors were positive about Remote Uptime. The issue was not lack of support. It was the sales system.

One visible sign of the issue was when ordinary account teams were asked to introduce the offer under normal commercial conditions, several still prioritized large equipment renewals.
Their targets made that the rational choice. This is why statements such as “Sales is aligned” tell me relatively little about scaling readiness. I want to know what people actually do when the new business competes with their existing priorities.

The company was not careless about risk. There was a business case, project governance and experienced managers reviewing the initiative. But risk analysis and assumption analysis start from different places. Conventional risk analysis asks what could go wrong with the plan. This works well when we understand the game.

We know how the business works and can identify what might disrupt execution.
For Remote Uptime, asking “What could go wrong with the rollout?” would have generated a perfectly respectable list: delays, cybersecurity problems, resource constraints, slow customer adoption.

But with beyond-Core growth, parts of the game may still be uncertain. There, another question is more revealing: What must be true for this plan to work?
For Remote Uptime, the installed equipment had to provide usable data at an acceptable cost.

Customers had to grant access. Account teams had to make the proposition a real priority. The service organization had to deal with new types of support requests without relying permanently on the original experts. Installation and support effort had to fit the subscription economics.

These assumptions had been present all along. They were simply hidden inside phrases such as “leverage our installed base” and “use the existing sales and service organization.”

Hidden bets are difficult to see. They often look like sensible plans. A green dashboard does not help if the assumptions underneath the plan remain invisible.

This is the problem I address with the Growth Opportunity Assumption Test (GOAT). It is a focused diagnostic applied to one growth initiative. The goal ist to find the few hidden assumptions that important enough to change what management should do next.

The key question is: What must be true for this initiative to become a business the company can own and scale — and what are we missing because we all look at the plan through the same familiar lens?
That takes the discussion beyond simple validation.

When we unpacked Remote Uptime, we found 31 assumptions. The number was not the interesting part. In fact, a long assumption list can become another form of bureaucracy. What mattered was identifying the assumptions that could break the scaling logic.
Those questions needed evidence before committing to the rollout. Questions like: Could account teams generate enough qualified customer access?

Was usable equipment data available across a sufficiently large share of the installed base?
Could installation and support be delivered at the cost assumed in the business case?
Could ordinary teams handle the service without the exceptional support that had made the pilot successful?

Once a hidden assumption is explicit, the test should follow from the claim. If the assumption is that the existing salesforce can take Remote Uptime to the installed base, asking Sales whether it supports the new service is a weak test.
Put the offer into the hands of ordinary account directors, alongside their normal targets and priorities, and observe what happens. That is how the sales issue became visible.

The same applies to delivery capability. If the assumption is that the existing equipment base can support Remote Uptime economically, testing a few carefully selected machines will not tell you enough.
Use representative equipment generations and record data availability, installation effort, manual intervention, support requirements and the exceptions that require expert help.

A technical test may tell you that something can be done. The business question is whether it can be done repeatedly at acceptable economics. And if the assumption concerns willingness to pay, enthusiastic pilot users are not enough.

Remote Uptime’s initial plant managers liked the service, but they did not necessarily own the budget and had received the pilot without paying for it.

The stronger test is a defined commercial offer taken into real approval processes because different assumptions need different evidence.

The common principle is that the test should get as close as reasonably possible to the behavior the future business will depend on.

Remote Uptime also sharpened my view on how to think about pilots. The usual statement that “pilots don’t scale” is too crude. A well-designed pilot can provide excellent evidence. The question is: evidence for what? Remote Uptime’s pilot established that the service could work and that customers could benefit from it.

That was valuable. It did not establish that the company could reproduce the result across different customers, machine generations and regions. And it certainly did not establish that the existing organization could deliver and support hundreds of implementations economically.

In practice, three different proofs are needed:
Pilot proof: Can we make it work and create the intended customer value?
Repeatability proof: Can we reproduce that result with other customers and under less protected conditions?
Scaling proof: Can the company sell, deliver, support and expand the business economically without exceptional intervention?

These are not three new stage gates. They are simply different questions requiring different evidence.

The problem starts when these three proofs are not seen in conjunction, for example when a pilot proof is used to justify a Scaling decision without the required scaling proof.

Pilot teams are usually very good at solving problems. That is part of their job. They find cooperative customers. Specialists join calls. Technical issues are escalated. Senior managers help remove internal barriers. Processes that do not yet exist are replaced by manual work. Remote Uptime was no exception.

The early pilot had dedicated engineering support and executive help when data-access problems appeared. Those conditions were useful for learning. But they were not representative of the planned business. So the closer the company came to a scaling decision, the more important it became to remove the special treatment.

My piece of advice is to use normal account teams, representative equipment, standard customer processes and the people who would really install and support the service. Then observe where the system holds and where it starts to strain. This is not about making the test artificially difficult. It is about understanding the business the company is actually preparing to build.

For Remote Uptime, this work showed that the original rollout plan was too optimistic in two important respects. Existing account incentives constrained commercial access, and delivery effort varied substantially across equipment generations. Neither finding invalidated the opportunity. But both mattered for the scaling decision.

There is a tendency to turn assumption testing into a pass/fail exercise: validate the assumption and continue; invalidate it and stop. Sometimes an assumption fails in a way that damages the opportunity fundamentally.
Then stopping may be the right decision. But that is not the purpose of the exercise. The purpose is to improve the next decision.

Otherwise, contradictory results may be seen as “valuable learning” while the original plan continues untouched.
The strength of evidence should also reflect the size of the commitment. Funding a learning cycle is different from hiring a permanent organization, building infrastructure and committing a revenue target to senior management.

What happens next depends on the evidence. If account incentives make Remote Uptime hard to sell through the existing channel, management can change the incentives or use a specialist sales team. If older equipment makes delivery uneconomic, the rollout can start with machine generations where the economics work. Missing capabilities can be built, acquired or sourced from a partner.

For Remote Uptime, the evidence pointed to a narrower first rollout, changes to the sales mechanism and further work on the delivery model.
At the same time, it made one thing equally clear: the originally planned broad rollout was not the right way to go until the company had evidence that the model could work at scale.

There is a broader management point behind this case. A conventional execution initiative operates mainly in a world the company understands. The task is to plan, resource, coordinate and execute. A growth bet still depends on important things that are not known. Both may appear in the same strategic portfolio. Both may have business cases, milestones, budgets and executive sponsors.

But they should not automatically be managed in the same way. The difficult cases are the hidden bets because nobody sees the need to manage them differently. The initiative looks sufficiently familiar. Assumptions become numbers in a business case or activities in a project plan. The organization moves into execution while some of the most important questions are still open.

GOAT helps make those questions visible before they become expensive.
The point in de-risking growth initiatives is getting enough evidence to make the next decision with confidence, rather than pretending we can prove the entire journey upfront.

Triple Win takes the argument one level further. The overarching question is no longer only how an individual team handles uncertainty. It is how a company recognizes these growth bets inside its normal strategy, portfolio and investment conversations and brings in the capabilities required to deal with them.

That includes Corporate Innovation, but in a different role from the one many companies have given it in the past. Its distinctive capability is not simply generating ideas or running pilots. It is knowing how to operate where important assumptions still need to become evidence.

The business remains responsible for the growth. Innovation capabilities help it deal with the uncertainty that comes with growth beyond the existing business.

Take one important growth initiative that currently appears ready for execution. Then ask: What must be true for this initiative to become a business we can own and scale?

The point is not to challenge them for the sake of challenging.

The point is to distinguish what the company knows from what it currently assumes.
Pay attention when the answers contain statements such as “Sales will…”, “customers should…”, “the BU can…”, “we already have…” or “our existing organization will…”. There may be excellent reasons to believe every one of them.

Remote Uptime had a good proposition, positive pilot customers, customer access and substantial corporate assets behind it. But delivery capability was a hidden assumption.

That was the hidden assumption worth finding before committing to the rollout. Because after finding out and changing the roll-out course accordingly, success could be achieved.