Patrick Moran

Capacity is not EBITDA. Business cases that count one as the other overstate their return. A technology project can save 10,000 hours and add zero dollars to earnings. A company implements an IT solution that automates a process, eliminates manual work, or makes a team 30% more productive. The business case looks great: hours saved, tasks automated, faster cycle times, and more work handled by the same team. Every one of those metrics skips one question: Where did the EBITDA go? Capacity and financial value are two different outcomes. Consider three scenarios. 1. Capacity creation A new solution cuts the time a process takes by 40%. The operation improves. If headcount, contractors, and operating expenses stay flat, EBITDA stays flat too. The company created capacity. Earnings did not move. 2. Cost-out realization The same solution lets the company eliminate outsourced spend, cancel a planned hire, cut overtime, or consolidate roles. Now the productivity gain shows up as dollars leaving the P&L. 3. Revenue and scalability enablement The solution lets the business process twice the volume without adding resources. Expenses hold steady today, but the cost structure of growth changes. Incremental revenue flows through at a much higher margin. Scenario three creates a different kind of value. The distinction drives investment decisions. Every technology business case should: - Capacity created: how much more work existing resources can absorb - Cost eliminated or avoided: the dollars that actually leave the P&L - Incremental EBITDA: the earnings improvement attributable to the investment All three carry value. None of them substitutes for the others. A team that books $1M of productivity gains as realized EBITDA, at a 10x multiple, pays $10M for earnings nobody has captured. The best IT investments do more than make people productive. They change the eco The question isn't how many hours the technology saved. The question is what the business did with those hours, and how that decision turns into financial value.

Everybody loves governance. As long as it doesn't apply to them. AI governance is no exception. Ask a room full of executives whether AI needs oversight, and you'll get unanimous agreement. Ask those same executives to submit their own AI initiatives to an architecture review, security assessment, or risk committee, and the enthusiasm fades. Suddenly, governance is bureaucracy. Security is slowing innovation. IT doesn't understand the urgency of the business. And to be fair, sometimes they're right. Traditional governance wasn't designed for technology that can be built in an afternoon, deployed in a week, and rendered obsolete by the next frontier model release. A six-month approval process for an application with a three-month useful life isn't governance. It's organizational dysfunction. But the answer isn't to abandon oversight. It's to rethink how we apply it. A chatbot helping someone draft an email shouldn't face the same scrutiny as an autonomous agent making financial decisions or accessing sensitive customer data. Governance should scale with risk, not organizational hierarchy. Controls should be embedded in the development and deployment process, not bolted on after the fact. And accountability should remain with the people who authorize the technology, not the technology itself. Most importantly, the rules need to apply to everyone. Including the executive who just discovered vibe coding. Especially that executive. Because governance that only applies when it's convenient isn't governance. It's theater.

AI can read a data room faster than any deal team. Last week I read about a library of AI skills for private equity that was making the rounds. Screening, CIM teardown, diligence, all the way through exit. It's useful. Deal teams should use it. However, the AI slop cannons are even better at creating documentation for processes, systems, and practices that don't exist. So how much can you trust the data room? Across the technology diligences I've performed, the most expensive finding was rarely in the data room anyway. It's the system nobody mentions because it "just runs." The contract that reprices on a change of control. The one engineer who holds the keys to production. None of that is in a PDF. You find it in the management session, when an answer comes a beat too slow. Or when you ask to see the thing running instead of the slide about it. AI compresses the reading. That frees up time for the part that was always the job: asking the question nobody prepared for. Teams that use AI to read faster will win deals. Teams that use it to skip the conversation will buy the surprise.

