P&TD lives or dies on evidence quality. You can have the best interview guide and the sharpest technical instincts, but if you cannot see the right artifacts, you will either (a) over-index on management narrative or (b) drown in irrelevant documentation. This chapter is about avoiding both. It lays out what to request, what access models are realistic in a deal process, what to treat as red flags in the first 48 hours, and how to protect confidentiality without creating operational disruption.
3.1 The P&TD Data Request List (Minimum Viable Vs Best-in-class)
Most targets will happily give you decks. What you need are artifacts that reflect reality: what customers experience, what engineers ship, what breaks in production, and what commitments exist in contracts. The best request lists are not long; they are structured. They separate minimum viable inputs (enough to underwrite) from best-in-class inputs (enough to reduce residual uncertainty and build a detailed post-close plan).
Start by deciding which questions you are trying to answer. A request that is not connected to a question is a distraction. Then group requests by the way they are typically produced inside a software company: product planning, engineering delivery, operations, security/compliance, customer success, and business reporting. This grouping matters because it helps management assign owners and helps you diagnose gaps. If a company cannot provide basic operational artifacts, the absence is itself evidence about maturity.
Minimum viable inputs are what you should request on almost every deal, even when access is limited. If the company cannot produce these, you should assume elevated risk until proven otherwise. The goal is not completeness; it is sufficient triangulation to identify deal-breakers, seize the most material risks, and validate the thesis-critical roadmap items.
- Product and roadmap: current roadmap with themes and committed deliverables for the next two quarters; top 10 customer requests; release notes for the last 6–12 months; product packaging and pricing overview.
- Customer outcomes: NRR/GRR by cohort or segment; churn list with stated reasons; top customers by ARR; list of top expansion accounts; win/loss summary if available.
- Delivery and org: engineering and product org chart; headcount by function; description of SDLC and release cadence; summary of major initiatives shipped in the last two quarters.
- Architecture and operations: architecture overview diagram; hosting/deployment model; availability/SLA commitments; incident summary for the last 6–12 months (at least high-severity incidents); support ticket volumes and top drivers.
- Security and compliance: most recent security policies (or control summary); vulnerability management approach; incident response plan; any audit reports (SOC 2, ISO 27001, HIPAA/PCI as relevant); data retention and deletion policy.
- Data and analytics: definitions for core product metrics; a sample usage/adoption report; description of telemetry collection (events, logs, analytics tools).
- Contracts and commitments: standard MSA and DPA templates; top 10 customer contracts (redacted if needed) focusing on SLAs, security addenda, and bespoke commitments.
Best-in-class inputs reduce uncertainty and allow you to move from “directionally true” to “quantified and sequenced.” They also accelerate post-close execution because you can translate findings into a backlog with credible sizing. These inputs are common in well-run SaaS businesses but are often partial in services-heavy or earlier-stage companies.
- Product evidence: PRDs for thesis-critical roadmap items; customer journey maps or onboarding flows; product analytics dashboards; A/B test history (if applicable); product strategy docs tied to segment focus.
- Engineering evidence: Jira/Linear export for the last 2–3 quarters; cycle time and throughput metrics; defect escape rates; test coverage summaries; architecture decision records; dependency inventory and major third-party components.
- Operational evidence: SLOs and error budgets; on-call schedules; postmortems with action item tracking; observability stack configuration; capacity planning docs; cloud cost breakdown by service and environment.
- Security evidence: third-party penetration test results; risk register; access reviews; security training logs; vendor security assessments; evidence of control operation for key controls (IAM, secrets, logging).
- Customer evidence: implementation timelines by segment; PS utilization; support ticket tagging quality; CS health scoring and renewal playbooks; product gap analysis from renewal notes.
- Data evidence: event taxonomy; data model diagrams; pipeline lineage; data quality checks; governance approach for PII; AI feature evaluations if AI is part of the story.
To make the request list actionable, present it as a short table with owners and intent. This reduces “we don’t have that” responses that are really “we didn’t know why you needed it.” A practical template is below.
Request | Owner | Why it matters | Format |
Last 12 months of high-severity incidents and postmortems | Head of Engineering/Operations | Validate reliability risk and operational maturity | PDF exports or screen-share walkthrough |
Top customer contracts (ARR-weighted) with SLAs/security addenda | Legal/RevOps | Identify hard commitments and bespoke obligations | Redacted PDFs in data room |
Product usage/adoption dashboard for core workflows | Product Analytics | Test retention and expansion drivers | Dashboard screenshots or export |
Cloud cost report by service and environment | Cloud/FinOps | Assess margin, scalability cost, and optimization levers | CSV export or billing console walkthrough |
Two scoping guardrails keep the list tight. First, cap the minimum viable list so it can be fulfilled quickly; if it cannot be delivered in 3–5 business days, it is not minimum viable. Second, make best-in-class requests conditional: “Only needed if we find X,” or “Needed to size remediation.” This reduces perceived burden and makes it easier to negotiate access.
Finally, accept that documentation quality varies. Your request list should include an explicit option for substitution. If a company lacks a formal SLO document, ask to see their uptime dashboard and alerting configuration. If they cannot provide a cycle time dashboard, ask for a raw export from their work tracker. The objective is not paperwork; it is evidence.
3.2 Access Model: Product Demos, Repo Access, Logs, Cloud Consoles—what’s Realistic
Access is where diligence ideals meet real reality. Targets are protecting IP, customer data, and operational stability. Buyers are trying to reduce uncertainty in a short window. A good access model respects both: it is minimally invasive, time-boxed, and specific about what you will and will not do.
There are four common access modes, and most diligences use a mix. Mode 1: guided screen shares (demos, dashboards, code walkthroughs). Mode 2: controlled exports (CSVs, PDF reports, redacted contracts, anonymized logs). Mode 3: read-only tool access (analytics, ticketing, cloud billing) with tight permissions. Mode 4: clean room review for highly sensitive assets (source code, customer data, security reports). Choosing the right mode is a negotiation, not a demand, and it should be driven by the sensitivity of the asset and the value of the evidence.
Product demos are almost always available and are useful, but they are also easy to misread. To make demos evidence-driven, require three things. Scenario: ask for a demo of the workflows that matter to the thesis, not the “best looking” features. Role realism: see the product through the permissions of real personas (admin, power user, read-only stakeholder). Data realism: use realistic datasets, not empty sandboxes. If the target cannot demonstrate realistic data flows, that is itself a signal about maturity and onboarding complexity.
Repo access is the most sensitive request and the most politically charged. In many deals, full repo access is not realistic pre-close. The practical alternative is a structured “walk the repo” session in a clean room or via screen share. Ask the engineering lead to navigate the codebase with you: show the service boundaries, the deployment descriptors, the test suite, the dependency manifests, and a recent meaningful pull request. You are not trying to read code line-by-line; you are validating engineering health signals and architectural claims. When access is available, prefer read-only access to a mirrored repo with limited history and no ability to clone externally, and log all access for auditability.
Logs and operational data are more probative than source code, and they can usually be shared safely. If direct log access is not possible, ask for aggregated exports: incident timelines, error rate trends, latency distributions, capacity graphs, and top alert categories. If a company has observability tooling (e.g., Datadog, New Relic, Grafana), a read-only session where the operator drives can be sufficient. The key is to see how the system behaves under stress, not just how it is designed.
Cloud consoles can be a gold mine for understanding architecture, security posture, and cost drivers, but direct access to production is rarely acceptable. A realistic compromise is a billing-console walkthrough (which is less sensitive than resource-level access) plus screenshots or exports of key configurations: VPC layout, IAM roles, encryption settings, CI/CD integration points, and environment separation. If the thesis hinges on margin expansion or global scaling, push harder for billing data because it is often the fastest way to validate cost-to-serve assumptions.
Regardless of mode, your access requests should be framed as “show us how you run the business,” not “let us audit you.” This language reduces defensiveness and improves cooperation. It also helps you align on boundaries that protect operations.
Use these practical access principles:
- Least privilege: ask only for read-only access, time-limited, scoped to specific tools or projects.
- Operator-driven review: when access is sensitive, have the target’s operator drive the screen share while you direct the exploration.
- Anonymization by default: for customer data, use hashed identifiers, aggregated metrics, or synthetic datasets unless raw data is essential.
- Time-boxed deep dives: schedule short sessions (60–90 minutes) to answer a defined question, then stop.
- Audit trail: log who accessed what and when, especially for code and security artifacts.
When you need higher assurance than these modes provide—such as in regulated industries or when IP is central to valuation—use a clean room. A clean room can be physical (in-office review) or virtual (a controlled VDI environment with disabled copy/paste, restricted downloads, and monitoring). The goal is to let you see enough to validate claims without creating uncontrolled data leakage risk.
Also recognize that “access denied” is sometimes a commercial signal. If a target refuses to share any operational evidence, you may be facing either immature practices or a desire to preserve ambiguity. In either case, the right response is not to argue. It is to document the gap, explain the decision impact, and propose alternatives: independent testing post-signing, contractual representations, escrow/holdback, or a funded first-100-day assessment.
Access should end with clarity. At the end of each access conversation, write down: What we will see: specific artifacts or sessions; How we will see it: mode and controls; When: dates; and What it answers: the assumption or risk it validates. This turns access into a plan, not a negotiation loop.
3.3 Red Flags in The First 48 Hours (and How to Escalate)
The first 48 hours are disproportionately important. They determine whether you will have evidence early enough to go deep where it matters. They also reveal whether the target operates with discipline or with improvisation. Your job is to treat early signals as data, not as noise, and to escalate in a way that preserves momentum without damaging the relationship.
Most red flags are not “gotchas.” They are patterns that predict risk: weak instrumentation, fragile operations, or low process maturity. Some are also deal-process flags: intentional delays, selective sharing, or conflicting narratives.
Watch for five categories of early red flags.
- Evidence scarcity: The data room is full of decks but lacks core operational artifacts (incidents, support drivers, usage metrics, audit evidence). “We don’t track that” appears frequently.
- Inconsistent metrics: NRR/GRR numbers differ across decks, finance outputs, and management commentary, or definitions cannot be explained consistently.
- Roadmap vagueness: A roadmap exists only as themes with no epics, owners, or sequencing, especially when the thesis relies on near-term delivery.
- Operational fragility: Frequent sev-1 incidents, lack of postmortems, or an on-call model that depends on a single individual.
- Security discomfort: Resistance to sharing audit reports, unclear ownership of security, or an inability to describe basic IAM, secrets management, or vulnerability response.
There are also “people and dependency” red flags that surface early if you ask directly. If a single engineer owns the deployment pipeline, if the head of security is part-time, or if a critical system is maintained by a contractor without documentation, you should treat the business as key-person dependent. Similarly, if a large portion of the product relies on a third-party platform with unfavorable terms, you have a hidden strategic risk.
When a red flag appears, the first step is to translate it into a concrete question and a specific request. Red flags are often ambiguous until you pin them down. “No telemetry” might mean truly none, or it might mean data exists in logs but not in dashboards. “No postmortems” might mean no formal write-ups, or it might mean issues are handled informally in chat. Your goal is to determine whether the gap is documentation, process, or reality.
Use a simple escalation ladder that preserves trust while protecting the decision.
- Step 1: Clarify the gap and ask for substitution. “If you don’t have a formal incident report, can you walk us through your incident tool and the top five incidents with timelines and outcomes?”
- Step 2: State the decision impact. “Without this evidence, we cannot validate the reliability assumption underlying enterprise expansion, so we will need to treat it as a priced risk.”
- Step 3: Escalate to the deal lead and request intervention. “We need this within 48 hours or we will shift depth and recommend structural protections.”
- Step 4: Propose mitigations. “We can do a clean room review, a time-boxed read-only session, or a post-signing confirmatory diligence with a closing condition.”
Escalation works best when it is specific and time-bound. Vague escalation (“we need more access”) creates defensiveness. Specific escalation (“we need the last 12 months of sev-1 incidents and any postmortems by Thursday”) creates an actionable path.
Also differentiate between “cannot” and “will not.” Cannot suggest immaturity or lack of instrumentation and should be treated as an operational risk with remediation cost. Will not suggest sensitivity or negotiation posture and should be treated as an information risk that may require deal protections. Either way, document it in the risk register as soon as it is clear; waiting until the final week makes the issue feel like a surprise rather than a managed constraint.
Finally, use the first 48 hours to set expectations about responsiveness. Establish a single point of contact for requests, agree on a daily response cadence, and keep your question backlog tidy. If the target is overwhelmed, offer structure: prioritize requests, batch them, and explain why each matters. Diligence is a two-way process, and operational empathy often unlocks better access than pressure alone.
3.4 Confidentiality, Clean Rooms, and Avoiding Operational Disruption
Access is not just a logistics problem; it is a trust problem. Targets worry about IP leakage, competitive risk, and customer confidentiality. Buyers worry about making a decision with incomplete information. A good P&TD lead treats confidentiality controls as a design requirement, not a legal footnote, and builds an access approach that is safe enough to be granted and efficient enough to be useful.
Start with the principle of minimum necessary exposure. If a question can be answered with aggregated data, do not request raw data. If a question can be answered with a screen share, do not request downloads. If a question can be answered with a redacted contract, do not request the full agreement. This discipline reduces friction and demonstrates good faith.
Confidentiality controls typically fall into four buckets: contractual, technical, procedural, and behavioral. You will usually have the contractual bucket covered by the NDA. The diligence lead should focus on the other three, because that is where trust is earned.
- Technical controls: read-only access, time-limited credentials, restricted IP ranges, disabled downloads, watermarking, and access logging.
- Procedural controls: clean room sessions for highly sensitive assets, pre-approved attendee lists, and a single channel for sharing sensitive files.
- Behavioral controls: no recording of screens, no copying of code, and explicit limits on note-taking detail for sensitive IP.
A clean room is your strongest tool when the target is nervous about source code, customer data, or security artifacts. The goal is not to create bureaucracy; it is to create a safe container that unlocks evidence. A clean room should be designed around the minimum review needed to answer the question. For example, a two-hour repo review in a locked-down VDI can be enough to validate code organization, testing maturity, and dependency risk without exposing proprietary logic. Similarly, a clean room review of customer data can focus on anonymized cohorts rather than individual records.
When proposing a clean room, be concrete. Specify: Environment: VDI or on-site; Controls: no external connectivity, no downloads, monitoring; Participants: named individuals; Agenda: what you will review and why; and Outputs: what notes will be retained (typically summarized observations, not raw artifacts).
Confidentiality also includes protecting the target’s operational stability. Diligence requests can unintentionally disrupt the business if they trigger ad hoc data pulls, engineer interruptions, or risky access changes. Avoid this by designing an operating model that minimizes load on the team.
Use these disruption-reduction practices:
- Single-threaded requests: appoint one diligence coordinator on the target side; route all requests through them.
- Batching: send requests once or twice per day; avoid constant pings that fragment the team’s attention.
- Time-boxed sessions: schedule deep dives rather than asking engineers to “pull data when they can.”
- Use existing exports: prefer reports the business already produces (monthly reliability review, QBR decks, billing exports).
- Avoid production changes: do not ask the team to enable new logging, change IAM roles, or deploy instrumentation during diligence unless absolutely necessary, and never without clear approvals.
When you do need new evidence that requires work, be honest about the tradeoff. State the decision value and offer options. For example: “To size infrastructure cost, we can use a billing export (low effort) or a detailed service-by-service mapping (higher effort). The export is sufficient for underwriting; the detailed mapping would inform the first 100 days.” This framing lets management choose effort level while preserving your ability to document uncertainty.
Finally, remember that confidentiality concerns are often proxies for trust. How you behave matters. Show up prepared, use time efficiently, avoid fishing expeditions, and honor boundaries. When you do, targets are more willing to open the aperture, and you get better evidence with less friction. That is the practical path to getting the inputs you actually need.
