Assumptions vs evidence in Product Discovery
Most product decisions contain more assumptions than the team realizes.
“Users are confused by onboarding.” “Customers would pay for this.” “This feature will improve retention.” Each statement may be plausible. None becomes evidence simply because it sounds reasonable or because several people repeat it.
A useful Product Discovery process keeps that boundary visible.
Assumptions make the decision testable
Assumptions are unavoidable in product work.
A product idea is usually a bundle of them. If a team wants to add collaborative editing, for example, it may be assuming that:
- collaboration is a meaningful problem for the target segment;
- people currently use an inconvenient workaround;
- real-time editing would solve enough of that problem;
- the change would improve an outcome that matters.
Problems appear when those assumptions start to behave like established facts before they have been investigated.
That is why turning an idea into an explicit product hypothesis is useful: it exposes what the decision depends on.
A source needs interpretation before it becomes evidence
A customer interview, support ticket, dashboard, article or competitor page is a source.
Evidence is the part of that source that meaningfully changes how you should read a hypothesis.
Suppose a dashboard shows that 40% of users leave during onboarding. That is evidence of a drop-off pattern. The same data still leaves the cause open.
Likewise, one customer saying “I need feature X” is evidence that this person expressed that need. The broader market may experience the problem differently, and feature X may or may not be the best response.
This distinction keeps Product Discovery from becoming a collection of links that merely looks rigorous.
Evidence can support, challenge or qualify
Teams often look for evidence mainly in the direction of confirmation.
Useful evidence can do at least three things:
- support a hypothesis;
- challenge it;
- qualify it by showing that it holds only for a segment, situation or condition.
That third category is easy to miss. Research may reveal that a problem is meaningful for enterprise admins and largely irrelevant to individual users.
That result narrows the hypothesis and gives the team a more precise model of the problem.
Ask what would change your mind
A simple test helps separate belief from evidence:
What would we need to observe for us to change this conclusion?
If the team cannot name anything, the current direction may be receiving more defense than investigation.
A clear answer exposes a research gap and gives the next round of work a specific purpose.
The next step depends on the cost of being wrong. How much evidence is enough should be judged against the decision’s risk, reversibility and remaining uncertainty.
Keep the distinction visible over time
Assumptions, sources and evidence can easily blur together as a decision moves through meetings, documents and roadmap discussions.
Keeping them distinct makes it easier to explain what the team currently believes, why that reading looks reasonable and which new information could still change it.
That clarity matters especially when a decision is revisited months later and the original reasoning has to be reconstructed.