AI products in private equity: back the builders.

Ask to see the product in use. Then ask what the team itself built, when the last meaningful change reached users and what it learned from their behaviour. A credible lead can show a release history, explain a failure and identify the next constraint. The answer should survive a conversation with an engineer and a user, without requiring a newly prepared presentation.

Persistent ideation, repeated demonstrations with no route into operation and a roadmap that advances mainly through new job titles are warning signs. So is a leader who cannot explain a technical decision without calling an external supplier. A difficult integration can justify delay; an inability to diagnose it or offer a smaller release is a different problem. Ask for the specific dependency, its owner and the decision required.

Make the first commitment small enough to test. Identify one user, one recurring task, a baseline and acceptance conditions. A working front end can quickly expose a poor workflow or weak demand. Label it as a prototype. A proof of value needs evidence that the intended task improves; a pilot tests that evidence with real users; production adds reliable operation and support. Do not report all four as delivered business value.

We organise AI opportunity discovery across three value pools: the core commercial engine, productivity in the support organisation, and AI products that customers pay for. This gives a fund a practical way to uncover use cases against each company’s investment thesis. The first improves how the existing business acquires, serves and retains customers. The second improves the work around that value chain. The third creates a monetisable offer.

Treat portfolio management and platform development as a shared investment supporting all three pools. Keep their costs visible and tie expansion to releases they enable. Each use case needs one primary value pool and one accountable business owner. An AI sales assistant may improve conversion in the existing commercial engine; an AI research subscription belongs in the product revenue pool. Where benefits overlap, count the same revenue or saving once. Rank opportunities by credible value, time to a useful release and the effort required to operate them, then use delivery evidence to decide the next investment.

For AI delivery leadership, I would favour someone whose engineering judgement rests on software fundamentals, with experience that goes beyond assembling the latest AI tools. They should understand application architecture, data boundaries, cloud services, testing and deployment. They must be willing to read code, challenge a design and help debug a release. Familiarity with low-code tools can be useful; it does not establish that depth of judgement.

Test the candidate against work they have personally delivered. Ask them to walk through an application, identify what they built, explain an architectural trade-off and describe a production incident they helped resolve. Ask how they review AI-generated code and decide a change is ready. A title, certification or list of suppliers managed is weak evidence of the ability to lead builders.

A leader who needs an external development partner for every change leaves the company dependent on someone else’s priorities and judgement. Contractors can add valuable capacity, and specialist partners can strengthen quality assurance. Keep technical ownership inside the delivery team: access to code, the ability to evaluate its quality, control of the release process and a credible handover. Buying expertise is different from surrendering the ability to deliver.

Product management still matters, especially for customer-facing products with uncertain demand or difficult user journeys. Where a technical team already owns architecture, a strong PM should sharpen discovery, scope, acceptance criteria and learning from users. Do not require every PM to be an architect. Do require the person accountable for technical delivery to have that judgement. Add a PM when product decisions are the constraint; add builders when implementation is the constraint.

Start with a technically credible delivery lead, a named business owner and enough hands-on capacity to complete the first useful release. Expand when demand and delivery evidence justify it. A separate VP layer, programme office and portfolio coordination team should each have to explain the constraint they remove. Senior titles do not create velocity; shorter paths between a decision, a build and a user can.

Choose the structure around company capability and concurrent demand. A central team can supply scarce builders; a shared foundation can support local teams; established businesses may need their own embedded capability. These are operating choices, not steps towards an ever-larger central function. Reuse deployment tooling, evaluations and specialist knowledge where they save work. Keep company data, permissions and commercial accountability properly separated.

Protect time to finish. A flexible contractor or PM bench is useful when assignments have a bounded release and continuity through launch. Constantly moving people between portfolio requests creates unfinished work and repeated context recovery. Reserve capacity for supporting what is already live, then add builders as proven demand grows. A team that launches products faster than it can operate them is borrowing capacity from its future.

A fund can hire the right people and still neutralise them with infrastructure queues. If developers wait repeatedly for environments, approved model access, data permissions or deployment rights, the constraint sits outside the build team. The managing director and company leadership should make the CIO accountable for a usable route to production, with named owners and turnaround expectations for dependencies.

Give the delivery lead explicit authority within agreed boundaries: a budget, access to suitable cloud services, test data, environments and a way to release. Delegated authority should use scoped permissions, separate test and production environments, controlled credentials and observable changes. It should not mean an exception request for every ordinary development action. Escalate unresolved dependencies to someone who can decide them.

Bring legal, security and relevant compliance specialists into the first product brief. While builders test the user journey, those colleagues can resolve data use, access, contractual constraints and the conditions for wider release. Make required controls and decisions explicit early. A genuine issue may stop a release; vague concern should become a defined question with an owner, rather than an indefinite hold on the entire initiative.

Fund the essentials: AI development tools, repeatable deployments, evaluations, monitoring, rollback and enough cloud capacity to test properly. Measure their cost against the cost of idle builders and delayed evidence. Budget discipline should expose waste, including unnecessary platform construction; it should also make sensible spending easy. A shared platform earns expansion when real products need it, rather than when a central roadmap anticipates every possible use case.

