Preserve experiment rationale: a discovery-to-requirements lifecycle that keeps evidence usable

Most teams treat discovery like a phase you graduate from. You run the interviews, ship the prototype, A/B test the checkout flow, argue in a room for two hours — and then someone writes a requirement that says "users need a saved-cart feature" and everything that came before gets buried in a Miro board nobody opens again.

Six months later, an engineer asks why the cart persists for exactly 30 days and not 7. Nobody knows. The person who ran the experiment left. The Figma file is archived. The requirement sits there, orphaned from the reasoning that produced it, and the team re-litigates the whole thing from scratch.

That gap — between what discovery learned and what requirements record — is where most product organizations quietly bleed time. The discovery-to-requirements lifecycle isn't a handoff. When it works, evidence flows forward and stays attached to the thing it justifies. When it breaks, requirements become assertions with no receipts.

This piece is about building that connective tissue: treating discovery artifacts and experiment results as first-class inputs that live inside the requirement record, not in some separate research repository that decays the moment the sprint starts.

Why the discovery-to-requirements handoff rots

The core problem is that discovery and delivery use different systems, different vocabularies, and different owners.

Discovery lives in research tools, spreadsheets, recorded calls, and experiment dashboards. Delivery lives in Jira, in requirement docs, in acceptance criteria. The moment you cross that boundary, someone has to summarize. And summarization is lossy by nature. A three-week experiment that produced a nuanced result — "the new onboarding lifted activation by about 8% but only for users who came in through paid channels" — gets compressed into a requirement line that reads "improve onboarding activation." The condition disappears. The channel dependency disappears. The confidence interval disappears.

What tends to happen across a lot of product teams is that the summarization step occurs exactly once, by one person, under deadline pressure. Whatever nuance they didn't capture is gone. There's no versioning on that summary, no link back to the raw evidence, no record of who decided the experiment "won."

A second reason it rots: discovery artifacts have no stable identity. An experiment gets a name in one tool, a different label in the analytics dashboard, and a third phrasing in the requirement. When someone tries to trace back six months later, they're doing keyword archaeology across three systems that don't share IDs. Most give up.

And third — the uncomfortable one — a lot of discovery evidence is inconvenient once delivery starts. If the experiment showed a feature only helped a narrow segment, that complicates the roadmap story. So the evidence quietly gets rounded up into something cleaner. The requirement survives; the caveat doesn't.

What actually breaks when you scale this

At a five-person startup, none of this matters much. The person who ran the experiment is also the person writing the requirement and building it. The evidence lives in their head, and that's fine.

The trouble starts around the point where you have multiple squads, a research function that's separate from the PM function, and a backlog old enough that the people who wrote the early requirements have moved on. Suddenly the lifecycle has real seams, and evidence stops making it across them.

Here's the progression that typically plays out:

The expensive breakage happens at the "scale" row. That's when you get two squads independently running near-identical experiments because neither knew the other had already tested it. That's when a requirement gets reversed in planning, the reversal gets built, and then someone surfaces the original experiment that predicted exactly the outcome you just paid to rediscover.

There's a related failure mode worth naming: evidence that outlives its validity. An experiment result from two years ago, on a product that's changed substantially, gets cited as if it's still true. Without versioning and dates attached to the evidence, teams can't tell fresh evidence from stale. Both look equally authoritative in a requirement doc. This ties closely to the broader problem of how requirements artifacts fail to scale across agile teams — discovery evidence is just one more artifact class that fractures once the org gets big enough to lose shared context.

The mental shift: evidence as an input, not an attachment

The reframe that fixes most of this is small but load-bearing.

Stop thinking of the experiment result as supporting material you attach to a requirement. Start thinking of it as an input the requirement depends on — the same way code depends on a library version. If the input changes, the thing that depends on it should be flagged for review. If the input is deleted, the dependency is broken and you should know about it.

Concretely, that means every requirement carries structured references to:

1. 1
   The discovery artifacts that motivated it (interviews, surveys, journey maps)
2. 2
   The experiments that tested the underlying assumption, with their result and confidence
3. 3
   The decision that converted evidence into a committed requirement, including who decided and what the alternatives were
4. 4
   The version of each of those, so you can tell when evidence has moved on

This is where the discipline overlaps heavily with decision records. If you're already keeping decision records linked to requirements, you're most of the way there — a discovery-to-requirements lifecycle is essentially decision records extended backward to include the raw evidence, not just the conclusion.

A worked lifecycle you can actually run

Walk through the flow end to end using a realistic example, not an abstract diagram.

1. 1
   Frame the assumption. Discovery produces a hypothesis

   "New subscribers churn early because the first box feels generic." This becomes a discovery artifact with an ID — call it DISC-114 — containing interview clips and the churn cohort data that suggested the problem.

2. 2
   Run the experiment against it. The team ships a personalized first box to a test group. Experiment EXP-207 records the design, the sample (roughly 2,400 subscribers per arm), the primary metric, and the result: about a 6% relative reduction in 60-day churn, with the effect concentrated in subscribers who filled out the preference quiz.
3. 3
   Hit a decision gate. Before anything becomes a requirement, evidence passes through an explicit gate. Someone — named, dated — reviews EXP-207, notes the conditional nature of the result, and decides to commit. That decision (DEC-58) records the alternatives considered and the caveat that the effect depends on quiz completion.
