A growth initiative can reach budget approval with a polished business case, supportive pilot users, and no reliable evidence that that everything that must be true is supported by evidence. By the time the gap becomes visible, expensive surprise can become apparent.
Teams may have hired people, committed technology budgets, and promised revenue to senior leadership. Testing assumptions early prevents weak evidence from hardening into an expensive plan. Use this sequence before approving a major investment or rollout:
- Define the decision the evidence must support.
- Write down the assumptions required for the initiative to succeed.
- Prioritize assumptions by uncertainty, impact, and urgency.
- Design the smallest credible test for each priority assumption.
- Set evidence thresholds and decision rules before running the test.
- Run tests with the people and conditions that matter at scale.
- Update the initiative, investment, or stop decision from the results.
Lean Scaleup applies this logic to growth decisions so that leadership teams can assess initiatives using decision-grade evidence, rather than activity reports or confidence alone. To show how the method works, this article follows a composite example:
An industrial equipment manufacturer wants to launch Remote Uptime, a subscription service that predicts equipment failures and coordinates maintenance. Its pilot has produced positive comments from six plant managers. The proposed plan assumes the business can expand across the installed base within two years.
1. Define the decision before testing business assumptions
An assumption test must serve a decision. Without that connection, teams tend to collect interesting information that does not change funding, scope, or timing. Start by writing the decision in operational terms.
Specify the decision owner, date, available options, and commitment at stake. The options might be to invest in rollout, fund another validation stage, narrow the target segment, partner for delivery, or stop.
Record which commitments become difficult to reverse after the decision, including hiring, platform development, channel incentives, contracts, and public targets.This framing changes the testing plan.
A product team preparing another prototype needs different evidence from an executive committee considering a rollout organization.
A clear decision owner should also be named now since shared sponsorship often creates unclear accountability when evidence contradicts the original plan.
The practical issues are covered further in growth initiative decision ownership.
For Remote Uptime, the immediate decision is not whether predictive maintenance is an attractive market. It is whether the company should release the next tranche of funding for a multi-country commercial rollout. The business unit president owns the funding decision. The venture lead owns evidence production. Finance reviews the economic model, while service operations verifies whether delivery assumptions are realistic. These roles should not be merged into a vague steering committee mandate.
2. Identify the hidden assumptions behind the growth initiative
Bring together the business case, customer proposition, operating model, financial model, rollout plan, and current dashboard. Read each one as a set of claims that must remain true. Write each assumption as a falsifiable statement.
Include a defined actor, behavior, condition, and timeframe. For example: maintenance directors at multi-site manufacturers will sign a paid annual agreement after a limited technical evaluation. That can be tested. Customers value reduced downtime is too broad.
Look for assumptions in five areas:
- Customer behavior, including who pays and why they act now
- Market access, including channels and sales incentives
- Delivery capability, including data, people, partners, support, and compliance
- Economics, including price, cost to serve, retention, and working capital
- Corporate fit, including strategic sponsorship, business unit ownership, and portfolio conflicts
This is where corporate initiatives differ from independent startups. An external founder may need to prove demand and economics. An internal growth team must also prove that the corporation can sell, deliver, govern, and continue funding the business without the core organization suppressing it.
Do not treat an existing asset as accessible merely because the corporation owns it. The distinction between theoretical access and operational capability is examined in market access versus delivery capability.
For Remote Uptime, a forecast that shows 400 customer sites in year 2 may assume access to those sites, sufficient sales capacity, a buying process shorter than the planning cycle, and consistent data quality across equipment generations. None of those assumptions appears in the revenue cell. The first workshop produced 31 assumptions of this kind. Several came directly from phrases in the business case such as leverage the installed base and use the existing service channel. Those phrases disguise operational questions. Can the team legally contact installed-base customers? Will account directors introduce the offer? Are service technicians measured in a way that supports subscription adoption?
3. Prioritize which business assumptions to test first
Testing all 31 assumptions at once would waste time and obscure the important results. Rank them using three factors: how uncertain the assumption is, how severely failure would damage the initiative, and how soon the team must know.
A simple scoring approach can use low, medium, and high ratings.
Avoid mathematical precision that the underlying judgments cannot support. The scores create a structured conversation, not an objective probability model.
Use the following test map to choose evidence that matches each type of uncertainty:
| Assumption category | Remote Uptime assumption | Credible early test | Evidence needed for the next decision |
|---|---|---|---|
| Buyer | Regional maintenance directors control the budget | Buying-process interviews using a specific offer | Named budget owner, approval path, and current spending source |
| Willingness to pay | Customers will accept an annual subscription | Paid proposal with defined scope and price | Signed order, conditional commitment, or documented rejection reason |
| Market access | Account teams will introduce the offer to qualified sites | Time-boxed account activation test | Introductions completed across an agreed account sample |
| Delivery | Existing equipment data is sufficient for reliable monitoring | Technical audit using representative equipment generations | Documented coverage, failure cases, and remediation effort |
| Unit economics | Support requirements will remain within the service model | Concierge delivery with time and cost tracking | Observed labor, partner, infrastructure, and exception costs |
| Scalability | Results can transfer beyond pilot-friendly plants | Replication in a less supportive region | Adoption and delivery evidence under normal operating conditions |
Keep the full register, but limit active tests to the few that can change the next decision. This protects the team from producing a large volume of weak evidence.
Some tests also depend on others. There is little value in refining a global demand forecast when the available equipment data may exclude half the installed base. Test gating assumptions before optimization assumptions.
In the example, willingness to pay initially receives the highest priority. The team then realizes that market access is equally urgent. Even a strong offer cannot scale if account directors protect customer relationships or receive no credit for selling it.
4. Design credible tests for business assumptions
Match the test to the claim. Interviews can reveal roles, constraints, existing behavior — but they cannot prove that a customer will pay. Landing pages can compare message response, but they rarely show if a corporate buying center can approve an annual contract.
For each test, define the assumption, target population, test action, observable behavior, timeframe, and decision threshold. Also record what the test cannot establish.
The revised test uses a written annual offer. It names the equipment covered, service response, customer responsibilities, contract duration, and price. The team presents it to maintenance directors and procurement representatives from companies that were not part of the pilot.
Responses are coded by actual behavior: signed, entered procurement, requested a defined contractual change, deferred without action, or rejected. The team also created a private page at /homepage/remote-uptime/operations-package for invited accounts. Page visits are not counted as purchase evidence. The page gives each buying group a consistent description and lets the team observe whether contacts proceed to a commercial review.
When evaluating an innovation test, ask whether the conditions resemble the future business closely enough to inform the decision. The UK government’s Magenta Book provides useful guidance on evaluation design, including the need to connect evidence methods to the questions being answered.
Avoid oversized experiments. A six-month platform build is not a test if the same commercial assumption could be examined with a manual service and a defined offer. Yet a test can also be too small. One friendly customer cannot represent a market with different buying centers, regulations, and operating environments.
Remote Uptime first tested willingness to pay by showing the existing pilot dashboard to plant managers. Most said they wanted the service. That was weak evidence because the participants did not own the relevant budget and had received the pilot at no charge.
5. Set evidence thresholds before running assumption tests
Teams often interpret ambiguous results more positively after investing time in a test. Predefined thresholds reduce that bias. A threshold should say what supports the assumption, what rejects it, and what result requires another test. It should also define the relevant sample, even when the initiative is too early for statistical inference.
The delivery test has different thresholds. The team selects equipment from several generations and records data availability, installation effort, manual intervention, false alerts, and support time. Passing requires more than technical operation. The observed work must fit the proposed service economics.
Document thresholds before customer responses arrive. Have the decision owner approve them. Otherwise, a team can quietly redefine a failed sales test as valuable customer learning and continue without resolving the assumption.
This does not mean evidence rules can never change. New information may expose a badly designed test. If that happens, record why the rule changed and rerun the test rather than retrospectively declaring success.
For the Remote Uptime commercial test, the team does not set a universal conversion benchmark. It defines decision-specific evidence: multiple buying organizations must advance the paid offer through their real approval process, at least one must reach a contractual commitment, and rejection reasons must not reveal a common structural barrier. The actual numbers are agreed privately based on the investment under consideration and available customer pool.
6. Run assumption tests under realistic corporate conditions
Remove special treatment as testing progresses. Early manual work is useful for learning, but later tests must reveal what happens when normal sales, procurement, security, delivery, and support systems become involved.
Run tests far enough from the original pilot group to expose transfer risk. Use less supportive customers, standard contracts, normal data systems, and representative delivery staff.
The OECD Oslo Manual distinguishes innovation activity from the implementation of a new or improved product or process, which helps explain why completing experiments should not be confused with achieving business adoption.
Keep an evidence log. Store the original assumption, test design, raw observations, interpretation, threshold, and resulting decision. A slide that says validated removes the detail future reviewers need.
Remote Uptime’s test uses ordinary account teams in two regions. Account directors receive the same proposition, qualification criteria, and request for introductions that a rollout would require. The team tracks whether introductions happen, how long approvals take, and where the process stalls. This exposes a problem. Several account directors like the service but prioritize large equipment renewals because those sales affect their targets. The obstacle is not customer demand. It is the internal sales motion. Similar conflicts are explored in how sales incentives block new business.
Remote Uptime’s pilot succeeded partly because the innovation team recruited cooperative plants, supplied dedicated engineers, and escalated data-access issues through an executive sponsor. Those conditions will not exist for hundreds of sites.
7. Turn assumption evidence into a growth investment decision
At the review, evaluate assumptions individually before discussing the overall narrative. Green status should mean the agreed threshold was met. It should not mean the team made progress. The correct response is not necessarily to stop.
Leadership can narrow the first segment to newer equipment, change sales credit, use a specialist channel, or fund another bounded test. Each option creates a different plan and requires an owner.
Separate four possible decisions: proceed, adapt, hold, or stop. Proceed releases the specified next commitment. Adapt changes the proposition or operating model and identifies assumptions that must be retested. Hold delays commitment because an external dependency has a credible resolution date. Stop ends investment and records why. Stopping should remain an acceptable portfolio action.
If every initiative advances, the thresholds are probably not influencing capital allocation. Use explicit stopping criteria and preserve the evidence so another team does not repeat the same unsupported thesis. Lean Scaleup’s article on when to stop a growth initiative explains how to make that decision without treating it as a failure of effort.
For Remote Uptime, the evidence supports customer need and shows that some buyers will enter a paid process. It does not support the proposed rollout rate. Existing account incentives limit access, and delivery effort varies sharply across older equipment.
How the Lean Scaleup framework tests growth assumptions
A team can run this process with documents and disciplined governance. The administrative burden increases when several initiatives use different evidence standards, review formats, and definitions of progress. The Lean Scaleup Framework connects validation to the wider job of creating new business beyond Core.
A team starts by making the growth thesis and critical assumptions explicit.
It then gathers evidence against the assumptions, assesses whether the initiative is ready for its next commitment, and brings the resulting choices into a decision forum.
The sequence matters. Teams do not begin with a request to approve a large plan and then attach selected customer quotes. They show what must be true, which claims have been tested, what remains uncertain, and what commitment the current evidence justifies.
Lean Scaleup’s approach to de-risking growth initiatives focuses on producing evidence for scalable returns before commitments become difficult to reverse. Its Triple Win approach for beyond-core growth adds a broader assessment lens, helping teams examine whether an initiative can create durable value across the parties required for growth rather than optimizing a pilot in isolation.
For organizations managing several initiatives, the framework also creates a common basis for comparison. One initiative may have stronger demand evidence but weaker delivery readiness. Another may fit the business unit portfolio but lack willingness-to-pay evidence. Leaders can compare the unresolved risks without pretending that early revenue forecasts are equally reliable.
For Remote Uptime, this means the next review would show the commercial commitment evidence alongside the account-access failure and equipment-generation constraints. Leadership could then approve a narrower segment, require a revised sales mechanism, and withhold global rollout funding until replication evidence exists.
Common mistakes when testing business assumptions
The first common mistake is testing the idea rather than a specific claim. Asking customers what they think of predictive maintenance generates opinions. Asking a budget owner to review and advance a defined paid offer produces evidence about a commercial assumption.
The second is relying on pilot users as substitutes for the buying center. Users may value a service while procurement, IT security, finance, or an economic buyer blocks adoption. The gap between the two is covered in pilot users versus the buying center.
The third is testing under protected conditions and projecting the result to normal operations. Dedicated engineers and executive escalation can prove technical possibility. They say little about repeatable delivery cost.
The fourth is combining assumptions into a single status. An initiative labeled on track may contain proven demand, uncertain market access, and failing economics. Show these separately. Hidden assumptions in growth dashboards explains why conventional reporting often conceals those differences.
The fifth is changing success criteria after seeing results. Agree thresholds with the decision owner first and preserve the original record.
Finally, do not treat more research as the default response to uncertainty. Sometimes the next useful action is a purchase request, partner negotiation, technical audit, or controlled rollout. Choose the behavior that would have to occur in the real business.
How assumption testing improves creating beyond-Core business
Governance should regulate commitments, not supervise every team activity. Set review points around consequential decisions such as entering a new country, building production infrastructure, hiring a permanent sales team, or integrating with core systems.
Require each initiative to present the same evidence fields: decision requested, commitment at stake, critical assumptions, tests completed, thresholds, contradictory findings, residual risks, and named owners. Keep narrative slides secondary.
Portfolio leaders can then direct resources toward initiatives with both strategic relevance and evidence of a workable business. They can also identify shared corporate barriers. If several initiatives cannot access the installed customer base, the issue may require a portfolio-level change rather than separate workarounds.
Connect the evidence review to business unit priorities through a defined portfolio process. Lean Scaleup’s guidance on aligning innovation with business unit portfolios addresses this handoff between new growth and the operating organization.
Frequently asked questions about testing business assumptions
How do you identify assumptions in a business plan?
Review every forecast, strategic claim, and proposed capability as something that depends on observable conditions. Ask what must be true for the revenue, adoption, margin, timing, and rollout numbers to occur. Pay particular attention to phrases such as use existing channels, scale globally, customers are interested, and integrate with current operations. Rewrite each as a statement that could be disproved.
What is the best way to prioritize business assumptions?
Prioritize by uncertainty, consequence, and decision timing. Start with assumptions that could invalidate the initiative or materially change the next investment. Test dependencies first. For example, prove access to representative customers before commissioning a detailed market forecast based on reaching them.
Can customer interviews validate a business idea?
Interviews can validate facts about current behavior, pain, roles, constraints, and purchasing processes when questions focus on real events. They do not establish willingness to pay by themselves. Use a defined offer, commercial step, deposit, contract, or other behavior appropriate to the buying context.
How many assumptions should a team test at once?
Keep a complete assumption register but run only the tests needed for the next decision. For many teams, that means a small number of critical assumptions rather than dozens of parallel experiments. Capacity is not the only constraint. Too many tests make it difficult to see which evidence should change the initiative.
When is a growth initiative ready to move from pilot to scale?
A successful pilot is necessary in some businesses, but it is not enough. The team needs evidence of repeatable customer acquisition, buying approval, delivery under representative conditions, viable economics, and organizational ownership. The initiative should also have clear responses for known failure cases. The difference is examined in successful pilots versus scalable rollouts.
Should weak evidence lead to stopping the initiative?
Not automatically. Weak evidence may justify redesigning the test, narrowing the segment, changing the operating model, or delaying a commitment. Stop when a critical assumption has failed and no credible adaptation fits the strategy, economics, or available capabilities. The decision should follow a rule agreed before sunk costs and sponsorship pressure distort the review.
A qualified leadership team has a practical choice. It can approve growth initiatives from forecasts and pilot enthusiasm, or require explicit assumptions and evidence matched to each irreversible commitment. Use the first approach only when the organization is prepared to absorb avoidable portfolio risk. For consequential growth investments, test the assumptions first and fund the next stage only when the evidence supports it.