Everyone is a Chief AI Officer now. Some just haven't discovered the rest of the job yet. Last week, Steve showed me a tool he had vibe coded. My first thought was, “This is fantastic!” He had been looking for an enterprise solution for a long time. With the latest AI tools available, he decided to give it a shot himself. The functionality was impressive. It fit his use case well. He understood the problem because he lived with it, and now he had the tools to do something about it. I could see other people wanting to use it. Unfortunately for Steve, my second thought had follow-up questions. What data does it use, and where does that data go? How do we know the results are right? Who can access it? Who supports it when something breaks? Steve had solved a business problem. Now we needed to work through what it would take for the business to depend on his solution. I brought in the right experts to help Steve work through data risk, validation, access, support, and ownership. Together, we mapped out what it would take to harden the application for business use. Steve brought the solution and the business context. We brought the team to help him make it dependable. That conversation is becoming a bigger part of our job. As we push powerful tools closer to the problem, we also push technology decisions into the hands of people who have never needed to make them before. Which data to share. Which output to trust. Which process to automate. When to ask for help. These are pieces of the Chief AI Officer's job, showing up at desks across the company. Preparing an AI-enabled workforce means teaching people how to make those decisions. Alongside the tool training, they need a practical IT 101 course grounded in the work they are actually doing. It is really important to recognize this shift in thinking. Technology leaders are increasingly becoming educators as much as facilitators. How we respond when someone shows us what they built will shape whether they involve us the next time. If we make Steve regret showing us his app, we lose both the opportunity to improve it and the chance to help with the next one. What I like most about these situations is that we can measure the leverage: time saved, rework reduced, and more capacity for the work that needs human judgment. I want more Steves walking through my door. And I want them leaving better equipped to own what they create.

The business team came to the meeting with a vendor. The vendor had promised them a magic wand. We hadn't talked through the problem together. We hadn't reviewed the systems the proposed solution would need to work across. But we already had a demo and expectations. If you work in IT, you've probably been in that meeting. The business team sees something that could make their work easier. You see the systems it needs to connect to, the data it needs, and the workflows someone will have to change. So you ask questions. Can it work with our systems? What does implementation require? Does it solve the problem we actually have? By then, the demo has made the outcome look simple. Your questions make it sound complicated. Now you're explaining work nobody included in the promise, and the people you're trying to help hear reasons they can't have what they want. Most of us in IT want the thing to work, too. But asking the business to come to us first only works if we've earned their trust. When people bring us a problem, do we help them solve it? Or do we give them reasons to look elsewhere? We build that trust by listening, working through options together, and following through. The next time someone needs help, we want their first thought to be, "Let's talk to our team," instead of reaching for another magic wand.

Some days I wonder if my newest AI agent is really a prompt proxy named Carl. Drives a motorcycle. Likes meatball subs. Runs on Mountain Dew. Question in, prompt output relayed, nothing added in between. Carl is fine until he is on your critical path. That is when you need someone who thinks on their feet, challenges assumptions, and knows when the model is wrong. Not someone who simply forwards an answer. Then there is Julie. Julie has hired herself a virtual staff of AI agents. One researches customer trends. Another analyzes sales performance. A third challenges assumptions and looks for gaps in the recommendations. Julie coordinates their work, checks their conclusions against live business data, and makes the decisions that matter. She doesn't just use AI. She manages it. Her output is exceptional. The capability gap between Carl and Julie grows wider every week. Here is the problem: our enterprise dashboards show their productivity as identical. Both have seat licenses. Both query models. Both hit their activity targets. How do you measure AI productivity at the individual level? Count tokens, and people become slop cannons. Count slides, and every problem becomes a thirty-page deck. Count prompts, and Carl looks like your most productive employee. We need harder metrics. Did the work improve a decision? How much rework did it require? How quickly did it produce a validated business outcome? And what did the employee contribute beyond what the model could accomplish on its own? These questions become more important as employees build their own virtual teams. There is another implication worth considering. Scaling Julie's approach may be easier than deploying autonomous agents directly into enterprise operations. Production workflows demand reliable integrations, security controls, auditability, exception handling, and predictable execution. Julie brings something those systems struggle to replicate: business context, judgment, and accountability. She knows when to intervene and when the model has it wrong. That distinction could change more than how we measure productivity. For decades, enterprises have embedded business logic and decision processes into SaaS platforms. What happens when employees, armed with capable agents and governed access to enterprise data, are allowed to solve some of those problems themselves? The boundary between enterprise software and the employee begins to blur. The person closest to the customer may also become the person best equipped to assemble the technology needed to serve them. We spent decades teaching software how our businesses work. We may spend the next decade giving employees the tools to decide how the software should work. Carl and Julie may have the same job title today. I'm not convinced they will have the same job tomorrow. Tokens are cheaper than headcount. And Claude does not need Mountain Dew.

