Module 5: Handoff and Productization · FDE Course

A pilot that succeeds technically but cannot be handed off is a dead end. The product team cannot build on something they do not understand. The customer cannot maintain something the FDE owns. This module covers when to hand off, how to document pilot work so it survives the FDE's departure, and how to prevent the zombie pilot: a system that technically works but has no one responsible for keeping it alive.

The Zombie Pilot Problem

A zombie pilot is a deployed system that technically works but has no clear owner, no maintenance plan, and no path to further development. It consumes a customer resource (a server, a API key, staff time to run it), delivers some value, and slowly decays as the customer's data changes, the API it calls updates its interface, or the edge cases it cannot handle accumulate.

Zombie pilots are common in enterprise AI deployments. They happen when the FDE leaves before a clear handoff occurs, when no product team resource is assigned to the work, or when the customer organization changes structure and the internal champion who drove the pilot moves to a different team. Six months after a successful pilot, the system is still running. A year later, no one knows who owns it. Two years later, it breaks and no one fixes it.

Preventing the zombie pilot problem is not a technical challenge. It is an organizational one. The technical solution is already in the pilot. The organizational solution requires explicit decisions about ownership, maintenance, and development priority before the FDE disengages.

The zombie pilot test Before ending an engagement, ask: if I were unavailable for six months starting tomorrow, what would happen to this system? If the answer is "it would slowly break and no one would be able to fix it," the handoff is not complete.

Three Signals the Pilot Is Ready for Handoff

Signal 1: The success criteria are met. The scoping document specified what the pilot needed to demonstrate. When those criteria are satisfied, the pilot phase is complete and productization should begin. FDEs who continue building past the success criteria are doing product engineering work without the product team's involvement, which creates integration problems later.

Signal 2: A named product owner exists. A pilot is not ready for handoff until there is a specific named person on the product team who has agreed to own the work. Not a team, not a department. A named individual with the authority and capability to make decisions about the system going forward. If that person does not exist, the handoff conversation is the process of finding them.

Signal 3: The customer has a named internal champion. On the customer side, there must be someone who cares about the system surviving beyond the FDE engagement. This is usually the stakeholder who sponsored the discovery sprint. Confirming their continued involvement before handoff protects against the organizational change scenario.

Writing the Handoff Document

The handoff document is not source code documentation. It is an architectural overview, decision log, and operating guide combined into a single document the product team can read in under an hour. It answers five questions that a new engineer would ask about the system if they inherited it tomorrow:

Text · FDE Handoff Document Structure

FDE HANDOFF DOCUMENT
System: [Name]
Customer: [Name]
FDE: [Name]
Date: [Date]
Product owner: [Named individual + contact]

1. WHAT THIS SYSTEM DOES (2 paragraphs)
Plain-English description of what the system does for the user.
Not the architecture. What the user experiences and what
business problem it solves.

2. HOW IT WORKS (architecture overview)
- Data flow: where data comes from, how it moves through
  the system, where it ends up
- Key components: what each major component does
- External dependencies: APIs, services, credentials required
- Infrastructure: where it runs, how to access it

3. DECISIONS AND WHY (decision log)
List the three to five most significant architectural or
approach decisions made during the pilot, and the reasoning.
This prevents the product team from reversing decisions that
were made for non-obvious reasons.

4. WHAT DOES NOT WORK (known limitations)
- Edge cases the system fails on (with examples)
- Data quality issues that affect performance
- Scale limits: what happens if volume exceeds [N]

5. HOW TO EXTEND IT (next steps)
- What Phase 2 features were deferred during discovery
- Recommended first three improvements in priority order
- What would need to change to handle [specific edge case]

6. RUNBOOK (how to operate it day to day)
- How to add new documents
- What to do if the API call fails
- Where to find logs
- Who to call if it breaks

The FDE-to-PM Handoff Protocol

The handoff is not a document drop. It is a structured conversation with a minimum of two meetings. The first meeting is a technical walkthrough: the FDE walks the product manager and any engineers who will own the work through the system architecture, the decision log, and the known limitations. The second meeting is a planning session: the product team and the customer agree on what will be maintained as-is, what will be improved in the next phase, and who is responsible for each item.

Between those meetings, the product team should run the system independently, without FDE support, for at least a week. If they encounter problems during that week, those are problems the handoff document needs to address before the FDE disengages. Discovering the documentation is insufficient after the FDE has left is a common and avoidable failure.

Fig 5 · FDE-to-PM Handoff Protocol

What happens when a customer's internal champion leaves before the handoff is complete? ▼

This is the most common cause of zombie pilots. The pilot was built for a specific champion who drove the engagement. When that person leaves, the organizational priority they represented often goes with them. The structural fix is to identify a second internal champion before the primary one leaves, and to ensure the handoff document is clear enough that the second champion can understand and advocate for the system without any FDE involvement. The best FDE handoffs make the champion redundant: the system is documented well enough that any senior stakeholder can understand its value and own the next-phase decision.

Try this

Think of a project you handed off in the past, or received from someone else. Apply the zombie pilot test: if the person who built it had been unavailable for six months starting the day after handoff, what would have happened? Where was the documentation insufficient? This exercise usually reveals that the decision log (why choices were made) is the section most often missing from handoff documents.