Assumptions Are Not Evidence: A Better Way to Validate Product Ideas

Read almost any product strategy document and you will find a sentence that sounds like a fact but is actually a guess wearing a fact’s clothing. “Customers want a faster way to reorder.” “Clinicians will trust an automated recommendation if it shows its reasoning.” “Users will tolerate a short onboarding flow in exchange for personalization.” Someone wrote each of these sentences with conviction, a team nodded, and a roadmap got built on top of them. None of that conviction changes what they actually are: assumptions vs evidence, product validation still owes a debt to.

The problem is not that teams make assumptions. Every product decision requires some. The problem is what happens next, which is usually nothing. The assumption gets written down once, in a confident tone, and from that point forward it is treated as settled. Nobody circles back to check whether it was ever tested, because it does not read like a question anymore. It reads like a fact.

The Comfortable Lie of the Strategy Document

There is a specific kind of confidence that comes from seeing an idea in writing. A bullet point in a slide, a paragraph in a PRD, a line item in a business case, these all carry a visual authority that a spoken guess in a meeting does not. Once “customers want X” appears in a document with a logo on it, it starts to function like evidence even though nothing about writing it down generated any actual information about customers.

An assumption written in a product document does not become a fact.

This is not a criticism of any particular team. It is closer to a structural hazard in how product work gets documented. Strategy documents are written to be persuasive and decisive, not to preserve uncertainty. A sentence like “we believe some clinicians may be hesitant to trust automated recommendations, though we have not yet confirmed this with the specific segment we are targeting” is honest, but it does not read like leadership. So it gets compressed into “clinicians will resist automated recommendations,” which reads decisively and is quietly less true. The compression is where the damage happens.

Four Categories, Not One Pile

The fix is not to demand proof for everything before a team is allowed to move, that would stall any product effort indefinitely. The fix is to stop treating every belief as the same kind of belief. In practice, everything feeding a product decision falls into one of four categories, and confusing them is where most avoidable mistakes come from.

Known Facts. Things that have actually been observed, measured, or documented, not inferred. A support ticket volume, a completion rate from existing analytics, a regulatory requirement stated in writing, a finding from a study someone actually ran with real customers. Known facts earn their place through evidence that already exists, not through how often someone has repeated them in meetings.

Assumptions. Beliefs the team is treating as true for planning purposes but has not directly verified. “Our core customer checks the app daily” is an assumption if nobody has actually looked at usage data broken down by segment. Assumptions are not wrong to hold, but they are dangerous to build on unexamined, especially the load-bearing ones.

Hypotheses. Assumptions that have been shaped into something testable. Not “customers want faster reordering” but “customers who reorder more than twice a month will complete checkout at a higher rate if the reorder flow drops from four steps to one.” A hypothesis has a shape that an experiment can actually engage with, which is the whole point of writing it that way.

Unknowns. The things nobody in the room has an informed opinion about yet, and the category most often skipped entirely. Teams are usually fine admitting an assumption. They are much less comfortable writing “we genuinely do not know,” even when that is the most accurate available answer. Naming an unknown as an unknown, instead of quietly promoting it to assumption because someone had to fill in the row, is one of the more useful and underused disciplines in product work.

Sorting beliefs into these four bins does something simple but powerful: it makes visible exactly how much of a plan is standing on ground that has never been tested. That visibility is the actual value of an assumptions and evidence register. It is not a compliance exercise. It is a map of where the plan is strong and where it is hollow.

Building the Register: A Worked Example

Consider an illustrative case. A digital health team supporting patients with hypertension is deciding whether to build an AI chat assistant that reminds patients to log blood pressure readings and answers basic questions about their medication schedule. The pitch sounds reasonable in the room: patients forget to log readings, a conversational nudge feels lower-friction than a push notification, and the team has the AI capability to build it in a few weeks.

Before writing a line of code, the team sits down and actually separates what they know from what they are hoping is true.