The Evolving Cognitive Workload Andy Grove understood operational leverage better than almost anyone in technology leadership. In High Output Management, he laid out Task-Relevant Maturity: an effective leader doesn't manage raw ability. They manage an individual's specific familiarity with a given task, and adjust how closely they supervise accordingly. That distinction is becoming central to how I think about directing AI systems, especially as frontier models gain deeper reasoning and planning capabilities. Early prompting was about micro-management. We had to dictate every sub-step and force chain-of-thought manually because models lacked the capacity to structure their own thinking. As reasoning loops improve, the nature of the supervision changes. We no longer need to dictate the cognitive steps. But we still have to provide the institutional context, the boundary constraints, and the success criteria. In Grove's terms, extended thinking models move up the maturity curve on analytical reasoning, but they remain at zero on environmental familiarity. Effective prompting is shifting from tactical scripting to strategic management: setting the operational frame, defining the boundaries, and letting the reasoning loop handle the execution. Combine that premise with institutional context, and you've built something no competitor can copy.

Two years from now, companies renting generic intelligence will be undercut by the ones that chose to own it. If your AI roadmap is a ChatGPT wrapper, you do not own intellectual property. You own an expensive monthly subscription. The model is not the asset. Anyone can download one. The asset is your data. Making a model yours no longer takes a research lab. There are four paths, and most companies skip straight to the most expensive one. Retrieve for facts that change. Fine-tune for consistency at volume. Distill when the API bill is the problem. Pre-train only when your vocabulary is a language of its own. The method is the easy part. The hard part is the factory floor: a clean data pipeline, the right infrastructure, and a lean team of three. And none of it counts unless it holds up when a buyer looks closely. If you cannot prove rights to your data, a clean license, and results someone else can reproduce, you have not built an asset. You have built a liability with a GPU attached. Real enterprise value is not built on rented tokens. It is built on owned assets. The full playbook is in the article below. #PrivateEquity #ArtificialIntelligence #ValueCreation #CTO

I used to think deal risk lived solely in the technology. It took me years, and a seat on every side of the table, to learn it usually lives somewhere else. Buyer. Seller. The company being acquired. The advisor writing the diligence report. Most of these lessons, I learned the hard way. As the buyer, integrating acquisitions at one of the largest healthcare companies in the country, I learned the systems were never the hard part. The people protecting them were. As the seller, carving out a $300M division under an 18-month TSA, I learned the separation clock starts the day you sign, not the day you close. As the acquired company's technology leader, twice, I learned the buyer's integration plan is usually written by someone who has never run your systems. As the advisor, across 70+ technology diligences, I learned the most expensive finding is rarely in the data room. It is what management did not think to mention. Every seat sees a different deal. The gap isn't information. It's perspective.

You cannot stack AI on broken architecture. The loop is how you fix the foundation while capturing margin. Deal momentum often hits the data wall. The investment committee expects early margin expansion. The technology team inherits fragmented systems, inconsistent records, and documents nobody has structured. A linear remediation program can consume the first 100 days before the business sees a usable result. A closed-loop approach changes the sequence. Start with a defined data set and a business decision it needs to support. Extract records from legacy sources, validate them against business rules, and route exceptions to the people who can resolve them. Capture those decisions, update the extraction or validation logic, and test the changes before applying them at scale. The work extends beyond data cleanup. Each resolved exception improves the pipeline and leaves behind a reusable architectural capability: governed data, explicit rules, and a process for handling what the system cannot confidently determine. The old playbook treats architecture repair as a prerequisite to value creation. A well-run loop makes the repair part of the value-creation work.

They attend every meeting. They assure everyone they are working on it. Nothing moves. You dig in to diagnose the bottleneck. The resulting conversation leaves you more frustrated than when you started. Underneath the delay is a toxic mix: ego masking incompetence. When leaders lack the competence to execute, they default to posturing. When challenged, they do not produce data. They produce defensiveness, circular explanations, and performative alignment. Inaction left unchecked becomes the culture. High performers exit because they refuse to work in a bureaucracy of polite stagnation. The remaining team simply mirrors the leader: low output, high protectionism. Standard coaching rarely fixes this dynamic. You cannot coach someone out of a defensive posture they rely on for survival. Breaking the cycle requires shifting the operating cadence immediately. Crash the calendar. Eliminate the bi-weekly status sync and replace it with a daily 15-minute operational check. Keep the agenda strictly binary: what shipped in the last 24 hours, what ships in the next 24 hours, and what is blocked. Remove the space for narrative storytelling. Enforce single-threaded ownership. Shared accountability is zero accountability. Define one owner per deliverable with quantitative milestones. When an initiative misses a deadline, the post-mortem focuses on execution gaps, not philosophical debates. Replace the leader before the rot metastasizes. Teams adopt the operational traits, tolerances, and neuroses of their leader. If an executive responds to accountability with distortion rather than execution, coaching is just a delay tactic. Swap the seat. Execution is not complicated, but it is uncomfortable. Incompetence hides behind process. Strip the excuses. Demand forward motion. Clear the seat if you have to.

