An operational problem does not start in the financials. It starts in how people work, hardens into the technology, and only then reaches the numbers. Financial diligence sees it at the last stage, when the fix is capital. Technical diligence sees it at the middle stage, when the fix is a rebuild. Operational diligence sees it at the first, when the fix is still a process change. Same problem, three prices. That is the argument for running an operational read alongside the financial and technical ones, and it is also why it is the cheapest of them. It matters more than it used to: revenue growth drove 71% of the value created in 2024 exits, so whether the company can deliver the plan now carries most of the return.
The return moved, and diligence did not move with it
For a long stretch, a meaningful share of returns could be produced without the underlying company changing very much. Cheap debt, rising multiples and a benign exit environment did real work. Diligence was built for that world: confirm the numbers are true, confirm the market is real, confirm the contracts hold, and let financial structure do the rest.
That has tightened. Bain's private equity research found revenue growth accounted for 71% of the value created in 2024 exits, up from 64% the year before, and that with leverage and multiple expansion constrained, a typical deal now needs roughly 10-12% average annual EBITDA growth to produce a 2.5x over five years. The implication is not subtle. If most of the return has to come from the company actually growing, then whether the company is capable of growing is not context around the investment case. It is the investment case.
Venture is not private equity, and the mechanics differ. The direction is the same: the further the exit environment moves from easy, the more of the outcome rests on the company doing what it said it would do, on the timeline it said it would do it.
What each diligence stream is actually built to answer
The standard workstreams are good at what they do. The problem is that what they do leaves a specific question unasked, and the question is not a small one.
| Workstream | The question it answers | Where it looks |
|---|---|---|
| Financial | Are the numbers true, and what do they say about what already happened? | The past, in artifacts |
| Technical | Is the code sound, does the architecture hold at scale, is the security real? | The system, as built |
| Commercial | Is the market real, is it big enough, and is this company positioned in it? | Outside the company |
| Legal and tax | What are we bound to, exposed to, and liable for? | Documents |
| Operational | Can this company do the thing it says it will do, at the speed and scale the plan assumes? | The present, in behaviour |
Read down the third column and the gap becomes structural rather than accidental. Four of the five streams examine things that hold still: statements, code, contracts, market data. The fifth examines how a group of people currently behaves under load, which is not a document and cannot be produced on request.
None of these replaces another. A technical review will tell you things an operational read never can, and should be commissioned when the deal turns on the platform. The two work in a specific order, though: an operational read tells you where to point an expensive technical review, and often tells you that you do not need one. The stack is only impressive relative to the work it has to carry, and the work is the cheaper thing to look at first.
The same problem, three prices
The gap matters because of what it costs. An operational problem in a growing company does not appear and stay put. It moves through three stages, and the bill goes up at every one.
Stage one, in the work. A handoff nobody owns. A decision only one person can make, so everything queues behind their calendar. An approval three people route around every week. At this point the fix is an owner, a changed rule, and a conversation. It costs days, and the company can do it itself.
Stage two, in the systems. The workaround gets automated, because that is the rational thing to do with a workaround that has lasted a year. Someone writes the script that bridges the gap. An integration comes to depend on the script. A customer-facing feature comes to depend on the integration. The process problem is now load-bearing, and the fix is engineering time competing with the roadmap. It costs quarters.
Stage three, in the numbers. The milestone slips, the cohort churns, engineering spend rises with nothing attached to it. Now everybody can see it. It is priced into the round, and the fix is capital.
Financial diligence is excellent at stage three and structurally cannot see stage one. A technical review is excellent at stage two and sees stage one only where it left a trace in the code.
That is not a failure of either stream. Both are pointed at artifacts, and stage one does not produce artifacts. It produces habits, and habits are only visible to somebody standing in the room while people work.
Why a data room hides this by design
A data room is a collection of artifacts. Artifacts are produced deliberately, reviewed before they are uploaded, and represent the company at its most composed. That is not deception. It is what a data room is for.
The consequence is specific and worth stating plainly: you can read an architecture diagram and have no idea that the engineering team routinely works around it. You can read a documented approval process and not know that in practice three people bypass it every week because it is too slow, which is the reason the company ships at all. You can read a roadmap and not know that the last four quarters of it were reprioritised mid-quarter by whoever escalated loudest.
A data room tells you what a company has written down. It does not tell you what the company does when the written thing is inconvenient.
The gap between those two is where post-close surprises live. It is also not discoverable by asking, because the people answering are not withholding it - they have usually stopped noticing. Workarounds become invisible to the people performing them within about a quarter.
The four things worth checking, and what each reveals
An operational assessment starts from the business processes the plan depends on and works outward. It reads the systems and the AI claims at the surface, against those processes, and it is deliberately not a code audit, a security audit or a model review. Where the deal needs one of those, the report says so and names what to commission.
How the work actually moves
A workflow analysis of the processes the plan depends on: who decides, where work queues, where handoffs drop things, what is handled by exception, and cycle time between a decision and a delivery.
Reveals: whether the processes that work at 40 people survive the 120 the plan requiresWhether the systems carry the work
Where the team works around the system instead of through it. What gets re-entered by hand, which report takes a person a day, which tool everybody quietly stopped using. Read against the work, not against a technical standard.
Reveals: stage-two cost already sitting inside the growth curveWhether the AI claims sit on a real process
Whether the AI in the deck maps onto a process that exists, with data capable of supporting it and a team that can run it. The common finding is a layer proposed on top of a process nobody has fixed.
Reveals: the difference between an AI product and an AI slideFounder, team and key-person risk
Decision patterns under pressure, how cross-functional work actually gets coordinated, where the company depends on individuals in ways nobody has written down.
Reveals: what breaks if one person leaves in month fourThe escalation shows up in the failure data. CB Insights' analysis of startup post-mortems puts "not the right team" at 23% of failures and running out of cash at 29%, alongside no market need at 42%. Running out of cash is a stage-three description of an event, not a cause. The 23% is a stage-one cause, and a share of the 29% is the same cause arriving later with a bigger number attached.
Pendo's 2024 benchmarks show the same shape inside a product organisation: of every 100 features built and launched, roughly 6.4 drive 80% of usage. The decision to keep shipping without checking what gets used is a stage-one habit. The maintenance cost of the other 93 is stage two, and it is permanent. The engineering spend with no revenue attached is stage three, and by then it is in the P&L the financial stream is reading.
If your capital has to come back, this is not optional
Equity and debt are not the same buyer of this assessment, and the difference is worth being precise about.
An equity investor is underwriting upside. A company that executes slowly is a dilution problem, painful and usually survivable, repriced at the next round. A lender is underwriting downside. Repayment is mandatory whether the milestone lands or not, and the upside is capped, so the risk that actually matters is the company failing to do the thing it said it would do. A missed milestone that an equity investor absorbs in the cap table is a liquidity event for a lender.
The cheapest stream in the pack, twice over
It is the cheapest to buy. One to two weeks, a fixed fee, set against a diligence budget already committed to financial, legal and commercial work, and a fraction of what a full technical review costs when one is warranted.
It is cheaper in a way that matters more. The read does not make the problem smaller. It moves the moment you find out to the stage where the fix is still a process change, and to before the price is agreed rather than after. A finding at stage one is something the company can act on in a fortnight. The same finding at stage three is a conversation about capital, held with a board that expected progress.
Skipping it rarely produces a failed investment. It produces a value-creation plan built on assumptions nobody tested. The 90-day plan gets written from the deck: it assumes the team can absorb change at a certain rate, that the platform carries a certain load, that decisions get made at a certain speed. If any of those is wrong, the first two quarters after the close are spent discovering it. The capital is not lost. The time is, and in a fund with a defined horizon time is the scarcer input.
How it runs
One to two weeks, at deal pace rather than consulting pace. Document review, interviews across levels rather than only with the leadership team, and a walk through the systems that carry the work. The output is written: what was found, what it means for the plan being underwritten, what would need to be true for the plan to hold, and what the first 90 days should cover.
The reason it can run in that window is that it is narrow by design. It is not a transformation study and not a full-scope review. It answers one question, and one question can be answered quickly when the person asking has run the thing being assessed.
The one-line version
Financial diligence tells you whether the past was real. A technical review tells you whether the platform holds. Operational diligence tells you whether the next three years are available to this particular company, with this particular team. It is the only one of the streams that can see a problem while the fix is still a conversation, and it is the cheapest of them to run. When most of the return has to come from growth, that combination is worth more than its price, and it is the one the data room was never built to give you.
Sources
- Bain & Company, Global Private Equity Report. Source of the finding that revenue growth accounted for 71% of value created in 2024 exits (up from 64% in 2023), and that with leverage and multiple expansion constrained a typical deal requires roughly 10-12% average annual EBITDA growth for a 2.5x over five years. Private equity data, used here as directional for venture and growth investing rather than as a like-for-like comparison.
- CB Insights, "The Top Reasons Startups Fail". Source of the post-mortem breakdown: no market need 42%, ran out of cash 29%, not the right team 23%, outcompeted 19%. Based on self-reported and published post-mortems, so subject to survivorship and reporting bias, and read here as indicative of failure categories rather than precise incidence.
- Pendo, 2024 Product Benchmarks. Source of the finding that 6.4 of every 100 launched features drive 80% of click volume, rising to 15.6 for best-in-class products. Vendor research drawn from the company's own analytics install base, read as directional.
- Companion pieces: the operational due diligence engagement, and The Coverage Model on why an important number frequently has no real owner inside a company.