Sorting what we know from what we hope

Known facts: Adherence data from the existing app shows that logging drops off sharply after the second week of use. Support tickets show a recurring theme of patients asking what a given reading means, not just forgetting to log it. The care team has confirmed that any tool suggesting clinical interpretation, even mild reassurance language, needs a review process before launch.

Assumptions: That patients who stop logging do so because they forget, rather than because they find the readings confusing, discouraging, or simply not useful to them day to day. That a chat interface will feel less burdensome than the existing reminder notification. That patients in the target age range are comfortable typing conversational questions to an assistant rather than tapping a button.

Hypotheses: If patients receive a daily conversational check-in instead of a static push notification, week-three logging rates will be measurably higher than the current baseline within a defined test window.

Unknowns: Whether patients with lower health literacy will trust an AI-generated answer about their own blood pressure reading enough to act on it, and whether that trust changes based on how the assistant is introduced.

Finding the riskiest assumption

With the list assembled, the next step is not to validate everything, that would take longer than the feature is worth. It is to find the one assumption that, if wrong, would invalidate the most other decisions downstream. Here that assumption is not “patients prefer chat over notifications.” It is the first one: that logging drop-off is a forgetting problem rather than a comprehension or motivation problem.

That assumption is riskiest because almost everything else in the plan depends on it being true. If patients stop logging because the readings confuse or discourage them, then a friendlier reminder, no matter how well designed, will not move the outcome the team actually cares about, which is sustained blood pressure tracking, not message delivery. Building the entire chat assistant on top of an unverified guess about the root cause is the kind of decision that a confident-sounding paragraph in a planning document can hide very effectively.

A lightweight validation action

Testing this does not require building anything. A short round of structured conversations with a handful of patients who lapsed after two weeks, asking specifically what happened when they stopped logging, can surface the real reason within a few days. If the team wants something closer to quantitative, a simple in-app prompt that appears after a missed log, asking patients to pick the closest reason from a short list, forget / confusing / didn’t seem useful / other, can produce a directional answer within one or two weeks of existing usage. Neither approach requires an engineering sprint. Both produce actual evidence instead of a second layer of guessing.

If the evidence shows forgetting is the dominant reason, the chat assistant idea gets stronger support to proceed, ideally as a minimum viable output narrow enough to test the reminder mechanism specifically, not the full conversational product. If the evidence shows confusion or low perceived usefulness instead, the team has just avoided investing in a well-built answer to the wrong problem, which is a far more common failure mode than most retrospectives admit.

Why This Matters More, Not Less, in the AI Era

It would be reasonable to assume that AI tooling makes this kind of discipline less necessary, since teams can now build and ship variations so quickly that reality will sort things out on its own. The opposite is closer to true. Because prototypes, test flows, and even conversational scripts can now be assembled in hours rather than weeks, the cost of actually testing an assumption has dropped much faster than the cost of asserting one. There is less excuse than ever for skipping the test and going straight to the confident sentence in the document.

Product experiments should reduce uncertainty, not merely produce reports.

Cheap experimentation is only valuable if it is pointed at the right question. An AI-assisted team that skips the sorting exercise above will simply produce five polished-looking variants of the same untested assumption, faster than a slower team could have produced one. Speed compounds whatever discipline, or lack of it, was already present before the building started. Teams that treat assumption-sorting as a five-minute annoyance before the real work begins are the ones most likely to mistake fast output for good judgment.

Key Takeaway

Every product plan rests on a mix of known facts, assumptions, hypotheses, and unknowns, and the risk is not in having assumptions, it is in losing track of which category each belief belongs to. Build a short register for the next real decision on your roadmap, find the one assumption that would do the most damage if it turned out to be wrong, and design the smallest possible test for that one first. In a period when building has never been cheaper, testing a belief before committing to it is not extra overhead, it is the difference between speed that serves customers and speed that simply produces more confident guesses.