Handoff Between Solution and Product Teams
The engagement documentation is a structured record, not a slide deck, and it exists so that a team inheriting the work can continue it.
Predicting Which Artifact a Successor Needs
When a piece of engineering work for a customer finishes, a common instinct is to summarize it for everyone else in a presentation. The slides show what was built, what went well, and perhaps a chart or two about results. It feels like documentation because it is written down and shared. This article examines that instinct, because it leads teams to hand over the wrong kind of artifact at exactly the moment the next team needs the right one.
The source describes the work in a two-output framing. One output is the product or solution delivered to the customer. The second output is the set of artifacts that carry what was learned. This article is concerned only with that second kind of output, and specifically with the documentation that gets handed across a team boundary, from the team that built the solution to the team that will continue it.
What do you think happens?
Suppose a product engineering team must later extend a solution that another team built for a customer. Which artifact is most useful to them: a slide deck summarizing the engagement, or a structured record of the engagement?
Reveal answer
A structured post-engagement record built for the person who continues the work
The source is direct that the documentation is not a slide deck. A slide deck is built to persuade an audience in a single sitting, while the record is built for a reader who has to continue the work without having been present for it.
Two Teams and the Gravel Road
The source frames the two teams with a metaphor. The FDE team builds a gravel road, a working route that gets the customer where they need to go. The product engineering team then has to pave the highway that follows. The handoff is the explicit step that moves the knowledge from the first team to the second. Documentation is part of that step, along with structured retrospectives.
Follow the engagement record through the handoff. The FDE team produces the record before responsibility passes to the product engineering team. A template in Appendix A supports producing it consistently. The diagram below traces that ordering. The source gives only this simplified sequence, so the diagram adds no internal steps beyond it.
The key point of this sequence is that the receiving team has the record in hand when responsibility moves. The handoff is not complete merely because the work was shown to someone. It is complete when the inheriting team holds a record it can use to continue the solution.
Slide Deck Versus Structured Record
The source is explicit that the documentation is not a slide deck. A slide deck is built to persuade an audience in a single sitting and tends to keep the story that makes the work look finished. The structured record is built for a different reader: the person who has to continue the work without having been present for it. That reader needs facts they can look up, compare, and check, not a narrative arranged for a room.
| Aspect | Slide deck | Structured post-engagement record |
|---|---|---|
| Built to | Persuade an audience in a single sitting | Serve a reader who must continue the work |
| Tends to keep | The story that makes the work look finished | Facts the reader can look up, compare, and check |
| Organized around | A narrative arranged for a room | Questions a future engineer needs answered before touching the solution |
| Can a new team continue from it? | Not what it was designed for | Yes, this is its purpose |
Slide deck versus structured record, based on the source's description of each artifact
The difference is not only in tone. The record is organized around questions rather than around outcomes. Each field answers a question that a future engineer, reviewing the work, would need answered before touching the solution. A slide deck organized around outcomes answers 'what did we achieve', which is a different and less useful question for the inheriting team.
Contents of the Structured Record
The record described in the source is called the post-engagement synthesis. Each of its branches is one category the record must capture.
The source lists the following categories of content: the underlying problem, the workflow before and after, data structures, integration points, edge cases, the evaluation set, what the customer cared about and did not care about, and what was hard. The diagram below shows how these categories group around the single record.
Filling in one entry of the record
A team delivered a reporting tool for a customer. The customer requested a dashboard, but after delivery they only ever used the exported spreadsheet. How should the record capture this for the next team?
- 1Identify the category
This fact belongs under what the customer did not care about, because it shows where the dashboard effort was not valued.
- 2State the fact plainly
Record that the customer requested a dashboard and in practice used only the exported spreadsheet, without adding narrative about the project's success.
- 3Connect it to the question
A future engineer deciding whether to extend the dashboard can now see that the effort may not be worth repeating in the same form.
The record captures a checkable fact about customer priorities that a slide showing a finished dashboard would hide.
Why the Record Grows Over Repeated Engagements
The source makes a claim about time: the record is dry, and its value is cumulative. A single record from a single engagement is useful but modest. The source describes a trajectory in which value accumulates. After ten engagements, the record becomes a manual. After fifty, it becomes a competitive advantage.
The reason this matters is that the record's worth comes from comparison across engagements. Each new entry lets a team see which problems recur, which edge cases appear again, and which evaluation sets have proven reliable. A handoff therefore starts with a body of history rather than a single engagement's account.
Comparison only works if the entries are written the same way. A record written differently each time cannot be compared, so the cadence and structure supplied by the template carry real weight. The source notes that the template is what makes the record get produced on a reliable cadence rather than only when someone remembers to write it. The template is the mechanism for consistency, and the categories are what the template asks for.
Mistakes When Producing the Record
Common mistake Handing over a slide deck as the engagement documentation
Why it failsA slide deck is built to persuade a single audience and tends to keep the story that makes the work look finished, so the inheriting team cannot look up, compare, or check the facts they need.
Do this insteadProduce a structured post-engagement synthesis organized around the questions a future engineer must answer.
Common mistake Recording only what the customer asked for
Why it failsThis misses the signals showing where effort was wasted, which the source identifies as the entry 'what the customer did not care about'.
Do this insteadInclude both what the customer cared about and what the customer did not care about.
Common mistake Leaving out what was hard
Why it failsThe difficult parts are the places most likely to break or need rework, so an inheriting team that does not know them is exposed to those risks.
Do this insteadRecord the hard parts explicitly as one category of the synthesis.
Common mistake Writing each record in a different shape
Why it failsA record written differently each time cannot be compared across engagements, which is where its value comes from.
Do this insteadUse the Appendix A template so that every record follows the same structure and cadence.
Checking Your Understanding of the Handoff
A colleague proposes that, at handoff, the FDE team should send only the final slide deck from the customer presentation, since it already shows what was built and the results. Using the source's distinction between a slide deck and a structured record, explain why this would fail the product engineering team. Then name two categories from the post-engagement synthesis that the slide deck is unlikely to contain.
Hints
- Think about who the reader is: a person who must continue the work without having been present for it.
- The source names what the customer did not care about and what was hard as easy-to-omit entries.
- Consider which artifact is organized around questions and which around outcomes.
Key Takeaways
- The post-engagement synthesis is a structured record, not a slide deck, and it exists so that the team inheriting the work can continue it.
- The record is organized around questions and covers the underlying problem, the workflow before and after, data structures, integration points, edge cases, the evaluation set, what the customer cared about and did not care about, and what was hard.
- The FDE team produces the record before responsibility passes to the product engineering team, and the Appendix A template supports producing it consistently.
- The record's value is cumulative: it becomes a manual after ten engagements and a competitive advantage after fifty, because its worth comes from comparison across consistently structured entries.