Discovery Handoff: What the Build Team Needs on Day One
ยท 8 min read
A good discovery handoff gives the build team five things: the agreed scope and priorities, the decisions with the reasons behind them, the open questions and assumptions, the access they need, and one named person who owns changes. Put it all in one document and walk through it in a single meeting. Do not count on the team piecing it together from slides, call recordings and chat threads. Below is the checklist, a 60-minute meeting plan and the rules for what happens after.
Why handoffs lose information
The people who ran the discovery know far more than they wrote down. They remember why a feature was cut, which stakeholder pushed back, and which number in the estimate was a guess. The build team gets the document, not the memory. Information usually goes missing in four places:
- The reasons. A requirement or architecture choice arrives without the reason for it, so the team either follows it blindly or quietly changes it.
- The unknowns. Open questions were discussed on calls but never logged, so nobody knows they are still open.
- The estimate. The number travels and its assumptions do not. A range of 30-40 person-weeks that assumed an existing API turns into a promise once that API proves not to exist.
- The people. The developers do not know who on the client side can answer a question, or who has the final say.
Often the same company runs discovery and delivery, just with different people. The handoff problem is the same, because the people who carry the context are not the ones who build.
What the build team must receive
Use this as the checklist for the handoff package. If an item is missing, write down that it is missing. Do not let it look complete.
| Item | What "done" looks like | Usual owner |
|---|---|---|
| Scope and priorities | Every requirement has a priority (for example Must, Should, Could, Won't) and the first release is agreed in writing | Product owner or PM |
| Requirements | Each Must is testable and has acceptance criteria | Business analyst |
| Users and flows | Main journeys and key processes drawn and reviewed | Designer or analyst |
| Architecture | A context diagram, the integrations, and decision records | Solution architect |
| Estimate and roadmap | Milestones with low-high ranges and the assumptions behind them | Delivery lead |
| Open questions and risks | Each with an owner and a due date | PM |
| Access | Repositories, environments, test accounts, API keys requested through the proper channel, design files | Client IT and PM |
| People | Who answers which kind of question, who approves changes, how fast | PM |
The discovery phase checklist has the questions to ask before you call each of these finished. If you need a refresher on what discovery is meant to produce, see the discovery phase in software development.
Two of these items deserve their own section, because they are the ones most often missing.
Decisions and the reasons behind them
Every significant choice made during discovery should arrive as a short record: the question, the options considered, what was chosen, and what that choice means for the work. This is the architecture decision record (ADR) format Michael Nygard described in 2011. His argument still holds: someone who joins later and does not know why a decision was made can only accept it blindly or reverse it blindly, and both are expensive.
For a handoff, a decision record needs:
- Title and number, so it can be cited ("ADR-4: Use the client's existing identity provider").
- Context: the constraint or pressure behind the choice (a contract, a deadline, a team skill, a cost).
- Options compared, including the ones rejected and why.
- Decision in one or two sentences.
- Consequences: what it makes easier, what it makes harder, what it rules out.
- Status: proposed or accepted. A decision still at "proposed" is really an open question and belongs on the next list too.
Here is how that looks in the Discovery Phase AI example report, built for an invented field-service project called Fieldwise. Each decision has a number, a status and the number of options compared, and links to the requirements it covers. ADR-003 is still proposed, so it goes to the build team as an open item.
Do not limit this to technical decisions. Scope decisions matter just as much: "Offline mode is out of release one because the client's field staff always have coverage" will save an argument three months later.
Open questions and assumptions
No discovery closes every question. What matters is that the open ones are visible, owned and dated. Give the build team two lists:
- Open questions: what is not known yet, who will answer, by when, and what work is blocked until then. "Does the payment provider support partial refunds? Owner: client finance lead. Due: sprint 2. Blocks: refund flow."
- Assumptions: what the plan treats as true without proof. Tie each one to the estimate or milestone it affects. "The client's product API returns stock levels in real time. If not, add 3-5 person-weeks for a sync job."
Mark the blockers separately: questions that stop a milestone from starting. The team should see them on the first day, not on the day the blocked work begins.
In the Fieldwise example, the assumptions sit right under the milestones and their person-week ranges. The first one, that IT will expose two missing API endpoints, is exactly the kind of assumption a build team needs to check in week one.
Discovery Phase AI keeps risks, blockers and open questions as one list on each project, and the project cannot be marked done while any of them is still active. That is one way to make sure nothing is closed quietly. Whatever tool you use, the rule is the same: an unknown that is not written down will be treated as a known.
The handover meeting
One meeting, 60 minutes, with the people who ran discovery, the build team leads and the client's product owner. Send the package two days before and ask everyone to read it. Use the meeting for questions, not for reading slides aloud.
| Minutes | Topic | Who leads |
|---|---|---|
| 0-5 | The goal of the project and the business question release one must answer | Product owner |
| 5-15 | Scope: what is in release one, what is out, what is later | PM |
| 15-30 | Architecture and key decisions, including the rejected options | Architect |
| 30-40 | Estimate, milestones and the assumptions they depend on | Delivery lead |
| 40-50 | Open questions, blockers and risks: confirm each owner and date | PM |
| 50-55 | Access and environments: what is ready, what is still requested | PM and client IT |
| 55-60 | How changes will be raised and approved from now on | Product owner |
Record two outputs. The first is a list of new questions the build team raised, added to the open-questions log with owners. The second is a short note confirming that the build team accepts the package as the starting point, or naming what it does not accept yet. That note is the real end of discovery.
After the handoff: who owns changes
The discovery document becomes the baseline. From then on it should change only on purpose:
- One owner for scope and priorities, usually the client's product owner. The build team can propose changes; that owner approves them.
- Changes are recorded, not overwritten. When a decision is reversed, add a new decision record that supersedes the old one. When an assumption proves false, update the estimate it was tied to and say so.
- Open questions close with an answer, written into the item itself, not into a chat thread.
- The discovery team stays reachable for a set period (the first two or three sprints is common practice) to answer "why" questions.
If you produce the discovery in Discovery Phase AI, the report exports as PDF, Word, PowerPoint or Markdown (Markdown only on the Free plan), so the build team can take the baseline into their own tools. The whole Fieldwise report is in the example report.
A handoff is finished when the build team can start without calling the discovery team on the first day. They will still call later, and those calls should be about details, not about what was decided.