21. Translating tech due diligence findings into the investment thesis
A deal team method to turn diligence from a findings list into price, timing, and funding decisions before you sign.
The deal model promised $28M of EBITDA upside in 18 months. Pricing discipline. Procurement consolidation. “Quick” cross-sell once the commercial teams shared a customer view.
Tech diligence found a different clock.
The target ran Salesforce, but quoting lived in three incompatible workflows by region. Customer master data was duplicated across CRM and ERP with no single customer ID. Pricing tables were maintained in spreadsheets and pushed into the ERP via a nightly batch job that failed twice a week. The commercial thesis wasn’t wrong. The assumed timetable was.
The diligence report captured all of this. The investment thesis did not.
At signing, the IC memo still assumed revenue synergy starting in quarter two. The purchase agreement had no protections tied to the data and quoting constraints. After close, the integration team inherited a backlog of “findings,” but the value plan stayed the same. Six months later, pricing was still manual, cross-sell was still localized, and the team had approved an unplanned $9M CPQ and data remediation program just to make the revenue story executable.
The primary decision is simple: do you treat tech diligence findings as notes for the integration team, or as changes you must underwrite in the investment thesis before you sign? Most value leakage happens in that gap.
Why translation matters: findings don’t move returns, decisions do
Tech diligence produces facts: system constraints, data quality, contract terms, security posture, operating capacity. The investment thesis is a set of bets: “We will capture X value by Y date with Z one-time spend.” They are different artifacts, owned by different people, on different timelines.
A diligence “finding” only matters if it changes one of five deal decisions:
- Price (do we haircut value or pay for it?)
- Structure (do we protect downside with holdbacks, earnouts, TSAs, covenants?)
- Timing (when do gates open for the model’s value levers?)
- One-time cash (what must we fund to make the plan safe?)
- Run-rate (what steady-state costs are we inheriting or adding?)
If you can’t point to which of the five it changes, the finding is either noise or a “good to know.” Treat it accordingly.
The common failure mode: a broken audit trail from diligence to thesis
In good deals, there is a clean audit trail: diligence → thesis → deal terms → Day-1/Day-100 plan. In many deals, that chain breaks right after diligence.
Three patterns show up.
Pattern 1: The report becomes an appendix
The diligence team produces 40–80 findings and a maturity score. The IC memo uses two slides: “No major issues identified” and “Integration is straightforward.” Nothing is intentionally hidden. The translation just never happens.
The mechanism is structural: by the time diligence findings land, the bid narrative is already locked. Any change feels like friction. So the work gets filed for “post-close planning,” where it competes with 200 other Day-1 items.
Decision trigger: If the thesis was written before tech diligence started, assume you have a translation problem. Fix it explicitly.
Pattern 2: Findings are framed as risks, not as thesis deltas
“Data quality risk.” “ERP technical debt.” “Key-person dependency.” These labels are accurate and still unusable. They describe problems, not decisions.
A thesis delta has a shape:
- what value lever is affected
- what date is now at risk
- what you will do about it (and what it costs)
- what protection you need if it goes wrong
Without that shape, finance can’t change the model, legal can’t change the contract, and the integration lead can’t prioritize.
Pattern 3: Everyone agrees, but no one owns the economics
Tech says, “Integration will take longer.” Finance says, “We already told the IC quarter-two synergies.” Corp dev says, “We can’t reopen price.” The team nods and moves on.
Then reality arrives: delays, unplanned spend, and a year-one value shortfall that looks like “execution failure” but is actually “underwriting failure.”
A practical method: build a tech-to-thesis bridge in one working session
Best teams don’t try to translate every finding. They translate the few that move returns.
Run a 90-minute working session with four people: the deal lead, the finance lead, the tech diligence lead, and the integration/separation lead. The goal is not alignment. The goal is a bridge from facts to economics.
Use a single template for each thesis-moving finding:
- Fact (what is true): the concrete constraint or term.
- Mechanism (why it matters): how it blocks a value lever or adds cost.
- Thesis impact (what changes): price, structure, timing, one-time cash, run-rate.
- Action (what we will do): the minimum workplan to make the thesis executable.
- Protection (how we de-risk): the specific deal term, condition, or governance commitment.
If a finding can’t fill all five lines, it isn’t ready to influence the thesis.
Three examples of “finding → thesis delta” (with the math attached)
Example 1: Revenue synergy depends on customer and pricing data
- Fact: Customer IDs are not consistent across CRM and ERP; quoting runs on three region-specific processes; discounts are stored in local spreadsheets.
- Mechanism: You can’t roll out unified pricing or cross-sell offers without a single customer view and a controlled quoting process.
- Thesis impact: Delay year-one revenue synergy by 2 quarters or fund a minimum viable bridge (CPQ + customer master + data cleanup).
- Action: Stand up a “commercial data spine” (customer ID, product ID, price list governance) and standardize quoting for the top 30% of revenue first.
- Protection: Tie the synergy ramp to a gate (customer master + standardized quoting live for top accounts by Day 120). If the gate slips, shift the model and re-sequence programs; don’t keep the original ramp on paper.
Example 2: IT cost synergy is gross savings without offsets
- Fact: The plan assumes retiring 12 tools and cutting $6M of run-rate. Diligence shows the target relies on contractors to keep integrations running, and the buyer’s security stack will require new licenses at close.
- Mechanism: “Savings” will be offset by backfills (contractors, new tools, platform costs) unless you model them and commit to the retirement path.
- Thesis impact: Reduce net run-rate synergy from $6M to $2–$3M unless you fund migration and enforce tool retirement.
- Action: Build a simple bridge: baseline run-rate → retirement savings → required adds/offsets → net synergy, with owners for each line.
- Protection: Put tool retirement into governance, not aspiration: a Day-100 decision point with CFO sign-off on which tools are getting shut down and when.
Example 3: Deal terms create hidden tech obligations
- Fact: A core vendor contract auto-renews 120 days before close and has a change-of-control clause that increases fees by 25%. The ERP vendor requires a license true-up at close.
- Mechanism: Unplanned run-rate increases hit EBITDA immediately, and renewal timing can lock you into a multi-year term before you can rationalize.
- Thesis impact: Add $1–$3M of run-rate cost (depending on scope) or treat renegotiation as a closing condition.
- Action: Start commercial renegotiation pre-close; decide whether to assume the cost, restructure it, or carve it out.
- Protection: Contractualize it: closing condition, purchase price adjustment, or a seller-funded remediation escrow for known cost increases.
The point is not that every deal needs CPQ, a bridge model, or a renegotiation clause. The point is that each finding turns into a decision with numbers attached.
The deliverable the IC actually needs: a one-page thesis delta memo
Don’t attach the diligence report to the IC deck and hope readers infer the implications. Write a one-page “thesis delta memo” that sits between diligence and the investment thesis. It forces crisp decisions.
Include four sections:
- What we now believe (3–5 statements). Example: “Revenue synergy is gated by customer and pricing data; first-year ramp requires a bridge.”
- What changes in the economics. Timing shifts, one-time cash, and run-rate adds/offsets (with a short bridge, not a range).
- What we will do pre-close and in the first 100 days. The minimum plan to make the thesis executable, with an owner.
- What protections we are taking. The deal terms and governance commitments that cover downside if gates slip.
If the memo doesn’t change anything, that is an answer: either the findings are not thesis-moving, or the deal team is choosing to take risk without pricing it. Both are valid. Neither should be accidental.
Make “value gates” explicit and tie them to deal mechanics
Translation fails when the deal team speaks in maturity and the thesis speaks in dates. The bridge is a small set of gates.
A value gate is a technology condition that must be true by a date for a value lever to start.
Examples:
- “Unified customer ID and standardized quoting live for top 30% of revenue by Day 120.”
- “Identity and access model decided, and network connectivity approach signed off by security by Day 45.”
- “ERP separation scope locked, and TSA term covers month-end close through the first two quarters.”
Then tie each gate to the mechanism that can enforce it:
- Model: The synergy ramp starts when the gate is met, not when the calendar says so.
- Workplan: The gate has an owner, a budget, and a weekly checkpoint.
- Deal terms: If the gate depends on the seller (access, data, systems, contracts), protect it with a covenant, TSA term, or condition.
Decision trigger: If a value lever starts in the model before its gate can be achieved, you have an underwriting error. Fix the model or fund the bridge.
What to do in the next 10 days (and who should own it)
Translation is not a “best practice.” It is a short, time-boxed work product with owners.
In the 10 days after tech diligence findings are clear (often before signing), do five things:
- Pick the 3–5 value levers that drive the purchase price. Deal lead owns this. Not “synergies.” The actual programs and dates the model assumes.
- Define the technology gate for each lever. Tech diligence lead owns the gates; integration/separation lead validates feasibility.
- Write the economic bridge. Finance owns the math: timing shifts, one-time cash, run-rate adds/offsets. Keep it simple and defensible.
- Decide the protections. Legal owns the mechanism, but the deal lead owns the choice: escrow, covenant, TSA term, purchase price adjustment, earnout metric, or none.
- Commit to the first 100 days. Integration/separation lead owns the minimum plan and the weekly cadence; the deal lead owns escalation when gates slip.
If you do this well, the diligence report becomes what it should be: evidence. The thesis becomes what it should be: a set of bets you can execute. And the first 100 days becomes what it should be: the fastest path to opening the gates that make the deal work.