Which Startup Assumptions Should You Test First?

Why Startup Assumptions Matter So Early

Unit 1 makes a simple but important point: every startup idea is built on assumptions.

Once a team has defined a customer problem, it immediately starts making untested claims around that problem. It may assume the cause is correct, the consequences are serious, existing solutions are not good enough, or the customer segment is motivated to act. As soon as the team begins imagining a solution, even more assumptions appear.

That is why startup assumptions should be made visible as early as possible. If they remain hidden, teams often move ahead as if their view of the world were already confirmed. In reality, many of the most important parts of the idea may still be uncertain.

Steve Blank's core lean startup logic is useful here: startups are not established businesses executing a known model. They are searching for one. That means uncertainty is normal. The real mistake is not uncertainty itself. The mistake is acting as if the uncertainty is already resolved.

Why startup assumptions should be made visible early

What Counts as a Startup Assumption?

A useful way to think about assumptions is to complete the sentence: "We are assuming that..."

That framing makes hidden beliefs easier to spot. For example:

• We are assuming that this customer segment really has this problem.
• We are assuming that the problem matters enough for customers to seek change.
• We are assuming that our solution will be used the way we expect.
• We are assuming that customers will pay, or that some other model will support the business.
• We are assuming that the team can actually build and deliver what it promises.

Unit 1 groups startup assumptions into a practical set of categories:

Six main types of startup assumptions

• Customer assumptions: beliefs about who the customer is and how they behave
• Problem assumptions: beliefs about whether the problem is real and significant
• Solution assumptions: beliefs about whether the solution will work or be adopted
• Market assumptions: beliefs about size, demand, or growth conditions
• Revenue or cost assumptions: beliefs about willingness to pay and business viability
• Feasibility assumptions: beliefs about whether the team can build and deliver the solution

This is useful for program managers because it prevents teams from talking only about product features. It broadens the conversation from "what are you building?" to "what must be true for this to work?"

Not All Assumptions Matter Equally

One of the most common validation mistakes is treating all assumptions as if they have the same weight.

They do not.

Some assumptions are relatively harmless if they turn out to be wrong. Others are critical. If one of those critical assumptions fails, the startup may need to change direction completely or stop the idea altogether. These are often called leap-of-faith assumptions because they carry major consequences despite limited evidence.

For program managers, this is the key filter: do not ask teams to test everything first. Ask them to identify what would hurt the idea most if it turned out to be false.

Unit 1 recommends a simple prioritization logic based on two dimensions:

1. Impact: how much damage it would cause if the assumption were wrong
2. Uncertainty: how little evidence the team currently has

The riskiest assumptions are the ones with high impact and high uncertainty. Those are the assumptions that deserve testing first.

Which Startup Assumptions Should You Test First?

If a team asks which startup assumptions should you test first, the best answer is not "the easiest ones." It is the assumptions that combine the greatest consequence with the weakest evidence.

That usually puts a few recurring assumptions near the top.

1. Does the Customer Problem Really Exist and Matter?

This is often the most important starting point. If the team is wrong about the problem itself, everything built on top of it becomes unstable.

Program managers should push teams to examine whether the customer actually experiences the problem, whether it happens often enough, and whether the consequences are serious enough to drive attention or behavior. If that assumption fails, the team is not refining a promising concept. It is building on weak foundations.

2. Do Customers Care Enough to Act?

A problem can be real without being urgent. That distinction matters.

Teams often assume that because a problem sounds reasonable, customers will automatically prioritize solving it. But some problems remain low on the customer's list, even when they are genuine. This is why assumptions about motivation, urgency, and willingness to change are usually high-value tests.

3. Will Someone Pay, Sponsor, or Support the Business Model?

Many startup ideas sound compelling until the revenue assumption is examined. Unit 1 highlights this clearly: a venture may still fail if there is no viable path to payment or support.

For program managers, this is especially relevant in B2B and institutional contexts. The end user may value the solution, but the payer may be someone else entirely. That means willingness to pay can remain highly uncertain even when customer interest looks promising.

4. Will the Proposed Solution Actually Work in Practice?

