Product and technology diligence produces many accurate observations. The IC cannot underwrite observations; it underwrites economics and execution. “The release process is manual” only matters if it increases incident risk, slows roadmap delivery, or raises cost-to-serve, and if you can explain what it will take to fix. This chapter turns diagnostic work into a funded, time-bound plan: initiatives with owners, sized in people and calendar time, linked to deal risk and value creation.
14.1 Turning Issues Into Initiatives: Remediation Backlog Construction
The most common diligence output that fails in practice is a long list of “problems” that no one can staff, sequence, or close. The fix is to translate issues into a remediation backlog: a short portfolio of initiatives that are outcome-oriented, scoped, and owned.
Begin with an issue statement that is underwritable. Every issue should answer four questions. What: what is wrong, stated concretely. Evidence: how you know (artifact, metric, interview triangulation). So what: the impact pathway to revenue, margin, or timing. Now what: the likely class of fix. If you cannot answer these, label the item as uncertainty rather than fact.
Use a consistent language pattern so issues are comparable across deals. Observation: what you saw. Mechanism: why it happens in the system. Impact: where it shows up (incidents, churn, discounts, support load, delivery slips). Scope: which products, customers, or teams are affected. Confidence: high/medium/low based on evidence depth.
Then convert each issue into an initiative. An initiative is a discrete program with a measurable outcome, a bounded scope, and a single accountable owner. “Improve reliability” is not an initiative; “reduce sev-1 incidents by addressing the top three recurring failure classes and implementing release safety gates” is.
Most initiatives fall into a small set of archetypes. Risk reduction: reduce the likelihood or blast radius of incidents (security, privacy, reliability). Delivery enablement: increase throughput and predictability (tests, CI/CD, platform standards, observability). Scalability and cost control: increase headroom and stabilize unit costs (tenancy controls, performance work, FinOps discipline). Revenue enablement: remove barriers to selling, onboarding, and expanding (SSO/SCIM, audit logs, integration productization, admin tooling).
Archetypes matter because they imply different success metrics. Risk reduction is measured through incident frequency and recurrence, control evidence, and time-to-recover. Delivery enablement is measured through cycle time, change failure rate, and on-time delivery. Scalability and cost control is measured through p95/p99 performance, tenant isolation outcomes, and cost per unit. Revenue enablement is measured through sales-cycle friction, activation rate, win/loss reasons, and expansion attached.
Use an initiative “card” to force clarity. Keep it short, but do not skip fields; missing fields become surprises.
- Initiative: outcome-oriented name.
- Goal: measurable target and segment.
- Scope: included and excluded items.
- Approach: root-cause change.
- Dependencies: prerequisites and constraints.
- Owner: accountable leader and contributors.
- Effort: team-month range and confidence.
- Proof: evidence that verifies completion.
Two practical techniques keep backlogs from becoming noise. First, consolidate issues that share a root cause. It is common to find ten “symptoms” that are really one system problem, such as weak tenant isolation or an undisciplined release process. Treat the system problem as the initiative, and list the symptoms as evidence and as acceptance criteria. Second, separate “fix” work from “proof” work. Many programs fail because teams ship changes but never verify that outcomes moved, so the same issues reappear in a different form.
Add explicit acceptance criteria so completion is verifiable. Definition of done: deployed, monitored, documented, and actually used. Treat “installed” as incomplete until gates, alerts, and behaviors change in practice.
Set granularity intentionally. A useful heuristic is “one accountable owner, one primary outcome, one quarter-scale time box.” Smaller initiatives (two to six weeks) are fine when they remove a specific blocker. Larger initiatives (multiple quarters) should be broken into milestones that each produce a measurable step-change; otherwise they become perennial “platform work” that competes poorly with revenue pressure.
Prioritization is where you create deal value. Sort initiatives into four horizons. Day 1 must-do: required for safe operations or to meet contractual commitments. First 100 days: high ROI and high feasibility; builds momentum and frees capacity. Year 1: thesis-critical programs that require sequencing, hiring, or evidence windows. Defer: improvements that do not change underwriting.
Use two lenses simultaneously. Severity: downside if nothing changes. Leverage: how many benefits the initiative unlocks (for example, better observability can reduce incident time, support burden, and delivery friction). This prevents the common mistake of spending scarce capacity on “important but narrow” work while postponing “high-leverage” fixes.
As you prioritize, make the “owner problem” explicit. Some issues are primarily product decisions (packaging, onboarding flow, admin UX), others are engineering execution (tests, pipelines), and others are shared (enterprise trust, integrations). When ownership is ambiguous, initiatives stall. In diligence output, name the single accountable leader even if multiple teams contribute, and state what authority that leader needs to enforce standards and tradeoffs.
Also capture the smallest first milestone for each major initiative. Large programs should deliver value in increments: a first cohort migrated, a first failure class eliminated, a first set of enterprise controls shipped. Milestones create momentum and make it easier to manage investor expectations. They also create “stop points” where the owner can reassess whether deeper work is still worth funding based on evidence.
Be explicit about uncertainty. Some topics cannot be fully validated pre-close: true cloud unit costs, hidden codebase risks, or the depth of separation dependencies in a carve-out. Treat uncertainty as an initiative too. A short confirmatory sprint with defined outputs—such as cost attribution by workload, a security evidence gap assessment, or a repo-based maintainability scan—reduces risk quickly and prevents overconfident pricing.
Close the loop: every high-severity risk should map to at least one initiative with an owner and timing; every value creation claim should map to initiatives that create the capability. If you cannot draw that linkage, your plan is not yet operational.
14.2 Sizing Cost and Timeline: Staffing, Vendors, and Sequencing Assumptions
Sizing is where diligence becomes financially real. A well-defined initiative without cost and timing is still a narrative. The challenge is that sizing is done with imperfect information. The solution is to use repeatable estimation methods, make assumptions explicit, and present ranges with a confidence label.
Distinguish effort from elapsed time. State the staffing pattern you assume, include hiring and onboarding ramp if needed, and add calendar buffer for enablement and cross-team coordination when work spans product, engineering, and customer teams.
Size first in capacity units, then convert to dollars. People time is usually the main cost driver, and it is best expressed as team-months or FTE-months. Convert to dollars using a fully loaded cost assumption that is consistent across initiatives. This also forces feasibility realism: five engineers for three months is a different operational commitment than fifteen engineers for one month, even if the dollars look similar.
Use three methods, and choose based on evidence depth. Analog sizing: compare to similar programs you have seen and adjust for scale and maturity. Decomposition sizing: break the initiative into 3–6 outcome workstreams and estimate each. Constraint sizing: start with the delivery capacity available and infer the calendar timeline after accounting for ongoing commitments and operational load. In diligence, decomposition plus constraint usually yields the most credible result.
When you decompose, keep workstreams few and dependency-aware. For example, “enterprise trust uplift” may include identity features, audit logging, admin tooling, and evidence packaging. “Reliability program” may include observability baseline, top failure-class remediation, and release safety. Each workstream gets a team size range, an owner, and a prerequisite note.
Then apply sequencing discipline. Many initiatives fail because dependencies are assumed away. Make prerequisites explicit: instrumentation before performance optimization; identity model alignment before SSO/SCIM scale-up; evidence collection windows before SOC 2 Type II claims; data lineage before customer-facing analytics expansion. Put these on the initiative card so the operating plan and the model do not assume parallel work that cannot run in parallel.
Some work is calendar-gated even when execution is fast. Calendar-gated work: audits and attestations often require an operating period (for example, SOC 2 Type II) and cannot be “crashed” with more engineers. Treat these as stage gates: implement controls early, start evidence capture immediately, and consider interim milestones (such as a gap assessment or Type I report) to reduce sales friction while the observation window runs. The same logic applies to privacy and residency commitments that require updated documentation, training, and customer-facing evidence, not just code. When the thesis depends on these milestones, do not model full enterprise acceleration until the gating milestone is realistically achievable.
Account for the “work tax.” Most engineering organizations do not have 100% capacity for initiatives because unplanned work, customer commitments, and maintenance consume time. Ask for a rough split and treat it as a model input. If the target cannot estimate, use a conservative availability factor and label it. If you size initiatives assuming full availability, your dates will be wrong.
Specify role mix, not just headcount. The scarcest resources are usually senior engineers, platform owners, security leadership, and technical program management for cross-team work. A program can be “funded” and still fail if it lacks an accountable owner with authority to enforce standards and make tradeoffs. In diligence outputs, name the roles required and whether they exist today.
Be careful with “buy versus build” assumptions. Buying a tool shifts work into integration and ownership. If you assume a vendor closes a gap, specify the integration work, the internal owner, and the fallback if the vendor becomes the bottleneck.
Include an explicit capacity reserve for incidents and urgent commitments. A plan with no slack will break on the first outage. Represent this as an availability factor or a small reserve team, and make it visible to the IC.
Vendors can accelerate or de-risk when expertise is specialized or the work is temporary. Use them for SOC readiness, pen testing, identity migration, and separation planning. Avoid them for core differentiation unless ownership can transfer. Size both One-time: setup/remediation and Run-rate: recurring spend, and reflect run-rate in margin assumptions.
Express every estimate as a range with explicit assumptions. A practical format is: “X–Y team-months over A–B calendar months, assuming Z.” Include the three assumptions that typically drive the range: team availability, dependency resolution speed, and scope stability. Also include a short “what would change this” note so the deal team knows what to verify post-close.
Finally, make portfolio-level conflicts visible. You do not need a detailed schedule; you need a sequencing narrative that respects scarce roles. Identify which initiatives can run in parallel, which must be sequential, and which compete for the same people. If multiple initiatives require the same scarce roles at the same time, either the plan must change or hiring must be assumed in the model.
A fast sizing workflow that works under deal pressure is:
- Step 1: define the minimum scope that achieves the outcome.
- Step 2: decompose into a handful of workstreams with owners.
- Step 3: estimate team-month ranges per workstream.
- Step 4: apply an availability factor and critical path dependencies.
- Step 5: state timeline and cost ranges with confidence and assumptions.
Consistency matters more than precision. A repeatable sizing method builds trust, and trust is what allows your numbers to influence underwriting decisions.
14.3 Risk Pricing: Downside Cases, Holdbacks, and Covenants
After sizing remediation, decide how much residual risk remains and how to reflect it in the deal and the model. Risk pricing is not a negotiation tactic; it is a way to align economics and accountability with probability-weighted downside.
Most P&TD risks map to four categories. Revenue risk: trust gaps, roadmap slips, or reliability issues that reduce bookings or increase churn. Cost risk: unplanned remediation, cloud spend growth, or support scaling that compresses margin. Timing risk: delayed value creation due to dependencies or evidence windows. Event risk: low-probability, high-impact events like breaches, major outages, or failed carve-out separation.
Convert each material risk into a downside case with mechanics, not labels. For example, a security readiness downside case might assume longer enterprise sales cycles and lower win rates until specific controls and evidence are in place. A reliability downside case might assume elevated churn in the top cohort and higher support load until failure-class remediation lands. A carve-out downside case might assume longer TSA duration and stranded costs. These cases create a basis for pricing, structuring, and operating priorities.
Define triggers that move the plan from base case to downside case. Triggers: missed milestones, repeated sev-1 incidents, failure to obtain required attestations, or TSA slippage. Clear triggers improve post-close governance and prevent debates about whether execution is truly on track.
Then choose how to reflect the risk. Modeling: adjust growth timing, margins, and one-time remediation cost in the base case. Structure: escrows, holdbacks, earnouts, or price adjustments tied to defined risks. Covenants: specific, measurable commitments pre-close or post-close (for example, completing a SOC 2 plan, implementing privileged access controls, or meeting TSA exit milestones).
Use the lightest-weight lever that provides adequate protection. If the risk can be fully reflected in the operating plan and the base case still works, adjusting the model may be sufficient. If the risk depends on seller-controlled actions during transition, structure and TSA terms often matter more than modeling. If the risk is a “must fix” to operate safely, a covenant with a clear deadline and verification method can protect focus.
Confirmatory diligence is a practical tool when access limits create meaningful uncertainty. For example, if full repo access was not granted, a post-signing codebase review with a defined scope and remedy can reduce the chance of a surprise remediation program. Likewise, if cloud cost attribution is unclear, a post-close cost baseline assessment can be required and linked to budget approval gates.
Use holdbacks when the risk is measurable and the seller still influences outcomes (especially in carve-outs and transition-heavy deals). Tie holdbacks to verifiable milestones, not to vague posture improvements. “Exit identity TSA and migrate production monitoring by date” is actionable. “Improve security” is not. Covenants work when they are enforceable and limited to a few critical items; too many covenants dilute focus and are hard to monitor.
Avoid double-counting risk. Do not both haircut the model and demand a large holdback for the same downside unless you can explain why both are needed. Be explicit about what the base case assumes: whether it includes mitigation success, partial success, or no mitigation. Clarity here protects diligence credibility.
Present risk pricing recommendations in a consistent format. Risk: mechanism and evidence. Magnitude: revenue/cost/timing range. Mitigation: initiative plan and timeline. Residual: what remains uncertain or uncontrollable. Deal lever: the term that best aligns incentives and protects the buyer.
Done well, risk pricing creates alignment rather than conflict. It ensures the buyer funds what must be funded, the seller supports what must be supported, and the IC sees a plan that matches reality.
14.4 Value Creation Sizing: Revenue Acceleration and Cost-to-serve Reduction
Upside sizing is where diligence teams are most tempted to overpromise. The discipline is to size only what you can tie to a mechanism, a metric, and a feasible timeline, and to avoid double-counting across initiatives.
Do not ignore pricing and packaging. Many capabilities create value only if they are packaged, priced, and enabled for sales and CS. When you size uplift, state whether you assume packaging changes and who will own enablement.
Start with the levers product and technology can move within the holding period. Common revenue acceleration levers include: improving win rate by removing trust blockers, shortening sales cycles by standardizing security and integration responses, increasing conversion by reducing onboarding friction, increasing expansion by productizing adjacent workflows, and improving retention by reducing incidents and increasing adoption. Common cost-to-serve levers include: reducing tickets per account through productization, reducing engineering escalations, reducing cloud unit costs, and reducing implementation effort through tooling and standard patterns.
For each lever, write a mechanism statement and pick one primary metric. Win rate: fewer late-stage losses due to enterprise requirements. Sales cycle: fewer bespoke security and integration cycles. Activation: more customers reach first value within the target window. Retention: fewer high-severity incidents and deeper workflow usage. Support load: fewer tickets in top categories and lower escalation rate. Mechanisms anchor sizing in reality and help you triangulate evidence from customer interviews, telemetry, and support data.
Size with simple math and explicit baselines. Use ranges, not point estimates. For win rate, identify the pipeline portion where trust blockers occur, estimate the loss or delay attributable to those blockers, and apply a conservative improvement after the initiative’s completion. For activation, estimate the stall rate and the improvement achievable through specific onboarding and integration fixes. For retention, tie improvement to renewal timing and avoid assuming immediate impact.
Respect timing lags. Sales cycle and win-rate improvements can show within one to two quarters after the capability exists and sales enablement is complete. Retention improvements show at renewal and may take 6–18 months depending on contract duration. Support reductions can show quickly in ticket volumes, but headcount savings usually lag due to service-level expectations and hiring plans. Your value sizing must match these lags or it becomes fiction.
A defensible sizing checklist prevents optimism bias. Baseline: current metric. Addressable share: portion affected. Adoption: how quickly it is used. Timing: lag to dollars. Leakage: offsets like growth volume. If you cannot fill these, treat upside as directional.
Prevent double-counting by assigning primary benefits. An enterprise trust uplift should primarily impact win rate and discounting; a reliability program should primarily impact retention and support burden; a CI/CD program should primarily impact delivery speed and defect escape. Secondary benefits exist, but only size them when evidence is strong and when you can show they are not already captured by another initiative.
Translate cost-to-serve reductions into root-cause programs. Use support data to identify the top ticket drivers and estimate what portion is addressable through product work versus customer-specific variability. Use infrastructure data to identify the top cloud spend drivers and focus on unit cost improvements, not absolute spend reduction. If unit cost visibility is missing, treat instrumentation as a prerequisite and delay savings assumptions accordingly.
Present the upside as an investment case. Investment: initiative cost and staffing. Timing: when benefits begin and when they reach steady state. Benefit range: conservative to optimistic with drivers. Risks: what could prevent capture (adoption, scope creep, competing priorities). This format makes upside underwritable and helps the IC decide what to fund first.
Close with guardrails that tell you early whether value is being captured. Guardrails are leading indicators like activation within 30 days, reduction in top ticket categories, change failure rate, or time-to-complete onboarding steps. Including guardrails in the plan helps the owner course-correct before renewals or budget cycles force painful resets.
When this chapter is complete, you should have a coherent executable portfolio plan: a remediation backlog of initiatives, sized in people and dates, linked to risk terms and to value creation levers. That is what turns diligence from a report into a playbook.
