After this lesson, you will be able to:
- Explain the economics that make product feedback the FDE's second deliverable
- Write a field report that core engineering acts on instead of archiving
- Decide which bespoke work generalises and which should stay bespoke forever
- Navigate the standing tension between field teams and product teams
Every lesson so far served one customer. This one serves the next hundred.
The engagement is winding down: system deployed, pilot passed, handover scheduled. In a consulting firm, this is where the story ends and the next statement of work begins. In an FDE organisation, the most valuable artifact of the engagement is still unshipped: what the field learned, packaged so the product absorbs it.
#The economics, stated plainly
A consulting firm's capacity is headcount. Every new customer costs roughly the same effort as the last, so revenue scales linearly with engineers, margins compress, and the product never compounds.
The FDE model bets on a different curve. Each engagement produces two outputs: the customer's working system, and knowledge that makes the next similar engagement cheaper. When that knowledge lands in the product as features, configuration, and defaults, time-to-value falls with every cohort of customers. The lifecycle lesson gave you the test: if the next similar customer is not faster, the organisation is consulting, whatever its titles say.
You are the sensor in that loop. Nobody at headquarters saw the customer's workarounds, felt which integration took three weeks instead of three days, or watched which feature request appeared at the third customer in a row. If you do not carry it back, the signal dies with the engagement.
Across three engagements, you hand-built roughly the same CSV-import-with-validation flow three times, each with small customer-specific tweaks. What is the strongest version of the signal you carry to the product team?