# The project close-out review: how FDEs sort every loose end into three buckets

> If the final meeting ends with nothing more than "everything's fine", the next customer will hit the same problems all over again.

Original: https://fdetimes.net/en/guides/fde-project-closeout-review-three-buckets/

The last week of a deployment is always crowded: handing over accounts, revoking access, sending documentation. The close-out review usually gets squeezed into the final half hour and ends with "everything's fine". A few months later the next customer trips over the same problem, and nobody remembers how it was handled last time.

PostHog's handbook describes FDEs as the people who meet a product's rough edges under real customer load before anyone else. It also states plainly that context gathered in the field helps fix problems faster for the customers who come after.

So the final meeting is not a formality. It is the one time you can be sure the right people are in the room to turn that friction into owned work, before you move on to another project and the knowledge leaves with you.

## Every item goes into one of three buckets

Everything still open when a project closes belongs in exactly one of three buckets. **Lessons** are things that change how you work next time. **Remaining debt** is work the customer or your team still has to do, with an owner and a deadline. **Product issues** are problems only the product team can fix.

Before sorting, filter out one kind of item that does not belong in this technical meeting: commercial requests, such as the customer wanting additional scope. At PostHog, the commercial relationship with a customer belongs to that customer's TAE, TAM or CSM, not to the FDE. Say so at the start of the meeting, note those requests and pass them straight on.

For everything else, the sorting question is: if the next customer runs into this, who will have to fix it? If the answer is the team that owns the feature, PostHog has a clear rule. When an engagement is blocked by something only the product team can fix, the FDE hands the work to that team rather than hacking around it.

The rule guards against a specific risk. Tandem summarises Marty Cagan's critique of the FDE model: the danger is drifting into building bespoke software for each customer. The model works only when what is learned in the field flows back into the shared product instead of settling into custom code.

Whichever bucket an item lands in, the whole meeting needs one shared condition: no blame. The chapter on postmortem culture in Google's SRE book says you cannot "fix" people, but you can fix systems and processes.

The customer must be there too: one guide to closing engagements stresses that the lessons-learned session happens with the customer, not as your team's private retro.

## Picture an analytics deployment

Imagine you have just finished an event-tracking deployment for an e-commerce app. Before the meeting, you gather tickets, messages and notes into a raw list of six items. The table below shows how they are sorted, including one item filtered out before sorting.

| Item | Bucket | Owner | Next step |
|---|---|---|---|
| Sync job to the data warehouse is slow because it runs during the customer's peak hours | Remaining debt | Customer's data engineer | Reschedule the job, with a deadline |
| SDK drops events when users are offline for a long time | Product issue | Team that owns the SDK | Open an issue covering all four points |
| Temporary code working around the SDK bug above | Remaining debt | FDE | Link it in the issue, record a removal date |
| Script that renames old events to new names | Lesson, turned into a tool | FDE | Add it to the internal repo as a reusable template |
| Days lost waiting for access to be granted | Lesson | FDE team | Request access at the kickoff meeting |
| Customer wants an extra custom dashboard | Filtered out first: commercial request | CSM or TAM | Pass to whoever owns the commercial relationship |

Look closely at three rows. The workaround is not hidden: it is recorded as debt and linked to the product issue, so that once the SDK team ships a fix, someone remembers to remove it.

The event-renaming script becomes an asset. PostHog treats building reference implementations, examples and internal tools that speed up later engagements as part of an FDE's job.

The last row is the item filtered out at the start. When the customer raises new scope during the review, the right response is to note it and pass it to whoever owns the commercial relationship, not to make promises at the table.

For product issues, PostHog asks FDEs to notify the team that owns the area and open an issue stating what is broken, who hits it, what it blocks and how to reproduce it. A template you can copy straight away:

```markdown
Title: SDK drops events when the device is offline for a long time

What is broken: events recorded while offline are not sent after the connection returns
Who hits it: e-commerce customer, mobile app, users in areas with weak signal
What it blocks: the checkout funnel report is missing data, the customer does not yet trust the numbers
How to reproduce: turn on airplane mode, navigate a few screens, wait a long time, reconnect, check the events
Current workaround: workaround code in the customer's repo (link), to be removed after the fix
```

