How do we decide which new venture assumptions to test first?

Every new venture rests on more assumptions than any team can test. Some are about customers: who has the problem, how much it matters to them, and what they would pay to solve it. Some are about the solution and how it gets delivered. Some are about the company itself, and whether it will support something that works differently from the core business. Most are held with reasonable confidence. Few have been checked.

Time and money for testing are limited, so some assumptions get tested and most do not. That prioritization happens whether anyone does it deliberately or not. What matters is whether the assumptions that get tested are the ones the venture’s success actually depends on.

Our post on turning uncertainty into action covers the principle: rate each assumption for how much it affects the outcome and how strong the evidence behind it is, and work first on the ones that matter most and are least supported. This post is about why large companies so often test something else first, which assumptions tend to be missing from the list, and where software can help.

What large companies test first

Large companies tend to make one of two mistakes about what to test first.

One mistake is investing heavily before doing the preliminary analysis. Established products get a development budget once the business case is approved, and a new venture often follows the same path: a plan, a budget, a team and a build. Money is committed before anyone has checked the few assumptions that would decide whether the venture is worth building. Our post on how much to invest in a new idea covers why early investment should be small and released as evidence accumulates.

The other mistake is the reflex to just build something, especially in technology-focused companies. Prototypes and early product development feel like progress, and technical teams are good at them. But a prototype answers whether the product can be made or how it performs. If the question that matters most is whether customers will buy it, whether a channel partner will carry it, or whether the company will support it, the prototype does not answer it, or answers it far more slowly and expensively than another method would. A set of customer conversations, a simple mock-up, a letter of intent or a candid conversation with the functions the venture depends on can often answer it in weeks.

The goal is to test the most consequential assumptions with the least time and resources. That means choosing the question first and the method second.

Finding the assumptions is the hard part

Prioritizing assumptions depends on a step that is easy to skip: identifying them in the first place. That is harder than it sounds. An assumption is, by definition, assumed. Most are never consciously made or derived. They are taken for granted, so they do not appear on any list until someone deliberately goes looking for them. Writing them down is a discipline, and one most teams have had little reason to build.

It helps to know what to look for. Every strategy hypothesis rests on three kinds of assumption:

• Choices are the decisions the team controls, such as which customers to serve, what to build and which channel to use.
• Assertions are beliefs about how others will behave: that customers have the need, that a channel partner will carry the offering, that a competitor will not respond.
• Uncertainties are the quantities the team can only estimate, such as price, adoption rate and cost per unit.

The uncertainties are the easiest to find, because a financial model will not run without them. That is one reason the list of risks a team works from is so often built from the spreadsheet. Choices and assertions are harder to see. Some of the most consequential are the choices a venture inherits from the core business without anyone deciding to make them, which this series has looked at: where it sits in its value network, what the whole solution includes and how each part is delivered, how its business case is built, and whether the organization will support it. Each rests on assertions nobody wrote down: that the existing channel will sell the new offering, that a partner will stay committed, that procurement and legal will move at the venture’s pace. They are left off the list not because anyone judged them safe, but because nobody noticed they were assumptions.

A complete list covers the three questions every venture has to answer: whether customers want it (desirability), whether it can be delivered (feasibility), and whether it can make money (viability). A list built from the spreadsheet covers mostly viability, and leaves out much of the risk.

Confidence is not evidence

The assumptions most worth testing are often the ones the team is most confident about. An inherited choice feels settled because the core business has always worked that way. The core’s channel does sell the core’s products. The core’s customers do buy from the company. That experience is real, but it is evidence about the core business, not about the venture. Confidence carried over from the core is one of the easiest ways for an untested assumption to look tested.

That is why each assumption’s evidence level should be rated on what the team actually has, from a rough guess to real-world results, rather than on how sure people feel. An assumption everyone agrees on and nobody has checked has a low evidence level, however settled it feels in the room.

Why the usual tools leave gaps

