PE teams think they’re ahead on AI. What I see is brilliant individuals, and a fund that hardly benefits from it.

I saw it again while preparing a workshop for a PE team. Many people in PE come from an economics background, so they have a knack for automation. Associates build their own Claude skills for pricing analyses, slides, even automated DDs. Yet each skill lives with the person who built it, and most AI use never gets past the individual. To me that isn’t ambitious enough.

Step one: take context management seriously

Step one is taking context management seriously, both organizational and individual. Claude, ChatGPT, whatever you use, works a hundred times better when you feed it the right context.

I’m heavily inspired by how Andrej Karpathy manages context in Obsidian: a folder of plain markdown files the LLM reads from and keeps up to date itself.

In my own slide work the difference is clear-cut. With good examples and the right instructions on how to behave and draft a storyline, the first draft is already close. Without them, I spend most of my time correcting.

An IM works the same way. Put clear-cut examples and the instructions that go with them in one place the whole team works from, so quality no longer depends on who’s on the deal.

The files themselves are boring, and that is fine. A few good examples of the output you want, a description of how your team structures a storyline, the house conventions for naming and formatting. The value is that there is one copy of it and everyone starts from the same place.

Start with the thing your team produces most often. If that is the IM, write down what a good one looks like before you write anything else. The first version does not have to be complete, it has to be somewhere people can find it.

It also survives people leaving. A skill that lives on someone’s laptop goes with them when they move on. A shared folder stays.

Step two: build once, roll out across the portfolio

Step two is where the EBITDA is. Making the deal cycle easier is one thing, but the actual impact is made in the portcos.

Most of them run the same processes, each in its own slightly different way:

• orders come in by email and get retyped into the ERP

• the monthly report is rebuilt by hand every month

The same goes for tenders, procurement, customer support and back-office.

Automating that per company means paying for the same project again for every portco. A modular component, built once and adjusted per company, can run across the whole portfolio.

You will not get every portco onto the same component, and you do not need to. If four out of eleven can use it with light changes, the build has already paid for itself compared with four separate projects.

The work is in finding the version that is genuinely shared. Order intake looks different in every company until you strip it back to reading a document, matching it to a customer and a product, and writing a record into a system. That core is the part you build once. The adjustments per company sit around it.

It changes how you fund it too. One build with a budget owner at fund level, then a smaller rollout cost per company, instead of a separate business case in every portco that each has to clear on its own.

Where to start

So I challenge you to look at the overlap between your portcos. Which of these could you build once and roll out everywhere?

A rough count is enough to begin with. Take the three processes you hear about most across the portfolio and ask how many companies would use the same component.

Originally posted on LinkedIn