Expect the team to use AI-assisted development where it helps them build, test and investigate faster. Keep human ownership of design and code review. Aim for a narrow, working slice of the complete experience, then a bounded pilot with real users. Shorter scope creates earlier evidence. Removing the checks that make that evidence trustworthy creates rework.

Evaluate representative tasks, difficult cases and unacceptable actions. Use automated tests and human review where judgement matters; calibrate any model-based grading against people. Verify completed outcomes, not just convincing responses. Repeat trials to expose variability and rerun regression checks when models, prompts, tools or data change. Production monitoring then shows what the test set missed.

Invest in a dependable QA base. A capable QA partner can review permissions, integrations, failure recovery and critical user journeys while builders continue delivery. Agree acceptance conditions and responsibility for fixing defects. The technical lead still owns release quality. A small custom application is not inherently unreliable, but releasing one without testing, support and recovery creates avoidable operating risk.

Use a DevOps model in practice: the people building the product stay close to deployment, monitoring and incidents. Name an operating owner, reserve debugging capacity and establish a way to disable or roll back a failing feature. As usage grows, scale support deliberately. A launch creates an obligation to users; it does not end the assignment.

Ask for a portfolio view you can inspect between meetings. One row per distinct solution should show the company, user problem, owner, lifecycle stage, time in that stage, last release, adoption, quality, spend and next decision. Link to the working product and its evidence. Include a last-updated timestamp and show missing data explicitly. A dashboard built from optimistic self-reporting is simply a presentation with a different interface.

The weekly review should answer what shipped, what moved, what is stuck and what needs a decision. Keep the essential product brief, architecture decisions, operating instructions and evidence of required controls. Avoid making builders recreate this information in a large recurring slide deck. Reporting should make the work inspectable with as little duplicate effort as possible.

Do not turn solution count into a competition. A useful release can create more value than ten trivial applications. Compare delivery within a stable scope and show both completed and unfinished work. A growing ideation queue or rising spend without releases demands intervention, but a controlled product handling consequential decisions may reasonably need more evidence than a simple internal tool.

Use the dashboard to allocate capital and remove constraints. Add a builder when a validated backlog exceeds capacity; improve the user experience when adoption is weak; address reliability before widening use. Stop work when the hypothesis fails. Neither tokens consumed, impressive demos nor a busy roadmap substitutes for these decisions.

I use ‘micro-apps’ to describe small, focused applications that remove friction from recurring work: preparing a customer brief, reconciling an exception or checking a handover. Some use AI at runtime; others are conventional applications built faster with AI assistance. Their importance lies in the task they improve. Repeated useful releases can expand what a portfolio company is able to do without a large transformation programme upfront.

The risk is a new version of application sprawl. Maintain an inventory from the first release: purpose, users, owner, data access, dependencies, running cost and support arrangements. Check whether a new request should extend an existing product. Retire duplicates and unused tools. Share components where they simplify maintenance. A small application still needs someone to update it when its model, API or source system changes.

Apply the same discipline to existing AI products. Inspect failed tasks, abandonment and support demand; distinguish a capability problem from an onboarding or workflow problem. Test one improvement hypothesis against the current baseline, release progressively and retain regression checks. Improving a product people already use may earn a better return than adding another application to the portfolio count.

I would use 12–18 months as a planning checkpoint for a broader operating-model and capacity review, once a meaningful set of releases has sustained adoption. It is a review point, not a forecast of savings. The evidence may support action earlier, or show that more work is needed. Within a PE investment cycle, this creates a practical route from delivery to resource decisions, provided the remaining holding period supports the investment case.

Size the future organisation against measured workload and service requirements. Include exceptions, rework, support and expected growth; verify whether saved time can actually be combined and redeployed. Then decide what capacity supports growth, what roles change and whether spending can fall. Do not book an FTE reduction because a prototype saves minutes in a demonstration. Released capacity becomes a cash saving only when the cost base changes.

Start the next assignment with a narrow product mandate, an accountable technical lead, a business owner and protected delivery capacity. Agree the spending envelope, first evidence review and route to users. Provide enough tooling, infrastructure and QA to make that commitment credible. Increase capacity as the team demonstrates delivery, adoption and an economically sound backlog. Keep support costs in the funding decision.

For the managing director, the strongest signal is a team that can show its work, explain its failures and release the next improvement. The warning is persistent dependence on hierarchy, suppliers and presentations to conceal an absence of delivery. Back the people who can build and judge quality, give them room to act, and hold them accountable for what remains in operation.

At Scipio & Partners, we have developed playbooks for PE houses facing these scenarios and have helped establish AI delivery setups across portfolio companies globally. Our work connects leadership selection, team structure, delivery authority, infrastructure, QA and portfolio reporting. We help firms avoid costly setup mistakes and turn early releases into an operating capability. Contact us to discuss the team, delivery mandate and investment sequence for your portfolio.