Open your team’s decision history, if you have one, and read an entry from three months ago. “We decided to build X.” Now try to answer why. Not the story you remember, the evidence that was actually on the table when the call was made. What did you know? What were you assuming? What would have changed your mind? For most decisions, that information is gone. The decision survived. Everything that justified it evaporated.
Engineering solved a version of this problem and gave it a name. Done means done. A claim that a task is complete is worth nothing on its own, because it is trivially easy to declare. What makes it trustworthy is the proof traveling with the claim: the test that ran, the output it produced, the contract it ran against. The completion and its evidence move together or the completion is just a sentence. Product decisions need the same rule, and almost never get it.
A decision without evidence is a rumor with a timestamp
Say it plainly, because the softer version lets everyone off the hook. A decision recorded as “we chose X” and nothing else is not a decision anyone can audit. It is a rumor with a timestamp. You know a choice was made and roughly when. You do not know on what basis, which means you cannot tell later whether it was a good call that aged badly or a bad call that got lucky, and you cannot tell whether the thing that justified it is still true.
This matters more now, not less, and the reason is the same one that reshaped product management in the AI era. When building was the expensive part, the volume of decisions was naturally throttled by how much you could build. Now agents build in hours, so you make more calls, faster, on thinner deliberation. The rate of decisions went up and the evidence per decision went down. A team can now accumulate a quarter of unauditable choices in a month, and discover only when something breaks that it cannot reconstruct why any of it was built.
What “evidence attached” actually means
Evidence-based product decisions is a concrete discipline, not a value. When a decision closes, three things attach to it and travel with it.
The evidence that supported it. Not a summary of a feeling. The actual inputs: the user signal, the usage data, the specific thing you saw or heard that pointed this way. If the real answer is “a strong hunch,” that is allowed, and it gets recorded as a hunch, which is a very different record from “the data said so.” The record has to preserve which one it was.
The assumption it rests on. Every decision has a load-bearing belief underneath it, the thing that, if false, would make the decision wrong. Naming it is most of the value, because an unnamed assumption cannot be revisited when the world changes. “We decided to build X, assuming Y” is auditable. “We decided to build X” hides Y where nobody can check whether it still holds.
The disconfirming test. What would tell you this was wrong, and when you will look. A decision with no disconfirming test is a decision you have quietly made unfalsifiable, which means you will defend it forever regardless of what happens, because you never said what failure would look like.
Not every source earns the same claim
Here is the part most decision records get wrong, and it is the same discipline that governs a product graph’s reverse-intake layer: the strength of a claim is capped by the strength of what backs it, and mixing the two is how confident-sounding decisions get built on nothing.
| What you want to claim | What it needs | What it does not survive |
|---|---|---|
| “Users feel this pain” | real users, observed behavior | a model’s plausible guess about users |
| “This will move the metric” | a prior result or a run | an analogy to a different product |
| “We decided this on purpose” | a recorded human choice | a default nobody questioned |
| “This is the cheapest bet” | a comparison you actually did | the first option that looked fine |
The rule is not that hunches are forbidden. It is that a hunch has to be recorded as a hunch and never laundered into “the evidence showed.” When a decision attaches its evidence, the reader can see the difference between a call backed by observed user behavior and a call backed by a confident sentence, and weigh them accordingly. When the evidence is missing, everything reads with the same false certainty, and the weakest-backed decisions are indistinguishable from the strongest.
AI makes attaching evidence easy and skipping it dangerous
There is a symmetry worth noticing. The same speed that makes decisions cheap also makes it cheap to attach their evidence. An agent can pull the usage numbers, gather the relevant signals, and draft the assumption and the disconfirming test as fast as it can produce the prototype. The friction that used to make good decision hygiene expensive is mostly gone.
The danger is that AI is also very good at producing the confident-sounding decision without any of it. Ask a model for a recommendation and it will give you a fluent, structured, plausible answer with no evidence attached and no assumption named, and it will read like rigor. That is the failure mode: a decision that looks deliberated because it is well formatted, resting on nothing you could check. Attaching evidence is what separates a real decision from a well-written guess, and the better the writing gets, the more that separation depends on the evidence being there rather than the prose sounding sure.
The audit test
The measure of whether you are doing this is simple. Pick a decision from a quarter ago and try to audit it cold, without asking anyone. If you can see what was known, what was assumed, and what would have proven it wrong, the decision was closed with its evidence attached. If you can only see that a choice was made, you have a timestamp and a rumor, and you are about to re-argue from memory a debate you already had, with worse information than you had the first time.
Run this on ten decisions. The ratio tells you how much of your product’s reasoning is auditable and how much has already evaporated. Most teams are shocked by the number, and the number gets worse exactly as decision velocity goes up, which is to say exactly as agents make you faster.
Where PaellaDoc fits
PaellaDoc treats a decision as a first-class record, not a line in a chat. A decision closes with the evidence that supported it, the assumption it rests on, and the disconfirming test attached, and it links to the artifacts it authorized, so the reasoning stays auditable as the product grows around it. The goal is the product version of done means done: a decision you can open months later and reconstruct, instead of a choice you can only remember making.
Deciding got expensive because building got cheap. The way you keep expensive decisions from turning into expensive mistakes is to stop letting the evidence walk away from the decision the moment the decision is made.
Frequently asked questions
What are evidence-based product decisions?
It is the product version of “done means done”: a decision does not close until the evidence that justified it travels with it. “We chose X” on its own is a rumor with a timestamp, you know a choice was made and roughly when, but not on what basis, so you cannot later tell a good call that aged badly from a bad one that got lucky. The evidence and the decision move together or the decision is just a sentence.
What should I attach to a product decision?
Three things that travel with it when it closes. The evidence that supported it, the actual user signal or usage data, recorded as a hunch if that is what it was. The assumption it rests on, the load-bearing belief that, if false, makes the decision wrong. And the disconfirming test, what would tell you it was wrong and when you will look. Without the third, you have made the decision quietly unfalsifiable.
How do I audit a past product decision?
Pick a decision from a quarter ago and try to audit it cold, without asking anyone. If you can see what was known, what was assumed, and what would have proven it wrong, it was closed with its evidence attached. If you can only see that a choice was made, you have a timestamp and a rumor. Run it on ten decisions; the ratio tells you how much of your reasoning is still auditable.
What is a disconfirming test in a product decision?
It is naming, in advance, what would tell you the decision was wrong and when you will look. A decision with no disconfirming test is one you have quietly made unfalsifiable: you will defend it forever regardless of what happens, because you never said what failure would look like. Naming it turns a decision from an opinion you protect into a bet you can settle.