In product and technology diligence, the quality of the work is only half the job. The other half is landing it—clearly, credibly, and in a way that changes decisions. Investment Committees rarely fail because they lacked facts; they fail because they were given facts without meaning, or meaning without evidence. Your deliverables must therefore translate technical reality into underwriting implications and give the IC enough confidence to act on the translation.
15.1 The Executive Narrative: Thesis Alignment and “So What” Structure
The executive narrative is not a summary of what you did. It is a decision narrative: what is true, why it matters, and what the IC should do differently because of it. The most common mistake is to lead with an architecture tour or a list of issues. That forces the audience to do the translation work in real time, which is exactly what they will not do under time pressure. Lead with the thesis and the underwriting questions, then use evidence to answer them.
Start by restating the deal thesis in the same language the IC uses. Keep it to one or two sentences. Then declare the two or three diligence questions that matter most for that thesis. If the thesis is enterprise expansion, your questions are usually: Is the product and platform ready for enterprise trust requirements? Can delivery reliably execute the roadmap that unlocks enterprise? Will cost-to-serve stay controlled as complexity increases? If the thesis is usage-based growth, emphasize scalability, metering integrity, and unit cost visibility.
Once the questions are explicit, structure the narrative around answers, not topics. A useful pattern is: What we believe: the conclusion; Why we believe it: the evidence; What it means: the underwriting implication; and What we would do: the plan and owner. Repeating this pattern three to five times produces an IC-ready story without drowning the audience in detail.
Make your narrative “thesis-first” by building a simple mapping that you can repeat in the room. Thesis claim: what must be true for the deal to work. Capability: what product and technology must deliver to make that claim true. Evidence: what you saw that supports or weakens the capability. Implication: what changes in plan, price, or timing. This mapping is powerful because it prevents the conversation from drifting into interesting-but-irrelevant detail.
Be disciplined about segmentation. Most product and tech conclusions are true for some customers and not others. Phrase conclusions as bounded truths: strong for Segment A and use case X, fragile for Segment B and use case Y. Then translate boundaries into implications: which segments you should lean into, which you should price carefully, and which roadmap items are required to move the boundary.
Be explicit about confidence. Diligence happens under imperfect access. A credible narrative states what is known, what is inferred, and what remains uncertain. Use simple language: high confidence when evidence is direct (artifacts, metrics, repo walkthroughs), medium when evidence is triangulated but incomplete, low when evidence is primarily interviews or curated demos. When confidence is medium or low on a thesis-critical point, state what confirmatory action would raise confidence and how quickly it can be done.
A high-performing narrative contains five “so what” elements. Thesis support: what strengthens confidence in the plan. Thesis threats: what could break the plan. Economic translation: what changes in dollars or timeline. Owner action: what needs to happen and who will own it. Deal action: what the IC should do now (price, structure, diligence scope, or operating plan changes).
Be careful with technical language. Replace jargon with consequences. Instead of “high coupling,” say “small changes require coordination across many components, reducing predictability and increasing blast radius.” Instead of “lack of SLOs,” say “the company cannot reliably detect partial failures before customers do, increasing churn risk in enterprise cohorts.” You can keep the technical term in parentheses for practitioners, but lead with impact.
Make contradictions explicit rather than smoothing them over. It is common for sales, CS, and engineering to tell different stories about the same topic (roadmap credibility, security readiness, product quality). If you hide the divergence, the IC will discover it later and lose confidence in the diligence. A stronger move is to say: “These are the three perspectives, this is what the artifacts suggest, and this is the residual uncertainty.” This is also the right place to call out “unknown unknowns” driven by access limits.
Handle positives with the same rigor as risks. “The architecture is modern” is not a positive finding; “the platform has clear boundaries, a routine release cadence, and low change-failure rates, supporting confident roadmap execution” is. When you describe strengths, tie them to underwriting benefits: faster delivery, lower support burden, stronger pricing power, or lower integration cost. Balanced, evidence-based positives also prevent the narrative from reading like a risk memo dressed up as diligence.
End with explicit decisions and conditions. The IC is deciding whether to proceed, what price to pay, what terms to ask for, and what the first-year plan should be. Make those choices easy by listing the few “must accept” items: conditions that must be true for the deal economics to work (and when they must be true). If an item is a “nice to have,” label it as such. Conditions should be measurable and time-bound; vague conditions are not enforceable and do not guide execution.
15.2 The Risk Register: Severity, Likelihood, Detection, Mitigation Owner
A risk register turns technical concerns into managed risk. The purpose is not to create a scary list; it is to create risks that can be monitored, owned, and mitigated over time. A good register also prevents the most expensive post-close failure mode: everyone knew about a risk, but no one owned it, and no one tracked whether it was improving.
Start with a strict definition of “risk.” A risk is a plausible event or condition that, if it occurs, has a material impact on revenue, margin, timing, or regulatory exposure. Do not put general observations into the register unless they have a clear mechanism to an outcome. “Tech debt is high” is not a risk. “Weak release controls increase the probability of repeat sev-1 incidents during peak periods, which could trigger churn and SLA credits” is.
Keep the register small and ranked. Ten to fifteen risks is usually enough for an IC discussion. More than that is often a sign that items have not been consolidated into root causes. If you have thirty issues, you probably have ten risks and twenty symptoms. Consolidate symptoms under the risk that explains them, and keep the symptom list as evidence rather than as separate risks.
For each risk, capture four mandatory fields and two helpful fields. Severity: impact if it happens. Likelihood: probability within the relevant horizon (often 12–18 months). Detection: leading indicators that show the risk is materializing. Mitigation owner: the accountable person and team. The helpful fields are Mitigation plan: what will be done and by when, and Residual risk: what remains even after mitigation.
Define severity and likelihood scales so the register is consistent. A simple scale works well in deals. Severity high: could change the investment outcome (material churn, material margin compression, regulatory exposure, or multi-quarter delay). Severity medium: could reduce returns (lower growth, higher costs, slower execution) but is unlikely to break the deal. Severity low: operational nuisance or best-practice improvement. For likelihood, anchor to evidence: high means “already happening or recurring,” medium means “plausible given current controls,” low means “would require multiple failures or significant external change.”
Severity should be described in business terms first and technical terms second. Tie severity to outcomes the IC can price: churn, discounts, delayed pipeline conversion, margin compression, or regulatory exposure. Where possible, quantify a range: ARR at risk, one-time remediation cost, or timing slip. If you cannot quantify, state what proxy you are using and why it is directionally sound.
Likelihood should be evidence-based. Use observed frequency, recurrence patterns, and maturity signals. If the company has repeated incidents tied to deployments and still lacks gates, likelihood is higher. If recurrence is falling and postmortem actions close reliably, likelihood is lower even if incidents have happened. If you cannot judge likelihood due to limited evidence, label confidence as low and propose a confirmatory action.
Detection is the field that makes the register operational. Detection asks: what changes before the bad outcome occurs? For reliability, detection might be rising incident frequency, worsening error rates, or increasing support escalations in a cohort. For security, detection might be critical vulnerabilities aging past SLA, unusual privileged access, or recurring audit exceptions. For roadmap risk, detection might be rising cycle time variance, growing WIP, or repeated missed milestones. When you specify detection signals, you are also implicitly specifying what dashboards and reporting the business must have post-close.
Mitigation owners must have both authority and capacity. Naming “engineering” is not ownership. Name a role: CTO, Head of Platform, CISO, VP Product, or a specific program leader. If a risk spans functions, assign a single accountable owner and list consulted roles, but do not dilute accountability. Cross-functional risks without a single owner are the ones that persist through multiple quarters.
Make the register actionable by linking each risk to at least one initiative in the value creation plan. A risk without a funded initiative is a hope. An initiative without a linked risk or value lever is a hobby. The linkage forces discipline and makes the register useful for post-close governance.
Decide which risks are accepted versus reduced. Not every risk should be mitigated aggressively. Some risks are acceptable given deal economics, segment focus, and holding period. Document acceptance explicitly: “we accept this risk because it is low likelihood, because downside is bounded, or because mitigation cost exceeds value.” This prevents teams from chasing perfection and helps focus resources on the risks that actually matter.
Present the register with prioritization. Highlight the top three to five risks and explain why they are top: severity, likelihood, and proximity to decision points such as renewals, audits, or TSA exits. Then state the first mitigation milestone for each top risk and how it will be measured. A good close to this section is an explicit statement of “what we will watch in the first quarter” so the IC can monitor reality against the plan.
15.3 The Value Creation Plan: First 100 Days and 12–18 Month Roadmap
The value creation plan is where diligence becomes executable. It should do more than list opportunities; it should provide a plan the new owners can adopt on Day 1. The most useful plans are thesis-led, capacity-aware, and measured with milestones that map to financial outcomes.
Begin by restating the thesis in operational terms. If the thesis is “move upmarket,” the plan must include enterprise trust, delivery predictability, and productized onboarding. If the thesis is “drive NRR,” include adoption instrumentation, churn mechanism fixes, and expansion packaging. If the thesis is “improve margin,” include support burden reduction, cloud unit cost control, and reduction of bespoke implementation work. If the plan is not explicitly tied to the thesis, it will be deprioritized as soon as revenue pressure arrives.
Structure the plan in two horizons: Day 1 to Day 100, and 12 to 18 months. The first horizon is about stabilization and momentum—reducing immediate risks and creating early wins that free capacity. The second horizon is about thesis enablement—shipping capabilities that unlock the growth and margin plan. Each horizon should have a small number of initiatives, clear owners, and measurable outcomes.
First 100 days: Avoid ambitious re-architecture. Focus on control and clarity. High-ROI moves often include: instrumenting leading indicators (activation, workflow usage, top ticket drivers), tightening release gates and rollback practices, establishing escalation and commitment governance, creating a credible enterprise trust path (even if full attestations take longer), and addressing one or two recurring failure classes driving incidents or support load. These moves are valuable because they reduce surprises and protect engineering capacity.
Use the first 100 days to “stabilize the machine.” That includes small operational upgrades that disproportionately improve throughput: reducing work-in-progress, clarifying decision rights on what can be promised externally, and installing a single cadence where product, engineering, CS, and support make tradeoffs explicitly. These steps are not glamorous, but they are often the difference between an ambitious plan that ships and an ambitious plan that becomes a deck.
In the first 100 days, also close the evidence gaps that limited confidence pre-close. Fund a confirmatory sprint with defined outputs: a cloud cost attribution baseline, a deeper repo and CI/CD review, a data governance gap assessment, or a carve-out dependency burn-down plan. Label these as uncertainty reduction: initiatives; they prevent surprise remediation programs and allow owners to invest confidently. Tie each uncertainty reduction to a decision it will unlock, such as “finalize pricing for usage-based packaging” or “commit to a TSA exit date.”
12–18 months: This horizon contains the programs that change trajectory. These programs are usually cross-functional and must be protected by governance and capacity allocation. Examples include: enterprise readiness uplift (SSO/SCIM, audit logs, admin tooling, evidence packaging), scalability and tenancy controls for large customers, integration productization to reduce onboarding effort, reliability programs that reduce incident frequency and improve SLAs, and delivery improvements that increase predictability. For each program, state not only what will be built, but how you will measure that it changed outcomes and which cohorts will benefit first.
Link initiatives explicitly to the financial model. For each major initiative, define Primary value lever: win rate, cycle time, churn reduction, expansion attach, support cost reduction, or cloud unit cost reduction. Then define Lag to dollars: when the benefit shows up (immediately, next quarter, at renewal). This prevents a common IC disconnect where the plan is strong but the model assumes benefits too early.
Make capacity visible. State how much engineering capacity is available after operational load, customer commitments, and ongoing roadmap work. If the plan assumes hiring, state the roles, timing, and ramp. If the plan assumes vendors, state what they deliver and what internal ownership remains. A plan that ignores capacity becomes a set of broken promises, and broken promises kill trust quickly post-close.
Make sequencing explicit. Many initiatives have prerequisites that cannot be parallelized. Enterprise packaging depends on entitlements; entitlements depend on identity and billing primitives; identity changes require careful migration and testing. Reliability improvements depend on observability and release controls. Data and AI programs depend on metric definitions and governance. Calling out dependencies is not pessimism; it is how you keep the plan credible.
Use milestones that can be proven. “Work started” is not a milestone. A milestone is “p95 latency improved by X% on the core workflow,” “top ticket category reduced by Y% via productization,” or “SSO implemented as a repeatable standard and security-review cycle time reduced.” These proofs are the bridge between engineering activity and underwriting confidence. When possible, include a “before” and “after” view so the IC can see that the business is learning and improving, not just spending.
Finally, define the governance mechanism that protects the plan: weekly cross-functional triage with decision rights, biweekly roadmap review with explicit tradeoffs, and a monthly operating review that tracks leading indicators and initiative progress. Without this, urgent escalations will crowd out foundational work. Governance is also where you prevent scope creep: every new request must displace something else, and that displacement must be visible.
15.4 Templates: Slide Outline, One-page Findings Memo, Diligence Scorecard
Templates reduce cycle time and increase consistency. They standardize packaging so your thinking is visible under deal pressure.
Slide outline template
Use this as a default sequence. Adjust depth based on deal complexity, but keep the logic: thesis, conclusions, risks, plan, and evidence.
- Slide 1: Deal thesis and the P&TD questions we set out to answer.
- Slide 2: Executive conclusions—bounded by segment/use case, with confidence levels.
- Slide 3: What is working well—strengths that support the thesis and why they matter.
- Slide 4: Top risks (3–5)—severity, likelihood, detection signal, first mitigation milestone.
- Slide 5: Roadmap and delivery credibility—what can be underwritten and why.
- Slide 6: Reliability and support economics—incident patterns, ticket drivers, cost-to-serve implications.
- Slide 7: Security, privacy, and compliance—segment bar versus current state and path.
- Slide 8: Architecture and scalability—binding constraints and mitigation path.
- Slide 9: Data/analytics/AI—substance versus story and prerequisites.
- Slide 10: Value creation plan—first 100 days initiatives with owners and leading indicators.
- Slide 11: Value creation plan—12–18 month initiatives, dependencies, and outcome timing.
- Slide 12: Risk pricing and deal actions—model impacts, structure levers, confirmatory diligence asks.
- Appendix: Evidence details—metrics, artifacts requested, interview list, and sizing assumptions.
As a presenter, keep one message per slide. If you need two messages, split the slide. In Q&A, keep a few backup slides with direct artifacts—metrics, screenshots, and customer quotes—so you can prove a point without derailing the meeting. If a slide cannot change a decision, move it to the appendix immediately.
One-page findings memo template
This memo is the “single sheet of truth” for stakeholders who will not read the full deck. Write it in short paragraphs so it can stand alone.
- Deal context: one sentence on the thesis and what success looks like in 18 months.
- Overall conclusion: proceed/conditional/no-go framing, with one sentence on why.
- Thesis support: two to three evidence-backed strengths.
- Thesis threats: two to three risks stated as mechanisms.
- Economic implications: what changes in dollars and dates (ranges) and the key assumptions.
- First 100 days: three to five initiatives that protect value and create momentum, with owners.
- Deal actions: confirmatory diligence requests, pricing/structure recommendations, conditions.
- Confidence and limits: evidence available and what remains uncertain.
Make the memo quotable. IC members often reuse language directly. Write sentences that can be lifted without rework: concrete, bounded, and evidence-backed.
Diligence scorecard template
The scorecard is a fast visual that communicates where the business is strong, where it is fragile, and where investment is required. Use a 1–5 scale with brief anchors and include a confidence label for each dimension.
- Product fit and adoption: 1 means weak activation and shallow adoption; 3 means mixed fit with clear boundaries; 5 means deep workflow usage and durable expansion.
- Differentiation and defensibility: 1 means parity and price-driven losses; 3 means workflow lock-in in core segment; 5 means defensible advantage through data, distribution, or trust barriers.
- Delivery capability: 1 means unstable priorities and unpredictable shipping; 3 means functional delivery with uneven predictability; 5 means stable decision rights and repeatable execution.
- Architecture and scalability: 1 means binding constraints and frequent degradation; 3 means headroom with known bottlenecks; 5 means scalable design with isolation controls.
- Reliability and operations: 1 means repeat incidents and reactive operations; 3 means basic discipline with recurring failure classes; 5 means SLO-like operations with falling recurrence.
- Security and compliance readiness: 1 means below enterprise bar; 3 means near bar with a credible path; 5 means at bar with operating controls and clean attestations.
- Data and analytics maturity: 1 means inconsistent definitions and frequent disputes; 3 means usable analytics with known gaps; 5 means governed, trusted data with lineage.
- Integration readiness: 1 means heavy dependency risk; 3 means feasible with staged plan; 5 means strong primitives and low-risk integration path.
After scoring, add two short lines: Top investments: the three initiatives most likely to raise the score quickly, and Watch items: the three leading indicators the IC should monitor quarterly. This turns the scorecard into an operating tool rather than a static artifact.
When deliverables are done well, the IC discussion becomes about choices, not confusion. Your job is to create that clarity: a thesis-aligned narrative, an ownable risk register, and an executable value creation plan backed by evidence and realistic assumptions.