## Running the meeting step by step

Before the meeting, send the draft table to the customer so they can add to it. Nobody wants to hear a list of problems for the first time in the middle of a meeting. During the meeting, go through each item, agree its bucket, then agree an owner by naming a specific person, not "the other team".

The hardest step is prioritisation. Google's SRE book poses a question for every review: is the action plan sensible, and are the fixes given the right priority? A product issue marked "low" when it blocks the customer's main report means the meeting has half failed.

**Key point:** A lesson nobody rereads might as well never have been learned.

After the meeting, store the outcome in a shared repository. Google recommends keeping postmortems in a central place where others can find and learn from them, and says bluntly that an unreviewed postmortem might as well never have existed. The guide to closing engagements says much the same: store it where the team will find it next time.

One last task: the same guide points out that closing a project is more than sending the invoice, and that the customer relationship should be handed over deliberately even after the engagement ends. Introduce the customer to the person who will look after them from now on, in the wrap-up email itself.

## Mistakes that make the meeting worthless

The most common mistake is turning the meeting into a trial, along the lines of "who held up the access request?". The customer then goes quiet, and you lose precisely the stories most worth learning from. The second is meeting internally without inviting the customer, which leaves nobody on the customer side to take the items in the remaining-debt bucket.

The third is harder to spot: quietly working around product bugs because it is faster than opening an issue. Every such patch is a piece of bespoke code of exactly the kind Cagan warns about.

PostHog writes that the point of bringing customer problems back is a better roadmap. A patch that lives only in the customer's repo improves no roadmap at all.

The final mistake is the vague issue, a single line saying "SDK has an offline bug". If the product team cannot reproduce it, they will not schedule a fix. The four points in the template above are what turn what you witnessed in the field into work another team can act on.

This skill belongs on your CV as well. PostHog describes feeding lessons back into the product and building reusable tools as part of the FDE role, so it is worth showing rather than just writing "deployed for customer X".

State how many issues you opened for the product team, which ones were fixed, and which tools you built are being reused by later projects. When reading job descriptions, check whether they mention a feedback loop with the product team: it is one sign that the company takes this work seriously.

## Exercise: how would you sort these six items?

Imagine you have just closed a deployment of a customer-support agent. The raw list has six items. One: the product's API times out when ingesting large documents. Two: code that splits files into chunks to work around that bug. Three: the customer's IT team has not yet disabled the test accounts.

Four: the eval suite you wrote to score the agent's answers. Five: the project lost two weeks because nobody knew who on the customer side approved data. Six: the customer asked for pricing to expand to more departments. Sort them yourself first, then read the answer below.

Answer: item six is filtered out first and passed to the CSM or TAM. Item one goes to the product team, with an issue covering all four points. Item two is the FDE's debt, linked in that issue. Item three is debt owned by a named person on the customer side, with a deadline.

Item four is a lesson turned into a tool and added to the internal repo. Item five is a lesson: next time, ask for the name of the data approver at kickoff. If you got item two wrong, reread why the patch must not be hidden.

A project is truly closed when the next customer does not have to pay the price this one already paid.

**Try this week:**

- Reopen your most recent project, list every workaround and open ticket, and sort each item into the three buckets.
- Pick one product bug you had to work around and rewrite it as an issue covering all four points from the template, then send it to the team that owns that area.
- Add a line to your CV describing specifically how you fed customer lessons back to the product team or turned them into reusable tools.

## Sources

- [Working with product engineering - Handbook](https://posthog.com/handbook/forward-deployed-engineering/working-with-product-engineering)

- [Forward deployed engineering overview - Handbook](https://posthog.com/handbook/forward-deployed-engineering/overview)

- [How FDE teams work with product and engineering (without broken telephone) | Tandem](https://usetandem.ai/blog/fde-product-engineering-feedback-loop)

- [Chapter 15 - Postmortem Culture: Learning from Failure](https://sre.google/sre-book/postmortem-culture/)

- [Engagement Closeout & Post-Implementation Review](https://ferdinebi.github.io/software-engineering-with-ai/maintenance-retainer/engagement-closeout/)