Handoffs Between Engagement Teams and Product Teams
A structured record of an engagement answers ten questions covering the underlying problem, customer priorities and non-priorities, the workflow before and after, the data structures, integration points, edge cases, the evaluation set, and what was hard.
The Output Nobody Demonstrates
When people describe what an engagement with a customer produces, they usually point to the working solution. That solution is the visible output, and it is easy to demonstrate. This article covers a second output that rarely gets shown at all: the written trace of what happened during the engagement and what was learned from it. Its material is plain. It consists of careful notes, retrospectives that examine what went well and what did not, and a clear handoff from the engineer who worked the problem out in the field to the product engineering team that will turn that work into something durable.
What do you think happens?
Before reading on, how many questions do you think a structured record of an engagement is organized around?
Reveal answer
Ten
A structured record is organized around ten questions, and each one asks for a specific piece of knowledge about the engagement. The rest of this article walks through what those ten questions are and why the record is built around them.
The question this article answers is simple. If one engagement record looks unremarkable when you read it alone, why would a team spend effort producing it? The answer depends on what the record contains and on what happens when many of them sit side by side. We will first look at the contents, then at accumulation, and finally at the process that produces the record.
Ten Questions Sorted by Purpose
Each of the ten questions asks for a specific piece of knowledge about the engagement. Taken one at a time, they look like prompts for note-taking. Taken together, they cover the problem itself, the change in how work gets done, the technical footprint of the solution, and the human judgments that shaped it.
The ten items fall into four groups, because each group answers a different kind of later question. The diagram below places every item under its group.
- Problem and people: the underlying problem, customer priorities, and customer non-priorities. These record what the customer actually needed and which parts of the solution they surprised everyone by not caring about.
- Workflow: the workflow before the engagement and the workflow after it. These record how the work gets done and how it changed.
- Technical footprint: the data structures used, the integration points touched, and the edge cases that came up. These record what the solution touches and where it bent.
- Evidence and struggle: the evaluation set and what was hard. These record how the solution was judged and where the effort went.
The grouping matters because later readers rarely need all ten answers at once. A product engineer changing an integration will look in the technical footprint group. Someone asking why a feature was deprioritized will look at customer non-priorities. Sorting by purpose makes each answer easy to find when a specific question comes up.
Why One Record Looks Plain
A single structured record is not interesting to read. It is methodical, it repeats the same headings each time, and most of its entries describe a situation that will never recur in exactly the same form. That plainness is intentional. The record is built so that entries from different engagements can be compared, and that comparison is only possible when every record answers the same questions in the same order.
The plainness is therefore a design choice rather than a shortcoming. A record that answered different questions for each engagement would be richer in the moment but impossible to line up against the next one. Consistency is what turns many separate notes into something a team can consult as a whole.
How Accumulation Creates Value
The value appears when records accumulate. The source describes two thresholds. After about ten engagements, the collection of records functions as a manual, something a team can consult to see how similar problems were handled before. After about fifty engagements, the same collection becomes a competitive advantage, because the team holds a body of knowledge about customer priorities, workflow patterns, and recurring edge cases that is hard for others to reproduce quickly.
A Worked Sorting Exercise
Filing a set of engagement notes under the right item
A team has five raw notes from an engagement. Decide which of the ten record items each note belongs to, and which of the four groups that item falls under.
- 1Note A: the customer kept asking about exporting reports, but never asked about the dashboard colors.
The export interest reveals a customer priority, and the unasked dashboard colors reveal a non-priority. Both belong to the problem and people group, under customer priorities and customer non-priorities.
- 2Note B: before the engagement, a reviewer approved each invoice by email, and afterward approvals happen inside the tool.
This describes how work was done before and after. It belongs to the workflow group, split into workflow before and workflow after.
- 3Note C: the billing service and the reporting service had to share an account identifier, and the two timestamp formats disagreed.
A shared identifier and mismatched formats are integration details. They belong to the technical footprint group, under integration points, with the format conflict also recorded as an edge case.
- 4Note D: the test cases were drawn from last quarter's real invoices, not invented ones.
This describes what the solution was judged against, so it belongs to the evaluation set, in the evidence and struggle group.
- 5Note E: the hardest part was getting the approvals to match the old audit trail.
A difficulty the team faced is recorded under what was hard, which sits in the same evidence and struggle group as the evaluation set.
Every note maps to exactly one of the ten items, and each item sits under one of the four groups. A later reader who wants to know how approvals changed would go to workflow after, while a reader asking why the test data was chosen would go to the evaluation set.
Synthesis as the Step That Produces the Record
The record does not write itself. The source names the process that creates it as post-engagement synthesis: the work done after an engagement ends, in order to gather what was learned into the structured form described above. The source states that a template for this synthesis is included in Appendix A, and that the template is meant to produce the record on a reliable cadence.
Regularity matters. Records written sporadically, or only when someone remembers, will not form the consistent collection that makes accumulation possible. Synthesis is therefore a recurring step in the team's process, not an occasional clean-up task.
Read the sequence from left to right. The engineer, whom the source calls the FDE, worked the problem out during the engagement. Synthesis happens after the engagement ends and gathers what was learned. The output is the record. The record is the artifact that carries the knowledge across the boundary to the product engineering team, which must take the work forward.
The source uses an analogy for the two sides of this boundary. It compares the FDE to the builder of a gravel road and the product engineering team to the team that paves a highway. The record is what lets the paving happen without the paver having to rediscover where the road needs to go.
Mistakes Teams Make With Records
Common mistake Treating the working solution as the entire output of an engagement
What it looks likeA team hands over the code and considers the engagement finished.
Why it failsThe source identifies the written trace of what happened and what was learned as a second output, and that is what the product team needs to carry the work forward.
Do this insteadTreat the record as a required deliverable of the engagement, alongside the solution.
Common mistake Writing records only when someone remembers
Why it failsThe source says records written sporadically will not form the consistent collection that makes accumulation possible.
Do this insteadRun synthesis on a regular cadence, using the template in Appendix A.
Common mistake Judging a single record by how interesting it reads
Why it failsThe source says a single record is deliberately plain and repetitive, because its value comes from comparability across engagements.
Do this insteadEvaluate the collection of records over time rather than any one of them.
Common mistake Treating the ten and fifty engagement thresholds as exact rules
Why it failsThe source gives these as its own characterization and does not explain the mechanism behind them.
Do this insteadUse them as rough markers of how value tends to grow, not as precise counts.
Common mistake Answering the record's questions in a different order each time, which breaks comparability
Sorting Your Own Notes
Suppose an engagement produced these three notes. The team noticed that the customer only used the solution on Mondays. The team could not connect to the legacy inventory system until a vendor patch arrived. The team agreed that the old manual process took about two days per batch, and the new process takes about one hour. For each note, name the record item it belongs to and the group it falls under.
Hints
- Ask which of the ten questions each note answers. The Monday usage speaks to the customer's workflow or priorities.
- A connection blocked until a vendor patch is a difficulty the team faced, and it also touches integration points.
- A before and after comparison of how long a process takes describes the workflow group, split into before and after.
Key Takeaways
- A structured engagement record answers ten questions, which can be grouped into problem and people, workflow, technical footprint, and evidence and struggle.
- A single record is deliberately plain and repetitive so that records from different engagements can be compared, and its value grows as the collection accumulates.
- Post-engagement synthesis is the recurring step that produces the record, using the template in Appendix A.
- The record is the artifact that carries knowledge across the handoff from the engineer who built the solution to the product engineering team that must carry it forward.