Maria-Jacobi-Gasse 1, Media Quarter Marx 3.4, A-1030 Wien | office@inits.at  | Tel.: +43 1 – 715 72 67

How to Turn Assumptions Into Evidence

 

 

At the beginning, every startup is partly fiction.

The customer segment is a hypothesis. The problem is a hypothesis. The product is a hypothesis. The price, channel, adoption process, and market timing are hypotheses too.

Starting with assumptions is the nature of building something new.

The danger begins when assumptions quietly get promoted to facts because the team has repeated them often enough. A sentence on a pitch deck can become company doctrine surprisingly fast.

The Evidence Risk profile means your startup may have promising signals, but not enough proof from the market yet. The next step is to turn assumptions into evidence.

 

Evidence reduces uncertainty

 

The Lean Startup approach frames startup progress as a process of building, measuring, and learning through experiments. [1] A similar logic can be applied to science and engineering teams:

participants conduct customer discovery to assess whether a technological innovation may support a sustainable business model and to develop evidence-based decision-making. [2]

The important word is “decision”.
An experiment is useful only if it helps you decide what to do next.

 

Step 1: List your assumptions

 

Start by writing down what must be true for your startup to work.

Use categories:

 

Customer

  • Who has the problem?
  • How urgent is it?
  • Who pays?

Problem

  • How often does it happen?
  • What does it cost?
  • What happens if it remains unsolved?

Solution

  • Does the product solve the problem?
  • Can users adopt it?
  • Does it fit the workflow?

Business model

  • What will customers pay?
  • How will you reach them?
  • Can you deliver sustainably?

Execution

  • Can the team build, sell, and support this?
  • What capabilities are missing?

This exercise can be irritating because it reveals how much is unknown.
But that’s a good thing.

A startup that knows where it is guessing is already less dangerous to itself.

 

Step 2: Prioritise the assumptions that could kill you

 

Not all assumptions deserve equal attention.

A button color is an assumption.
Whether hospitals can legally use your product is also an assumption.

These should not receive the same calendar space.

Prioritise assumptions by:

Importance: If false, would this seriously damage the business?

Uncertainty: Do we actually know this?

Cost of learning later: Would it be expensive to discover this in six months?

The best experiments often target assumptions that are both highly important and highly uncertain.

 

Step 3: Choose the right evidence

 

Not all evidence is equally reliable.

Compliments, opinions, likes, and statements such as “I would use this” may indicate interest, but they reveal little about actual customer behaviour.

Repeated problem descriptions, past behaviour, qualified sign-ups, and prototype engagement provide stronger signals.

The most convincing evidence comes from commitment: customers paying, using and returning to a product, signing a pilot, involving budget owners, sharing data, entering procurement, or changing established workflows.

Weak evidence is not useless, it can help founders identify where to investigate next. However, it should not justify decisions that require significant time, capital, or product development.

 

Step 4: Design a small experiment

 

A useful experiment begins with a clear assumption and defines how it will be tested.

A good experiment has 5 parts:

Assumption: What are we testing?

Method: How will we test it?

Audience: Who must participate?

Success criterion: What result would count as evidence?

Decision: What will we do if the result is positive, negative, or unclear?

For example, a startup might test whether operations managers will share anonymised downtime data in exchange for an analysis of recurring bottlenecks. If at least three out of ten target managers provide data and agree to a follow-up, the team has a reason to develop the analysis workflow further. If they do not, the result points to questions about urgency, trust, or data-access barriers.

The experiment does not need to be elegant or scalable. Its purpose is to produce evidence that informs the next decision.

 

Step 5: Record what you learned

 

Capture your learnings!
Sometimes teams rely too much on memory, but memory is an unreliable colleague.

After each experiment, document:

  • what you assumed,
  • what you tested,
  • who participated,
  • what happened,
  • what evidence was strong or weak,
  • what surprised you,
  • what decision follows.

This prevents “selective learning”, where teams remember the encouraging parts and forget the awkward ones.

 

Common mistakes

 

The first mistake is testing too late.
If an assumption is critical, test it before building the expensive version.

The second is testing too many things at once.
If a landing page fails, was it the segment, message, offer, channel, or call to action?
Nobody knows. The spreadsheet shrugs.

The third is confusing activity with evidence.
Fifty meetings are not automatically progress.
Ten relevant conversations with clear patterns may be more valuable.

The fourth is ignoring negative evidence.
Bad news early is useful. Bad news late is a budget event.

 

Conclusion

 

Evidence-driven founders do not wait until everything is certain. Startups never get that luxury. But they do create enough evidence to make better decisions under uncertainty.

You can never remove all risk. But you can stop pretending that guesses are facts.

If you want structured support turning assumptions into experiments, evidence, and market progress, explore the INiTS SCALEup Incubation Program.

Explore INiTS SCALEup → www.inits.at/en/scaleup

 

 

The Big Takeaways

 

Write assumptions down explicitly.
Hidden assumptions cannot be tested.

Prioritise the assumptions that could kill the business.
Do not spend weeks testing cosmetic details while ignoring buying risk.

Define the decision before the experiment.
Evidence is useful only if it changes what you do next.

 

Sources

 

[1] Eric Ries / The Lean Startup — Methodology Principleshttps://theleanstartup.com/principles

[2] U.S. National Science Foundation — I-Corps Report — 2019 — https://nsf-gov-resources.nsf.gov/2022-06/I-CorpsReport–6_4_19FINAL_508_0.pdf


 

Facebook
LinkedIn
Twitter

Persönliches Profil