AI stacks built ninety days ago are already legacy. Rapid leaps in foundational reasoning wipe out complex agent harnesses overnight. The intricate scaffolding teams built last quarter to patch model limitations is now instant technical debt. At the same time, fast token deflation shifts unit economics in months. The real winners are not building closed, brittle systems. They are building flexible solutions on open standards that deliver real utility while maintaining the strict governance needed for enterprise scale. How do you price that into an acquisition? First, open standards versus custom dead weight. Look closely at whether the product is built on open, decoupled architectures that easily adapt to next-generation models, or proprietary wrappers destined for a total rewrite. Second, post-close engineering drag. Determine whether engineering capacity will fund new value creation or get consumed tearing out obsolete middleware. Third, unit economics and governance. Ensure margin models reflect deflating compute costs while factoring in the compliance controls required to run in production. In tech diligence, you are no longer just auditing code quality. You are pricing architectural shelf life. How is your deal team underwriting AI flexibility and durability today?

If you are evaluating enterprise AI software, the platforms you need to run away from are obvious: closed systems trying to manufacture an artificial moat. We are in the middle of a fundamental paradigm shift. In a hyper-velocity AI landscape where models, tooling, and architectures mutate weekly, the legacy enterprise software playbook is obsolete. Vendors believe walled gardens protect proprietary intellectual property. In production enterprise environments, they accomplish the opposite. They build an immediate wall against adoption. For operating partners and executive leadership, black boxes represent an unhedged operational liability. Driving enterprise value and margin expansion through autonomous workflows requires strict governance, capital efficiency, and complete operational control. Locking down a platform and blocking internal tooling does not accelerate time to value. It straps portfolio companies into an agentic tech debt harness that erodes operating leverage and complicates future integration. The AI SaaS platforms and tooling providers that will survive executive vetting deliver five mandatory capabilities: End-to-end telemetry: Complete visibility into compute costs, latency, and token consumption. Blind spots destroy operating margins. Think OpenTelemetry and OpenInference. Bring-your-own guardrails: Custom deterministic enforcement aligned with corporate risk profiles. Never outsource compliance to vendor defaults. Think Open Policy Agent (OPA) and NeMo Guardrails. Deep inference inspection: Full auditability into intermediary reasoning steps and tool execution. Opaque routing introduces unacceptable governance liability. Think Model Context Protocol (MCP) and open schema standards. Enterprise-grade security: Seamless integration with corporate identity and zero-trust perimeter controls. Proprietary silos fail security reviews immediately. Think OIDC, SCIM, and SPIFFE. Production SDKs for CI/CD: Native toolkits for testing, versioning, and deploying agents. Autonomous workflows belong in standard delivery pipelines. Think Promptfoo and headless developer SDKs. Protecting software IP is a valid business objective. Crippling enterprise agility and capital efficiency is not. Open, inspectable architectures will capture long-term enterprise budgets. Vendors that trap customers inside proprietary enclosures will simply find themselves cut from enterprise roadmaps entirely.

Tokenomics. Token famine. The frontier model mafia. Does your AI budget line look like a hockey stick? Don't bet on the model mafia cutting token prices to save your margins. When I was young, I split my allowance: a few quarters at the arcade for the newest machines, and the rest to buy games I could play at home. The games on my Apple IIe lacked arcade-level polish, but they were reliable and ran indefinitely without eating quarters every three minutes. Enterprise tokenomics is trapped in the exact same coin-op model. If a company is flush with cash, blasting unconstrained API calls at flagship frontier models is easy. For operators accountable for unit economics and margin preservation, unmanaged inference spend is pure capital drag. That drag hits the engineering floor long before it shows up in board decks. The token famine inside development teams is real. Developers burn monthly credit allocations in 48 hours, stalling sprint velocity while bargaining with finance for budget increases. Leadership demands aggressive AI adoption, but operates with zero line-of-sight into actual value creation. Capital drains into unoptimized, multi-turn exploratory loops instead of structured, high-yield workloads. Breaking out of the coin-op trap requires a different strategy: First: Match model tier to task complexity. Routing basic tasks to flagship reasoning models is like driving a semi-truck to the grocery store. Reserve expensive frontier models strictly for high-ambiguity logic and complex synthesis. Push deterministic, repetitive agent tasks down to small language models. Second: Deploy predictable, dedicated compute. Transitioning high-frequency internal workloads away from metered frontier APIs eliminates variable cost spikes. Open-weight models running on dedicated compute deliver predictable baseline costs and production-grade capability. Third: Enforce workforce prompt hygiene. The model mafia monetizes raw consumption, not client efficiency. Coach your teams to eliminate wasteful token loops and bloated multi-turn contexts. Structuring precise single-turn prompts, pruning context windows, and caching repeated blocks cuts invoice overhead immediately. The frontier model mafia built incredible machines, but their growth comes straight out of your margin. Stop funding their balance sheet one quarter at a time. Play a smarter game and run your own hardware at home.

