Move work from discovery to delivery by minimizing the number of handoffs first, then treating any that remain as a transfer of rationale, not just requirements. Engineers inherit the why — the evidence, the decisions made and rejected, the open questions — alongside the acceptance criteria, instead of a stripped ticket that only tells them what to build.
Quick answer: A discovery-to-delivery handoff loses context because acceptance criteria only encode conclusions, not reasoning. Fix it by reducing handoffs where you can, and where a handoff is unavoidable, attaching evidence, decision history, and open questions to the spec itself — not a separate deck nobody reopens.
Why the Discovery-to-Delivery Handoff Leaks Context
A handoff leaks context because the artifact that crosses it — a ticket, a one-pager, a set of acceptance criteria — is built to describe what to build, not why it's the right thing to build. Everything that shaped the decision stays behind with whoever made it, unless someone deliberately carries it forward.
This isn't a documentation problem you can write your way out of. It's structural: a handoff is a compression event. Whatever doesn't fit the format gets discarded, and rationale rarely fits a ticket template.
What Acceptance Criteria Can't Carry
Acceptance criteria are good at one thing: stating a testable condition. They're bad at almost everything else that made the decision correct in the first place.
- The evidence that justified the feature — the interview quote, the support-ticket pattern, the
JTBDopportunity score that ranked this problem above the other nine on the list. - The alternatives considered and rejected, and why. A criterion says "show a confirmation modal," not "we tried inline validation first and it failed usability testing twice."
- The confidence level behind the decision. A well-tested assumption and an educated guess can produce identical acceptance criteria and read as equally certain.
- The open questions that were still live when the spec shipped, because someone decided "good enough to start" beats "perfect but late."
Ron Jeffries, who co-created the original user-story format at Chrysler's C3 project, named this gap directly with his Three C's: a story is a Card (a placeholder), a Conversation (where the real understanding gets built), and Confirmation (the tests that prove it). The card was never meant to be self-sufficient — it's a reminder to have a conversation, not a substitute for one. Most teams keep the card and lose the conversation.
The Real Cost: Rebuilt Assumptions Mid-Sprint
When rationale doesn't travel, engineers hit a fork mid-build: guess at intent, or stop and ask. Both are expensive. Guessing risks building the wrong thing correctly; asking means someone has to reconstruct a decision from memory, days or weeks after making it.
The Standish Group's long-running CHAOS Report has, for decades, kept incomplete or poorly understood requirements near the top of the list of reasons software projects run over budget, slip schedule, or get scrapped outright. That's not a documentation-volume problem — plenty of over-documented projects still fail this way. It's a shared-understanding problem wearing a paperwork costume.
The tell isn't a missing document. It's an engineer who can restate what the feature does but not why it matters, three days into building it.
The Mental Shift: Minimize Handoffs, Don't Just Improve Them
The highest-leverage fix isn't a better handoff template — it's fewer handoffs. Every point where work changes hands is a point where context can drop, so the first question isn't "how do we document this better" but "does this need to be a handoff at all."
Most PM teams reach for documentation first because it feels like control. But a document is a lossy compression of a conversation that already happened in someone's head — writing a better document just makes the compression artifact prettier, not more complete.
Why Fewer Handoffs Beat Better Documents
A product trio — PM, designer, and tech lead — working discovery together doesn't need a handoff between discovery and delivery, because the person who'll build the thing was in the room when the decision got made. Marty Cagan and the Silicon Valley Product Group have argued for close to two decades that this is what separates empowered product teams from feature teams fed by a relay of documents: the engineer isn't downstream of the decision, they're a co-author of it.
That's the structural fix behind our guide to running discovery and delivery as parallel tracks — when a tech lead sits in weekly discovery touchpoints instead of receiving a finished spec, there's no seam for the "why" to fall through. The handoff isn't improved. It's deleted.
When a Handoff Is Unavoidable, Transfer Rationale Not Just Requirements
Not every team can staff a full trio on every initiative, and not every handoff can be designed away — a platform team picking up a spec from a product team, a contractor squad, a re-org that splits ownership mid-project. When a real handoff exists, the job changes from "write a clear ticket" to "transfer a decision, including how it was made."
| What a requirements-only handoff transfers | What a rationale-carrying handoff transfers |
|---|---|
| The feature description | The problem the feature solves, and for whom |
| Acceptance criteria | Acceptance criteria plus the evidence each one is based on |
| A single "approved" design | The design, plus alternatives rejected and why |
| A priority ranking | The priority ranking, plus the tradeoff that produced it |
| A due date | A due date, plus what happens to the outcome if it slips |
| Silence on uncertainty | An explicit list of what's still assumed, not confirmed |
Gojko Adzic, who wrote Specification by Example, makes a related point about living documentation: a spec earns the right to be trusted only if it stays connected to the conversation and the tests that back it, updating as understanding changes — not a snapshot frozen the day discovery "finished."
Shared Understanding Over Documentation: The Principle
The Agile Manifesto's contributors ranked "working software over comprehensive documentation" among their four core values for a reason: a document is evidence that understanding might exist, not proof that it does. Shared understanding is the actual deliverable; documentation is, at best, a byproduct of building it.
Alistair Cockburn, one of the manifesto's signatories, put the mechanism plainly in the twelve principles behind it: face-to-face conversation is "the most efficient and effective method of conveying information to and within a development team." A document can support that conversation. It can't replace it and still carry the same information.
What "Shared Understanding" Looks Like in Practice
Jeff Patton, who created story mapping specifically to prevent teams from losing the whole picture inside a flat, ticket-by-ticket backlog, has made the same case from a different angle: the map isn't the point — the shared mental model the team builds while making it is. A backlog is what's left after the understanding has already been built somewhere else.
In practice, shared understanding beats documentation on three fronts:
- It survives questions documentation can't answer. When an engineer asks "what if the user does X instead," a team with shared understanding can reason from the why; a team with only a ticket has to go find whoever wrote it.
- It degrades gracefully. A person who was in the room but skipped the doc still knows more than a person who read the doc but wasn't in the room.
- It catches drift early. Misunderstandings surface in conversation, in real time. In documentation, they surface in a demo, three weeks and one sprint too late.
None of this argues against writing things down — a spec that nobody can point to invites exactly the kind of drift this section warns about. It argues against treating the document as the transfer mechanism, when the transfer mechanism is actually the conversation the document is supposed to preserve.
The Handoff Checklist: What Must Travel With the Work
Whatever crosses from discovery to delivery — whether that's a formal handoff or just work moving from "exploring" to "committed" inside one trio's own backlog — should carry four things besides the requirement itself: evidence, decisions, alternatives, and open questions.
Treat this as a minimum bar, not paperwork. Each item takes minutes to attach if it's captured as discovery happens, and hours to reconstruct if it isn't.
| Must travel with the work | Why it matters | What it looks like in the spec |
|---|---|---|
| Evidence | Separates "we tested this" from "someone was confident" | Interview notes, a JTBD opportunity score, a journey-map dip, usage data |
| Decisions made | Prevents engineers from silently re-deciding something already settled | The chosen approach, stated as a decision, not just an outcome |
| Alternatives rejected | Stops good-faith re-litigation mid-sprint | The runner-up option and the specific reason it lost |
| Confidence level | Tells engineers where it's safe to push back vs. where it's settled | "Validated with 6 users" reads differently than "PM's best guess" |
| Open questions | Prevents a false sense of completeness | A named list of what's still unknown, not silence implying certainty |
| Owner for follow-up | Gives engineers someone to ask instead of guessing | Who to ping when a mid-build question surfaces |
A useful gut-check: if you deleted the acceptance criteria and only kept this table, could an engineer still make a reasonable call on an edge case the ticket didn't cover? If not, the handoff is transferring instructions, not understanding.
This is also where velocity metrics quietly make things worse. A team measured on points burned per sprint is incentivized to treat a fat, well-evidenced ticket as a liability rather than a gift — more to read means slower throughput this sprint, even though it's cheaper for the team over the life of the feature. Our critique of why story points measure the wrong thing goes deeper on how that pressure quietly punishes exactly the handoff discipline this checklist asks for.
Building a Cadence That Prevents the Leak Before It Starts
The checklist above is a repair kit for handoffs you can't avoid. The better long-term fix is a working cadence where discovery and delivery share enough real-time contact that there's rarely a cold handoff to repair in the first place.
Teresa Torres, whose Continuous Discovery Habits has become close to a standard reference on this, argues for weekly customer touchpoints that the whole trio — not just the PM — has visibility into. When the tech lead has seen the same evidence the PM has, "why are we building this" stops being a question that requires a document to answer.
Three Structural Habits That Keep Rationale From Evaporating
- Attach evidence to the spec section it justifies, not a separate deck. A journey-map dip at onboarding becomes the stated reason a section exists, right next to the requirement it produced — not background color in a slide nobody reopens.
- Write decisions as decisions. "We chose X over Y because Z" is a sentence, not a document. It costs almost nothing to capture at the moment a decision is made and a lot to reconstruct later.
- Keep a running, visible list of open questions instead of letting a spec read as more settled than it is. An honest "we don't know yet" is more useful to an engineer than false confidence.
Where the PM/PO split gets involved, ownership of this cadence needs a clear owner too — otherwise "who's responsible for the handoff" becomes its own unanswered question. Our breakdown of where PM and PO responsibilities actually diverge is worth reading before assuming the handoff belongs to whichever title happens to write the ticket. And if your team is still working out the sprint mechanics this cadence assumes, our complete guide to agile delivery covers that foundation from the ground up.
Where Prodinja Fits
This is the exact seam Prodinja's prototype is built around: the moment discovery work turns into something engineering can start on. Spec Studio's living PRD is designed to hold Customer Jobs opportunity scores and Customer Journey evidence directly inside the spec sections they justify, with PR-style diffs keeping a decision's history visible instead of overwritten.
The prototype's engineering hand-off export is designed to carry that same context forward rather than flattening it into a stripped ticket:
- The evidence behind each requirement, not just the requirement.
- The decisions made and the readiness-gate checks that were satisfied before the section moved toward hand-off.
- The open questions that were still live when the export was generated.
It's an honest attempt at the principle in this article, not a claim that a tool alone solves a team-communication problem — the weekly conversation still has to happen.
If your discovery work already produces the kind of evidence a spec should hold — a Customer Journey emotion curve or a JTBD opportunity score, for instance — our guides to building journey maps that feed the backlog and to the complete Jobs-to-be-Done framework cover how to produce evidence worth carrying across the handoff in the first place.
Key Takeaways
- A handoff is a compression event. Acceptance criteria encode conclusions, not the reasoning behind them, so rationale is exactly what gets left behind unless someone deliberately carries it forward.
- Minimize handoffs before you try to improve them. A
product triomaking decisions together doesn't need to hand off the "why" — the engineer was already there when it was decided. - Where a handoff is unavoidable, transfer rationale, not just requirements — evidence, decisions made, alternatives rejected, confidence level, and open questions.
- Shared understanding beats documentation because it survives questions the document never anticipated and degrades gracefully when someone missed the doc but was in the room.
- The Three C's still apply: a ticket is a card that stands in for a conversation, not a replacement for one — treat it that way even 25 years after Ron Jeffries named it.
- Watch what your metrics incentivize. A team optimizing raw
velocitywill treat a well-evidenced ticket as overhead instead of insurance against rebuilt assumptions mid-sprint. - A weekly discovery cadence with the whole trio present is cheaper than any handoff repair kit, because it prevents the cold handoff from happening at all.
Frequently Asked Questions
How do you hand off a spec from discovery to delivery without losing context?
Attach the evidence, the decisions made (and the alternatives rejected), the confidence level, and any open questions directly to the spec section they justify — not a separate deck. Where possible, avoid the handoff entirely by including the engineer in discovery conversations before the spec is written.
What's the difference between a requirements handoff and a rationale handoff?
A requirements handoff transfers what to build: a feature description and acceptance criteria. A rationale handoff also transfers why: the evidence behind the decision, the options considered and rejected, and what's still uncertain — the context an engineer needs to make good calls on anything the ticket didn't anticipate.
Why do engineers keep rebuilding assumptions that discovery already tested?
Usually because the assumption and its supporting evidence lived in a conversation, a slide, or someone's memory instead of the spec itself. If a spec states a conclusion without the evidence behind it, an engineer who hits an edge case mid-build has no way to tell a well-tested decision from an educated guess — so they re-litigate it from scratch.
Does "shared understanding over documentation" mean product teams shouldn't write specs?
No — it means the spec's job is to preserve understanding that already exists, not to create it from scratch through better writing. Teams still need something durable to point to; the mistake is treating that document as a substitute for the conversation, rather than a record of one that actually happened.
How many handoffs should a discovery-to-delivery process actually have?
As few as the team's structure allows. A product trio working discovery together can often collapse discovery-to-delivery into zero formal handoffs, since the same people carry context across both. Where org structure forces a real handoff — separate teams, contractors, a re-org — treat it as an exception that needs the full rationale checklist, not the default operating mode.