4. 4
   Write the requirement with trace links. The requirement now reads roughly: "First box is personalized for subscribers who complete the preference quiz," and it carries live links to DISC-114, EXP-207, and DEC-58. The 6% figure and the quiz-completion condition are in the record, not lost in translation.
5. 5
   Version the evidence. Six months later, the product changes the quiz. EXP-207's conditions no longer fully hold. Because the requirement is linked to a versioned experiment, the system can flag it as resting on evidence that may be stale — prompting a re-check rather than silent drift.

A simple visual of the lifecycle:

The difference between this and the usual flow is the decision gate and the versioned links. Most teams have steps 1, 2, and 4 in some form. What they skip is the explicit gate at step 3 and the versioning at step 5. Those two are what keep evidence usable a year out instead of merely present.

The decision gate is the part everyone skips

Worth spending more time here, because it's where the real value hides.

A decision gate isn't bureaucracy. It's the single point where you force the question: does the evidence actually justify this requirement, and under what conditions? Without it, evidence and requirements get connected by proximity — "we ran an experiment, then wrote a requirement, therefore the experiment justifies the requirement." That's a correlation, not a decision.

A good gate produces a short, structured record answering:

1. 1
   What did the evidence actually show, including the inconvenient parts?
2. 2
   What alternatives did we consider and reject?
3. 3
   What conditions does this result depend on?
4. 4
   What would make us reverse this decision?
5. 5
   Who made the call, and when?

That second-to-last question — what would make us reverse this — is the one almost nobody writes down, and it's the most valuable line in the whole record. It turns a static decision into a tripwire. When conditions change, you already know what you were watching for.

One pattern worth flagging: teams that adopt gates often over-formalize them early, requiring a gate for every backlog item. That collapses under its own weight in about a sprint. Gates belong on requirements that (a) cost real money to build or (b) reverse a prior decision. Everything else can carry a lightweight evidence link without a full gate.

When this makes sense — and when it's overkill

When it makes sense:

1. 1
   You have separate research and delivery functions, so evidence has to survive a handoff between people.
2. 2
   Your product is old enough that "the person who knows why" keeps leaving.
3. 3
   You operate under audit, compliance, or investment-gate pressure where "why did you build this" is a question you'll actually be asked.
4. 4
   You run enough experiments that duplicated or contradicted work is a real cost.

When it's a bad idea:

1. 1
   You're a small team where everyone was in the room for every decision. The overhead will slow you down and buy nothing.
2. 2
   You're pre-product-market-fit and pivoting weekly — your evidence has a shelf life measured in days, and formal versioning is theater.

Who should not do this: any team that would adopt the artifacts without the decision gate. If you link experiments to requirements but never explicitly decide whether the evidence justifies the requirement, you've added filing overhead and captured none of the reasoning. More work, same amnesia.

A short real scenario

A mid-sized fintech with about four product squads had a recurring pattern: features would ship, then get quietly rolled back two or three quarters later when someone questioned them, and nobody could produce the original justification. Their research team estimated somewhere around a quarter of their experiment throughput was rediscovery, not discovery — retesting assumptions they'd already validated and then lost track of.

They didn't buy a new tool at first. They added two things to their existing requirement template: a mandatory link field for the source experiment, and a five-line decision block with the "what would reverse this" line included. Gates were required only for requirements above a rough effort threshold.

Within a couple of quarters, the change was less dramatic than you'd hope but more useful than you'd expect. The rollback-and-rediscover cycle got noticeably rarer, because reversals now surfaced the original evidence before the reversal got built. Planning arguments got shorter — "we tested that, here's the result" became a two-click answer instead of a two-day investigation. Their own estimate put rediscovery waste down to low single digits. Not zero, but a lot cheaper than a quarter of their capacity.

Nothing about that required exotic tooling. It required treating evidence as a dependency and putting a decision on the record.

Making it stick without drowning in process

The failure mode for any traceability practice is that it works for one quarter, then decays the moment a deadline hits. A few things keep this alive:

“

Make the decision block short and mandatory so it gets filled in consistently.

1. 1
   Keep the evidence link mandatory but the decision block short. Long templates get skipped. A five-line decision block gets filled in.
2. 2
   Date and version everything. Undated evidence is unusable evidence within a year.
3. 3
   Automate the staleness flag. You want the system nudging you when a requirement's underlying experiment has changed, not a human remembering to check. This is where operational tooling earns its keep — a platform that watches trace links and flags when an upstream experiment or artifact version has moved lets the team maintain the lifecycle without someone babysitting it full time.
4. 4
   Review orphaned requirements quarterly. Any requirement with no linked evidence is either legacy debt or an untested assumption. Both are worth knowing about.

The value of this whole system isn't the tidy audit trail — it's that you stop paying to relearn things you already knew. Every experiment your organization runs is an expensive purchase. Requirements are supposed to be how you keep what you bought. When the evidence gets stripped off on the way into the backlog, you're buying knowledge and then throwing away the receipt, and you'll end up buying it again.

Get the discovery-to-requirements lifecycle right and the reasoning stays attached to the requirement for as long as the requirement lives. That's the whole point: not more documentation, but evidence that's still usable the day someone finally asks why.