Your enterprise software investment will self-destruct in 10 seconds... Enterprise tech used to run on a five-year depreciation schedule. You picked a vendor, survived an eighteen-month rollout, and amortized the CapEx over half a decade. AI agents destroyed that lifecycle. They are ephemeral. They are disposable software. Your operational horizon is no longer five years: it is five weeks. Lighting the fuse on an agent is cheap. Containing the blast is not. Disposable software delivers immediate velocity, but without strict operational constraints, things go sideways fast. Unchecked agents leak proprietary data, compound errors silently, and erase the margins you intended to create. The solution is not avoiding disposable tech. It is investing in a permanent, modular architecture so you can swap disposable building blocks without rebuilding the foundation. PE guys obsess over the exit before the ink is even dry. You should build your AI agents the exact same way. Building for obsolescence requires three non-negotiables: Decouple logic and core infrastructure: Treat every layer as a modular component. Prompts, models, pipelines, and compute must operate as independent, swappable cartridges. Enforce programmatic guardrails: Constrain inputs, validate outputs deterministically, and implement automated kill-switches. Design for rapid disposal: If an agent takes three months to build, it is obsolete before deployment. Engineer single-purpose tools that can be scrapped and replaced in forty-eight hours. Mid-market companies cannot afford multi-million dollar software monoliths that take quarters to implement and years to return capital. Ephemeral software targets discrete bottlenecks, compresses operating costs, and expands margins immediately. When OpenAI, Anthropic, or open source leapfrogs your stack on a random Tuesday, do not panic over sunk costs. Kill the agent, swap the engine, and capture the new spread. Build permanent foundations. Deploy disposable leverage. #ArtificialIntelligence #PrivateEquity #EBITDA #Operations #EnterpriseTech

You date AI tools: you do not marry them. Do not let FOMO drive enterprise capital decisions. Volatile technology cycles demand disciplined risk management. Elite trading desks survive market turbulence through strict controls: Stop-losses tighten. Holding periods compress. Capital stays liquid until volatility clears. Enterprise AI deployment requires identical discipline. Vendors actively engineer ecosystem capture through predictable failure modes: Walled-garden harnesses isolated from enterprise stacks. Proprietary agent workflows incompatible with internal governance engines. Closed architectures that cannot evaluate model drift or performance degradation. These anti-patterns disguise vendor lock-in as enterprise agility. They convert flexible tooling into fixed capital liabilities. Proprietary integrations ossify into technical debt long before the contract expires. Control AI adoption through structured risk mitigation: Avoid multi-year commitments on specialized, inflexible tooling. Enforce architectural modularity across the stack. Preserve technical flexibility while foundational capabilities mature. Date the tool. Own the architecture.

The main purpose of a Senior IT Leader is to turn kWh into $$$'s. Period. I'm not sure why so many miss that. I've been through several technology waves, and that history gives us something to draw from. The PC, the web, mobile. Each one arrived with novelty, then hype, then a split: those that wanted to build cool tech vs. the business asking how to get a multiple on their invested tech dollars. AI is no different. What surprises me is how few technical leaders can make the conversion. They can explain reinforcement learning or get wide-eyed on Agentic Architectures, but they can't cite the bottom-line economics. The kWh is not the point. The dollar is the point. The businesses that won prior platform shifts were not the ones with the best technology. They were the ones that figured out, fastest, how to turn infrastructure into income. That work is still the job. #AI #ITLeadership #EBITDA #ValueCreation #AIStrategy

