Most companies run corp dev as a transaction function.
A former banker or a finance person reacting to deals crossing their desk from former colleagues. The pattern is consistent. Market trigger. Build pipeline. Close deal. Integrate. Dormancy. Banker shows up with a deck. FOMO sets in. Targets evaluated reactively. Sky-high valuations temper enthusiasm. No deals. Dormancy. The M&A function exists when there is capital, FOMO, or an opportunistic deal in flight, otherwise it's below the radar.
The platforms that compound through M&A run it differently. It's a strategic function with leaders that have an operator mindset. A continuous operating discipline -- proactively sourced pipeline built through a unified platform thesis, underwritten by pre-approved capital availability thresholds, and ready to transact when the right deal is brought to the table. When not transacting, its operators drive strategic initiatives and the continuous pipeline-building work becomes a primary market data source -- the radar that sees unfiltered findings for product management's feedback loop. The difference shows up in high-quality deal volume and velocity, product and market competitiveness, and capital efficiency and ROI.
Reactive corp dev is a cost-driver. Strategic corp dev is a value creator.
Waiting in one place for someone to find you is solid survival advice when you're lost in the wilderness. But not a sound M&A target identification process for a lot of reasons. Reading pitch books is easy, but it manifests group-think and FOMO. It also puts your portco in an auction process that's largely stacked against you because of this adverse selection. Reactive sourcing is non-strategic. The companies that do close trade at premium prices.
Proactive outreach to CEOs and executives at target companies that are not in an auction process uncovers better targets. They transact at lower values, integrate more easily, and can include creative, Buyer-favorable financial structures. The data backs this up. McKinsey's research on programmatic acquirers -- companies that close two or more small-to-medium deals per year against a defined thesis -- finds they generate higher excess TSR than companies that pursue selective or large one-off deals, with a more reliable outperformance pattern. Compounding through pipeline is empirically a different return profile than buying when capital frees up.
Why the thesis has to be operator-built
A pipeline runs against a thesis. The quality of the pipeline is bounded by the quality of the thesis, and most theses are built by the wrong people.
Finance-built theses chase multiples and revenue scale. They optimize for what shows up on the deal model -- accretion, synergy capture, leverage capacity. They are easy to defend in an IC meeting and easy to model in a spreadsheet. They produce deals that close. They do not consistently produce deals that compound.
Operator-built theses chase capabilities, integration tractability, and product fit. They start from a different question: what is the platform we are building, and what does the next acquisition need to do to move the platform forward? The answer to that question lives in the heads of the people running product, engineering, and GTM -- not in the heads of the people running the deal model. A thesis built without those people in the room is a financial thesis dressed up as a strategic one.
The written thesis is the artifact this difference produces. Not a slide. A living document. What is the platform we are building? What capabilities are we missing? What scale acquisitions move the GTM motion? What capability acquisitions move the product surface? Without the document, the pipeline is a list. With it, the pipeline is a thesis. The thesis is what the corp-dev function carries into every conversation, and what every target gets qualified against. A strategic plan and a written platform thesis are not the same artifact.
Why product and engineering have to be at the pipeline table
The thesis being operator-built is necessary but not sufficient. The pipeline reviews themselves have to include the people who run the product and the engineering org. Not as deal approvers. As pattern-matchers.
A finance-led pipeline review scores targets on revenue, growth rate, gross margin, and TAM. A product-and-engineering-embedded pipeline review scores them on whether the capability is actually missing from the current platform, whether the integration is technically tractable, whether the engineering org can absorb the team without breaking, and whether the customer overlap supports the cross-sell thesis. The first set of questions is easier to answer and produces deals that close. The second set is harder to answer and produces deals that compound.
The current example is AI. AI capability is now a primary value-creation lever, which means it is now a primary diligence question -- and it is genuinely hard to assess. Bain's 2025 PE research finds that while nearly all portfolio companies are testing and developing AI use cases, fewer than 20% have actually operationalized any -- meaning most portcos cannot credibly read in a target what they have not built in themselves. The difficulty is asymmetric. Optimistic readings are easy to manufacture. The target has an AI roadmap, a model partnership, a few features in the product, an "AI-native" tagline. Pessimistic readings require seeing through the marketing layer to the architecture and code underneath: whether the data model supports retrieval at the scale AI workloads need, whether the engineering team has actually built with AI tooling or just talked about it, whether the codebase will refactor into something AI can maintain, whether the product roadmap reflects real AI capability or feature flags.
Finance teams cannot do this assessment. Only the people who have built AI capability inside their own platform can read it credibly in a target -- whether they sit in operating roles or advisory ones -- because they have lived through what it actually takes.
The pipeline question and the platform-readiness question are the same question on different timelines.
Can we host AI capability when we acquire it, and can we ship AI capability against what we already own. The platforms that compound through M&A get both questions answered by the same people, in the same room, against the same thesis.
How this works as an operating cadence
The thesis being operator-built and product-and-engineering-embedded only matters if it lives in the corp dev operating cadence. Pipeline reviews are not separate from the operating reviews. They are part of them. The CEO, CTO, CPO, and CFO know the pipeline by name and are part of qualifying it. The Corp Dev leader is often the first to call the CEO or Board member. That call is most effective when it is an operator-to-operator dialogue supported by a well-crafted thesis. More importantly, those conversations quickly surface whether the alignment is real, and targets that drift from the thesis get killed before they consume valuable company cycles.
Two things hold the operator-driven model in place when deal pressure shows up.
The first is integration architecture as a precondition, not an afterthought. The integration framework is built before the LOI, because it helps frame the offer. What changes operationally on Day 1, in the first ninety days, in the first year. What synergies are real and on what timeline. What the operating-model implications are for the existing platform. When integration architecture is a precondition, deals without a clean integration path get killed before capital is committed. When it is an afterthought, the synergy slide gets written by people who will not have to deliver against it.
The second is the Investment Committee. Inside a portco, the IC does for capital allocation what the operating cadence does for execution. It is the place where targets get evaluated against the thesis, the operating model, and the capital plan, separately from the deal-team enthusiasm of the moment. It is the place where a deal in play gets measured against the rest of the pipeline -- including the alternatives that may or may not develop into close-able opportunities.
The IC is not there to slow deals down. It is there to make sure the deals that move forward are the ones that fit and have the highest probability of creating value. Without that governance layer, even disciplined pipelines drift into non-thesis territory, and the operating cadence becomes a process that exists on paper while the actual deal-making reverts to the reactive pattern it was built to replace.
How the IC is structured matters more than who sits on it. Threshold-approval authority defined cleanly. Pre-meeting materials in a standard template, so deals are compared against each other rather than against the most recent emotional pitch. Clear documentation of gating decision points for diligence and deal review purposes are defined. Escalation paths to -- or regular checkpoints with -- the Board are established. The portcos that compound through M&A have all of this in place before they need it.
What this looks like for a portco today
A portco running M&A as a transaction function can rebuild it as an operating discipline in roughly ninety days, with the right operator. The work is concrete. Lock the platform thesis in writing -- what we are building, what we are missing, what fits. Pull product and engineering into the pipeline conversation as standing participants, not as deal-time consultants. Build a continuous target list against the thesis. Work with the CFO and bankers to define the capital allocation envelope. Embed M&A into the operating cadence so pipeline reviews run alongside strategic operating reviews, not separately from them. Stand up the capital allocation governance with an IC charter, threshold-approval framework, and escalation path to sponsor. Build the integration architecture template before the next LOI, not after.
None of this is exotic. Most of it is operating discipline applied to a function that most portcos treat as ad hoc. The platforms that compound through M&A are not the ones with the most aggressive corp-dev teams. They are the ones where the discipline is structural, the thesis is operator-led, the pipeline is product-and-engineering-embedded, and the leadership team treats pipeline as part of operating, not as an event.