The project close-out review: how FDEs sort every loose end into 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:

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.

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.