The doctor gave their IT program 18 months to live. The patient didn't want to hear it. They never do. The Weight Problem Unmanaged consultants are empty calories. The organization gets a spike: a deliverable, a deck, a workshop. Then they leave. The weight stays. Nobody owns the outcome. The scale keeps moving in the wrong direction. The Poor Diet Platforms that never integrate are five drive-throughs calling itself a meal plan. Every system was a good decision in isolation. Together: redundant costs, brittle pipelines, teams managing interfaces instead of delivering value. Healthy architecture has a food pyramid. Core platforms that nourish. Integrations that digest cleanly. A footprint that moves without carrying dead weight. The Smoking Habit Technical debt is smoking. Everyone knows it's killing them. It feels manageable today. It isn't. Every sprint that adds debt without retiring it is another pack. The checkout counter always comes. It arrives as a failed audit, a security incident, or an 18-month warning from someone who finally read the chart . The Sedentary Lifestyle Organizations that never exercise their change muscle lose it. Teams that haven't shipped meaningful change in 18 months don't suddenly sprint when the board demands it. Deploy. Iterate. Retire. Replace. When that stops, everything calcifies. The Intervention Good technology leaders are diagnosticians first. Read the vitals. Deliver the news without drama. The prescription is rarely exciting: rationalize the portfolio, align spend to EBITDA, and build habits that compound. The patient rarely wants to hear it. The ones who do are the ones who survive.

The University of Florida - Warrington College of Business didn't just give me an MBA. It gave me a sharper version of myself. When I enrolled, I came in with years of experience, a clear professional identity, and what I thought was a solid command of my strengths. What I didn't expect was how directly the program would confront what I didn't know. The coursework was rigorous, relevant, and deliberately designed to close gaps. Not the comfortable kind of learning that confirms what you already believe. The kind that exposes blind spots and forces you to rebuild your thinking from the ground up. The faculty and staff made that process work. Their professionalism was consistent. Their guidance was substantive. Their commitment to student success wasn't performative. It showed up in how they structured the curriculum, how they engaged with students, and how they built something rare in a graduate program: a genuine sense of community. The residency weekends were the engine of that. Masterfully curated, they compressed months of relationship-building into focused, high-intensity experiences that made a cohort feel like a team. That environment was amplified by cohort president Chris Taylor, MBA. His leadership demonstrated the Warrington way, ensuring the class navigated the program with a shared focus and an uncompromising standard of excellence. And then there was my immediate team. Adam, David, and Taylor were there from the beginning. The late nights, the weekend case studies, the deadlines that didn't care about anyone's schedule. What made it work wasn't just that everyone was capable. It was that everyone was committed. They flexed around each other's lives without complaint and brought their best to every deliverable. Their dedication to doing excellent work set a standard that pushed all of us. To the UF Warrington program, thank you. To the faculty and staff who poured into this experience, thank you. Martin Iragorri, MBA , thank you for delivering when it counted. To Adam Geesey-Chaouki, MBA , David Padron, MBA , and Taylor Pittman , it was an honor. The standard you held, the flexibility you showed, and the work you produced made this journey one I will always look back on with pride. There's one final thing I must share. It's quietly satisfying being in a foreign country, wearing a University of Florida hat, and hearing a stranger yell "Go Gators!" from across the street. The network isn't a bullet point on a brochure. It's real, it's global, and it shows up when you least expect it. It's a great day to be a Florida Gator! #UFWarrington #GatorNation #GoGators #Leadership #ProfessionalDevelopment #WarringtonMBA

Most PE firms price enterprise data as infrastructure. That is the wrong column on the balance sheet. Proprietary data is inventory - It compounds. It has exclusivity. It has buyers in adjacent markets willing to pay for access. Once it is structured and contractually clean, it is the hardest moat in the portfolio to replicate. Competitors can copy a product. They can poach a team. They can match a price. They cannot retroactively generate ten years of claims data, sensor telemetry, or transaction history they never collected. The mispricing is consistent - Diligence models expense the data platform. Value creation plans modernize it. Exit decks rarely monetize it. The revenue sits locked in the warehouse, classified as a cost center. Firms that price data assets during diligence will win auctions their competitors think they are overpaying for. Firms that build monetization into the hold period will exit at multiples their competitors cannot model. A few ways to approach the exercise: Calculate Replacement Cost: Multiply the organic CAC per record by total volume to establish the absolute valuation floor. Model Syndication Yield: Calculate the NPV of licensing anonymized, structured datasets to external buyers in adjacent markets. Measure EBITDA Impact: Quantify the internal margin expansion driven by the data, then apply your target exit multiple to those savings. Data is not overhead. It is an Asset. It is the moat. #PrivateEquity #TechnicalDueDiligence #ValueCreation