A lesson noted but not acted on was never learned.

Section 01

Why most lessons are lost

The standard lessons learned exercise is a meeting at the end of a program where people share what went well and what did not, a note taker writes it down, and the document is filed where nobody will ever open it again. The conversation feels useful in the room, but it changes nothing, because no finding is ever connected to a change in how the next exit will actually be run. The exercise has the form of learning without the substance.

A TSA exit is exactly the kind of program where this waste is most expensive. The same mistakes recur across carve-outs: the dependency that was missed, the knowledge transfer left too late, the testing that was too thin. Each one is painful and each one is preventable, but only if the lesson from the last exit reaches the team running the next. When lessons stay in a filed document, every deal team starts from zero and pays the tuition again.

The fix is to treat lessons learned as a process that ends in changed artifacts, not in a meeting. A lesson is only learned when it has altered a template, a checklist, a criterion, or a way of working that the next exit will inherit. That standard, that nothing counts until something downstream changes, is what separates a real lessons learned process from the ritual version that absorbs effort and produces nothing.

Section 02

Capture as you go

The richest lessons are lost if they are only collected at the end, because memory fades and the detail of what happened in the early weeks is gone by the time the program closes. The best programs keep a running lessons log throughout, where anyone can record an observation when it is fresh: the assumption that proved wrong, the step that took far longer than planned, the handoff that nearly failed. The log captures the texture that a closing meeting cannot reconstruct.

Much of the raw material is already being generated by the rest of the governance machinery. The risk register records the risks that materialized and how they were handled. The issue log records what broke and how long it took to resolve. The gate reviews record where readiness was overestimated. The hypercare record records what surfaced after go live. A good lessons process harvests these existing artifacts rather than relying on people to remember, because the data is already there.

Capture the successes as deliberately as the failures. A program that only records what went wrong teaches the next team what to fear without teaching it what to repeat. The sequencing that worked, the early decision that paid off, the rehearsal that caught a problem are all worth preserving, because reinforcing what works is as valuable as fixing what does not. A balanced log is also one that people are willing to contribute to honestly.

Section 03

From observation to root cause

A raw observation is not yet a lesson. The closing review takes the logged observations and asks why each one happened, pushing past the surface symptom to the cause that could be designed out. A cutover step that ran late is an observation; the cause might be that the duration was estimated without a rehearsal, and that cause is the thing the next program can actually fix. The value is in the root cause, not the symptom.

Run the review in a way that gets honest answers, which means separating cause from blame. People will surface real causes only if doing so does not put a colleague in the firing line, so the review focuses on what in the process allowed the problem rather than who made the mistake. A process that produced a missed dependency is a process to improve; an individual blamed for it is a person who will say less next time and a lesson that stays hidden.

Prioritize the lessons, because not all are worth the same effort to act on. A root cause that nearly derailed the exit and is likely to recur warrants a real change to the playbook. A minor annoyance that cost an hour once may not be worth a process change at all. Ranking the lessons by impact and likelihood, the same lens the risk register uses, keeps the team from spreading its improvement effort thin across findings that do not matter.

Section 04

Converting lessons into changes

This is the step that makes the difference, and the one most processes skip. Every lesson worth acting on becomes a specific change to a specific artifact, with an owner and a date. The lesson that knowledge transfer started too late becomes an edit to the program template that schedules transfer earlier. The lesson that a dependency was missed becomes an added question in the dependency mapping checklist. The lesson is real only once the artifact has changed.

Name an owner for each change and track it to completion like any other action. A lesson assigned to nobody is a lesson that will not be implemented, and a list of agreed changes with no follow through is the same filed document in a different format. The program office holds the list of conversions open until each one is made, so the loop from observation to changed playbook actually closes rather than trailing off after the closing meeting.

Update the durable assets, not just a lessons document. The changes should land in the templates, checklists, runbook structures, and readiness criteria that the next exit will actually pull from, because those are what a future team will use. A lesson that improves the shared playbook reaches every future deal automatically; a lesson that only lives in a retrospective reaches no one. The destination of a lesson is the tool, not the report.

Section 05

The portfolio compounding effect

For a single deal, lessons learned has limited payoff, because the same team may never run another carve-out. For a portfolio, it is one of the highest return activities available, because every lesson captured improves every exit that follows. A buyer running multiple TSAs across the portfolio can turn each exit into an investment in the next, so the tenth carve-out is run with the accumulated discipline of the nine before it.

Make the lessons portable across deal teams, because the value is realized only when the next team inherits them. A lesson trapped in one team's memory dies when that team moves on. A lesson built into the shared playbook, the standard checklists, and the firm's way of running an exit travels to whoever runs the next one. The portfolio that institutionalizes its lessons stops depending on the same individuals being present to avoid repeating mistakes.

Treat the playbook itself as a living product that the lessons process maintains. After each exit, the playbook should be measurably better than before: a sharper criterion here, an added check there, a re sequenced phase elsewhere. That steady improvement, deal after deal, is what turns TSA exit execution from a capability that lives in a few heads into an operating advantage the portfolio owns, which is the entire point of running the process with discipline.

FAQ

Lessons learned questions buyers ask.

What is a TSA lessons learned process?

It is the structured review after a TSA exit that captures what worked, what failed, and what should change, then turns those findings into specific updates to the playbook the next carve-out will use. Without the conversion to action, it is just a retrospective that gets filed and forgotten.

When should lessons learned be captured?

Both during the program and at its close. Capturing lessons only at the end loses the detail of what happened months earlier, so the best programs log lessons as they occur and then synthesize them in a final review while the full arc is still fresh.

How do you make lessons learned actually change anything?

By converting each lesson into a specific owned change to a template, checklist, or process, with someone accountable for making the change. A lesson with no resulting edit to how the next exit will be run has not been learned, only noted.

Why do lessons learned matter more across a portfolio?

Because a portfolio runs many carve-outs, and a lesson captured once can improve every exit that follows. A single deal team might never repeat the mistake, but the next team will unless the lesson is built into the shared playbook they inherit.

Related Reading

More on TSA governance.