Tech diligence findings belong in the investment thesis before signing, not in a handoff note to the integration team. 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:

  1. Price (do we haircut value or pay for it?)
  2. Structure (do we protect downside with holdbacks, earnouts, TSAs, covenants?)
  3. Timing (when do gates open for the model’s value levers?)
  4. One-time cash (what must we fund to make the plan safe?)
  5. 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

When diligence produces a long findings list and a maturity score, the IC memo can still collapse to “No major issues identified” and “Integration is straightforward.” Nothing is intentionally hidden; the translation simply 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

When technology indicates that integration will take longer, finance has already modeled early synergies, and corp dev resists reopening price, ownership of the economics is unclear. The result can be 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

Do not translate every finding. 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:

  1. Fact (what is true): the concrete constraint or term.
  2. Mechanism (why it matters): how it blocks a value lever or adds cost.
  3. Thesis impact (what changes): price, structure, timing, one-time cash, run-rate.
  4. Action (what we will do): the minimum workplan to make the thesis executable.
  5. 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 conditional examples of “finding → thesis delta”

Example 1: If revenue synergy depends on customer and pricing data

  • Fact: Customer IDs are not consistent across CRM and ERP; quoting varies by region; 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 the modeled revenue synergy until the data and quoting gate is live, 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 priority revenue segment first.
  • Protection: Tie the synergy ramp to a gate for customer master and standardized quoting by an agreed date. If the gate slips, shift the model and re-sequence programs; don’t keep the original ramp on paper.

Example 2: If IT cost synergy is gross savings without offsets

  • Fact: The plan assumes tool retirement and run-rate savings, while diligence shows reliance on contractors to keep integrations running and new licenses required by the buyer’s security stack.
  • 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 by the documented offsets 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 shut down and when.

Example 3: If deal terms create hidden tech obligations

  • Fact: A core vendor contract auto-renews before close and has a change-of-control clause that increases fees. 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 the documented run-rate increase 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:

  1. What we now believe (3–5 statements). Example: “Revenue synergy is gated by customer and pricing data; first-year ramp requires a bridge.”
  2. What changes in the economics. Timing shifts, one-time cash, and run-rate adds/offsets (with a short bridge, not a range).
  3. What we will do pre-close and in the first 100 days. The minimum plan to make the thesis executable, with an owner.
  4. 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 the priority revenue segment by the agreed gate date.”
  • “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.

Convert findings into five deal decisions

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:

  1. 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.
  2. Define the technology gate for each lever. Tech diligence lead owns the gates; integration/separation lead validates feasibility.
  3. Write the economic bridge. Finance owns the math: timing shifts, one-time cash, run-rate adds/offsets. Keep it simple and defensible.
  4. 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.
  5. 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.