Even if the problem is real, not every solution is viable. Teams may assume that adoption will happen smoothly, that the workflow fits user behavior, or that the proposed intervention creates measurable value.

This is why solution assumptions should not be ignored just because the team is still early. They do not need full product validation yet, but they do need to identify what must be true for the solution logic to hold.

How to Identify the Right Assumptions

Unit 1 offers a practical starting point: begin with the problem statement and ask what assumptions sit behind it.

This is a useful coaching sequence for program managers:

1. Start from the problem statement.
2. Ask what must be true about the problem, the customer, and the context.
3. Ask what must be true about the solution direction, if one exists.
4. Ask what must be true about adoption, payment, and delivery.

Another useful prompt is: what questions keep coming up in mentor conversations? If the same uncertainty appears again and again, it probably signals an assumption that deserves explicit testing.

Unit 1 also shows how assumptions can be grouped under practical headings such as:

• causes of the problem
• consequences of the problem
• why the problem is not already solved well

This is a strong coaching tool because it prevents teams from producing only generic lists. Instead, it pushes them to generate assumptions tied directly to the specific problem they are working on.

How the 2x2 Grid Helps Teams Prioritize Risk

The Assumption Prioritisation Tool in Unit 1 is deliberately simple: a 2x2 grid with Impact on one axis and Uncertainty on the other.

Which startup assumptions should be tested first?

That simplicity is useful. Teams do not need a complex framework to get value from it. They need a way to compare assumptions and decide what comes first.

The grid gives a practical testing order:

• High Impact + High Uncertainty → Test first
• High Impact + Low Uncertainty → Test second
• Low Impact + High Uncertainty → Test third
• Low Impact + Low Uncertainty → Test fourth

For program managers, this creates a better mentoring conversation. Instead of debating ideas in the abstract, the discussion becomes operational:

• Which assumptions could stop the venture if wrong?
• Which assumptions are still mostly guesswork?
• Which one to three assumptions should become the next validation priority?

That last point matters. Unit 1 does not suggest testing ten things at once. In most early-stage ventures, one to three assumptions stand out as the most urgent to validate first.

What This Looks Like in Practice

The Unit 1 use case with Ana the physiotherapist makes this concrete.

After defining the customer problem, Ana surfaces multiple assumptions. Some relate to cause: prolonged sitting is a major driver of lower-back pain. Some relate to consequence: the issue affects wellbeing and productivity. Others relate to current gaps: existing wellness tools are too general or not embedded into the workday.

Moving startup assumptions from a raw list to priority decisions

She then prioritizes them on the grid. The assumptions with the highest impact and highest uncertainty rise to the top. These include whether employees really experience the pain regularly, whether HR sees the issue as worth solving, and whether companies would pay for a solution.

That is the lesson program managers can apply more broadly. The best next test is not always the most exciting idea. It is the assumption that creates the biggest risk if it turns out to be false.

Why This Matters for Program Managers

Assumption prioritization improves more than startup learning. It improves program quality.

Why this matters for program managers

It helps mentors focus on evidence rather than founder confidence. It helps programs compare teams more clearly because validation activity becomes easier to interpret. It also improves intervention timing because weak assumptions can be challenged before teams invest too deeply in the wrong direction.

This is where the KPI Dashboard becomes more useful than a simple reporting sheet. If a program wants clearer visibility into validation progress, it should not only track activity volume. It should also track whether teams are testing critical assumptions, what evidence they are gathering, and where the biggest risks still sit. The KPI Dashboard template is a practical starting point for that kind of structured oversight.

In other words, assumption prioritization is not only a startup technique. It is a program management discipline.

Conclusion

If your teams are early, the question is not whether they have assumptions. They do.

The real question is whether those assumptions are visible, prioritized, and connected to the next validation step.

The best assumptions to test first are the ones with the highest impact and the least evidence. Those are the assumptions most likely to waste time, distort mentoring, and create false confidence if they remain untested. When program managers help teams surface and rank those risks early, they improve the quality of both learning and support.

Startup Drill KPI Dashboard

If you want a practical way to track validation priorities, learning progress, and key startup risks across your cohort, use the KPI Dashboard template as the next step.