Most teams have some way of listing assumptions. Each covers part of the job.

Assumption-mapping workshops, run with sticky notes or a canvas, are a good way to surface beliefs and rank them together. But they depend on the people in the room recognizing what they have assumed, and the result is usually a photo or a slide, made once and not connected to the strategy it describes. When the strategy changes, the map does not.

Risk registers track identified risks, owners and mitigations. They are built for execution risk in a project that has already been approved, not for the untested beliefs inside a strategy that has not.

Spreadsheet models can show which financial inputs move the outcome most, if someone runs the sensitivity analysis. They say nothing about the choices and assertions, and anything outside the model is rated by opinion.

What is missing is a single list of every assumption in the strategy, quantitative and qualitative, collected as the strategy work is done rather than rebuilt in a workshop, rated for evidence and impact, and kept current as the strategy changes.

There’s an app for that: how Growth Forge® Software addresses this

Assumptions Manager provides that list. Each of the strategy modeling tools records the assumptions behind the work done in it: the expected outcomes and beliefs in the strategy hypothesis, customer jobs and requirements, competitive ratings, solution and delivery choices, company fit, and the uncertain inputs in the financial models. Because each tool asks for the choices, beliefs and estimates its part of the strategy depends on, assumptions that would otherwise stay implicit get recorded as the work is done. Assumptions Manager gathers them into one place automatically, so the assumption list is a by-product of doing the strategy work rather than a separate document someone has to keep up to date. Teams can add any make-or-break assumptions the other tools did not capture.

The assumptions are organized by desirability, feasibility and viability, so a list that is heavy on financial inputs and thin on customer or fit assumptions is easy to see. Each is rated for evidence, from a rough guess to real-world actuals, and for its impact on the venture’s success. Some impact scores are calculated automatically from the other tools. Filtering to the high-impact, low-evidence assumptions gives the team its short list.

That short list goes to the Evidence Gathering tool, where tests are planned against the assumptions they are meant to answer. The evidence status feeds Strategy Evaluation, so the next investment decision can see how much of the strategy has actually been tested. And when a strategy choice changes, the assumptions change with it, because they come from the same model.

The output is a prioritized list of what the team most needs to learn next, covering the whole strategy rather than only the technical risks or a spreadsheet.

What no software can settle

Testing the riskiest assumption first means being willing to learn early that the venture does not work, or that the strategy hypothesis needs to change. That only happens where stopping or pivoting is a respectable outcome. Where a stopped venture counts against the people who ran it, teams rationally test the safe things first, and the riskiest assumptions wait until after the money is spent. Our post on when to stop pursuing an innovation idea covers what makes stopping a sound decision rather than a defeat.

That is a decision-culture question, set by leadership: whether early learning is rewarded, and whether a team that finds a fatal flaw in month two is treated better than one that finds it in year two.

Putting it into practice

Before a new venture’s next round of testing is planned, a few steps make sure it tests what matters. List the assumptions behind the strategy, including the choices inherited from the core business and the assertions about how others will behave. Rate each for its impact and for the evidence actually behind it, not the confidence the team feels. Pick the few high-impact, low-evidence assumptions, and for each one choose the fastest and cheapest test that would answer it. These steps can be worked through with a framework, facilitated by an experienced consulting firm, or with purpose-built software such as Growth Forge, where Assumptions Manager provides the guidance and the analysis. Choosing what to test is one part of moving a venture through its early stages. Gathering the evidence, and acting on it, are the parts that follow.

If the harder question is whether your organization treats an early stop as a good outcome, our Innovation Capability Assessment is a short scored read on where that stands.

Next in this series: gathering the evidence, and the part of the work no software can do.

BRI Associates helps companies grow by drawing on decades of practitioner experience in corporate innovation and new business development — practitioners, not pundits or academics — through direct consulting, training workshops, and Growth Forge® Software, built for the unique requirements of corporate innovation and growth organizations.