Every failed feature has a post-mortem. Most of them say the same thing: we didn't define success clearly enough before we started. True. But not useful. The interesting question isn't whether success was defined — it's whether the team could tell the difference between "this hypothesis was wrong" and "this experiment was poorly designed." Those are different problems with different implications. Conflating them is how teams end up running in circles.
The Collapse
Most teams that practice some form of hypothesis-driven development produce one document. It captures what they believe, how they'll test it, and what result they're hoping for, all in the same block of text. This feels efficient. It is actually a trap.
When belief and test live in the same document, they drift toward each other under pressure. The hypothesis bends to accommodate the experiment that was practical to run. The success criteria adjust as results come in. By the time the team is making a decision about whether to continue, the document reflects what happened — not what was predicted. Post-hoc revision, usually unconscious, usually rationalized as "refining our thinking."
The result is a process that looks like hypothesis-driven development but doesn't function like it. Teams go through the motions — they write a hypothesis, they run an experiment — but the decision at the end is still mostly driven by intuition, politics, and sunk cost. The document didn't change the decision. It just gave the decision a paper trail.
What a Hypothesis Record Actually Is
A hypothesis record has one job: to capture what the team believes before anything is built or tested. It is a snapshot of the mental model at a specific point in time, written precisely so it cannot be quietly revised after the fact.
It answers three questions: What do we believe? Why do we believe it? What would convince us we're wrong? That last question is the one most teams skip, and it is the most important. A belief that cannot be falsified is not a hypothesis. It is a preference. Preferences don't generate learning — they just generate confirmation bias until the budget runs out.
The hypothesis record must be written before the experiment is designed. This is not a procedural formality. It matters because the act of designing an experiment creates pressure to make the hypothesis testable — and "testable" often means "simplified." If you write the hypothesis after you've already decided what experiment to run, you will unconsciously write a hypothesis your experiment can answer, not the hypothesis that actually reflects what you believe. The order of operations is the discipline.
Once written, the hypothesis record is frozen. Not because it can never be updated — beliefs should evolve as evidence arrives — but because any revision should be deliberate, documented, and timestamped. If the team's belief changed because of what an experiment revealed, that is a meaningful data point. If the belief changed because the experiment was inconclusive and the team needed to say something optimistic in a stakeholder update, that is a different thing entirely. The frozen record makes the difference visible.
What an Experiment Record Is
An experiment record is operationally separate from the hypothesis record. It captures how a specific hypothesis will be tested: the method, the population, the metrics that will be observed, the time horizon, and the threshold that separates confirmation from refutation.
The experiment record is written when a build cycle or sprint is being scoped — not at the same time as the hypothesis. The gap between them is intentional. It creates space to ask: is this the best experiment we can run against this hypothesis, or is it just the most convenient one given current constraints? A team that writes both documents at the same time almost always chooses the convenient experiment. A team that writes them at different times has the opportunity to notice when the available experiment doesn't actually test the hypothesis at hand.
The experiment record also has a different lifecycle than the hypothesis record. Multiple experiments can test a single hypothesis — a small qualitative study first, then a larger quantitative test if the signal is promising, then a controlled rollout at scale. Each experiment has its own record, linked back to the original hypothesis. The hypothesis stays stable across all of them. What evolves is the evidence base — and eventually, the confidence level at which the team makes a persevere, kill, or pivot call.
The Reason the Separation Matters
Here is the practical problem the separation solves: one inconclusive experiment should not, by itself, change what the team believes.
This seems obvious when stated directly. In practice, teams violate it constantly. An experiment runs. The results are ambiguous — maybe a small positive signal, maybe noise, definitely not the clear confirmation that was hoped for. The team faces a decision: do we run another experiment, pivot the hypothesis, or kill the initiative? Under pressure, the path of least resistance is to revise the hypothesis to match the ambiguous results and call it learning. Then design a second experiment around the revised hypothesis. Then repeat.
This process generates documents. It does not generate decisions. The team is busy, they're working through a process, they're producing artifacts. But they're not actually testing anything — they're iterating toward a hypothesis their experiments can confirm, rather than running experiments against the hypothesis they actually hold.
Keeping the hypothesis record separate and frozen prevents this. When the experiment result comes in, there are two clearly distinct questions: Did this experiment produce the signal we said would confirm or refute the hypothesis? And: does this result, combined with everything else we know, change what we actually believe? The first question is answered by looking at the experiment record and the data. The second question is answered by the team, with the original hypothesis in front of them, under full accountability for the reasoning they're about to apply.
The Decision the Process Is Supposed to Produce
The point of hypothesis-driven development is not to produce better documentation. It is to reach a persevere, kill, or pivot decision as fast as possible, with as little waste as possible, at a high enough confidence level that the decision will actually hold.
Persevere means: the evidence supports the hypothesis; continue building in this direction. Kill means: the evidence refutes the hypothesis; stop. Pivot means: the evidence suggests the hypothesis was wrong in a specific way that points toward a better direction; change course deliberately. All three are good outcomes. The failure mode is a fourth path that no good process names: continue regardless, because we've invested too much to stop and the hypothesis has been quietly revised enough times that refutation is no longer possible.
Two separate records make the decision harder to avoid. The hypothesis, written before the work began, is on record. The experiment, designed against that hypothesis, is on record. The result is on record. Someone in the room has to say, clearly, whether the evidence confirms or refutes what was predicted — not what the current version of the hypothesis says, but the original one. That is an uncomfortable conversation. It is the conversation the process is designed to force.
What This Looks Like in Practice
In ProductHarness, hypothesis records and experiment records are first-class artifacts in the framework — not informal notes, not fields in a ticket, not items in a product strategy document. They live in the repo, version-controlled alongside the work they govern. The hypothesis record is a discovery-layer artifact, written before a build decision is made. The experiment record is a delivery-layer artifact, written when a sprint or build cycle is being scoped.
This placement is not arbitrary. It encodes the order of operations into the structure of the work. A hypothesis record that lives in a discovery folder, timestamped, linked to the feature it informed, is structurally harder to revise quietly than a hypothesis written in a Confluence page that anyone on the team can edit. The friction is the point. Small amounts of structural friction at the right moments are what make process disciplines stick in the long run.
Most teams won't implement hypothesis and experiment records on day one. Getting the basic harness in place — structured requirements, connected artifacts, a repo that functions as the source of truth — creates the foundation. The discipline of writing two separate records, in the right order, against a frozen hypothesis, and then actually making a persevere/kill/pivot call when the evidence arrives: that is Mastery-tier behavior. It takes time to build. It pays forward every time a team avoids a year of investment in a product direction they knew wasn't working but couldn't name as broken.
The two cards are small. The discipline they enforce is not.