Data is now part of the product. In many software businesses, customers do not buy a “tool” so much as they buy an outcome delivered through data: cleaner processes, faster decisions, better forecasts, fewer errors, or automated actions. Analytics and reporting are often the proof of that outcome. AI is increasingly marketed as the accelerator. Yet in diligence, data and AI are also where stories outpace substance.
12.1 Data Foundations: Models, Pipelines, Governance, and Quality
Data foundations are the plumbing that determines whether analytics are trusted, whether AI features are viable, and whether the business can run efficiently. In diligence, you are not trying to document every table. You are trying to understand the data lifecycle: where data comes from, how it is transformed, how it is governed, and whether it is accurate enough for customer-facing decisions and internal operations.
Start by clarifying what “data” means for the target. For some products, customer value is driven by workflow data the product generates naturally. For others, the product’s value depends on ingesting customer data from external systems, transforming it, and presenting insights or actions. The second model carries more risk because integration variability and customer data quality become structural constraints. If the thesis relies on analytics differentiation or AI, you need to know which model you are in.
Build a minimal data map in one session. Focus on four elements. Sources: product event streams, transactional databases, customer imports, integrations, third-party datasets. Stores: operational databases, object storage, search indexes, warehouses/lakes, feature stores if any. Transforms: ETL/ELT jobs, streaming pipelines, enrichment steps, aggregation layers. Consumers: product features, dashboards, alerting, internal metrics, AI workflows. A strong team can describe these plainly and can identify the critical paths that must not break.
Then examine the data model only where it affects correctness and scale. Ask how the system represents customers, users, accounts, and the domain entities that drive the core workflow. In multi-tenant systems, confirm how tenant boundaries are represented in analytics stores as well as operational stores; mismatches are a common source of reporting errors and trust concerns. Also ask how major entity changes are handled (merges, hierarchy changes, reclassification) without fragile backfills.
Pipelines: Data pipelines create “time lag,” “data drift,” and “silent failure” risk. Ask how data moves from operational systems to analytics. Is it batch, streaming, or hybrid? What refresh cadence customers experience? Where are failures detected, and who responds? If customers rely on dashboards for daily operations, pipeline reliability becomes a retention driver. If pipelines require manual babysitting, cost-to-serve scales poorly.
Look for evidence of pipeline discipline. Healthy signals include: versioned pipeline code, automated tests for transformations, clear data contracts, and monitoring of freshness and volume anomalies. Weak signals include: transformations living as untracked SQL in shared docs, manual fixes that are not captured as code, and “we notice issues when customers complain.”
Data contracts: When the product depends on incoming customer or partner data, ask whether schemas are versioned, breaking changes are detected early, and there is a clear compatibility policy. Without contracts, onboarding turns into repeated one-off work and “data drift” becomes a chronic support driver.
Governance: Governance is the set of rules that make data trustworthy and safe: ownership, definitions, access controls, and change management. Ask who owns metric definitions, who can change them, and how changes are communicated to downstream consumers. If the product includes customer-facing analytics, governance failures become customer-facing incidents.
Request a metric definition pack for the few metrics the business uses to run itself and to sell: activation, active users, retention, churn drivers, and usage volume. Then validate whether definitions are consistent across product, finance, and CS. Inconsistent definitions are a high-signal “data maturity” red flag because they create decision noise and reduce confidence in KPI-based value creation plans.
Do not ignore access controls in the analytics stack. Many teams lock down the application database but leave warehouses, BI tools, or support exports broadly accessible. Ask who can query customer-level data, whether access is logged, and whether data is masked in non-production environments. If the deal includes a carve-out or plans for add-on integrations, also ask how data is separated across products and whether there is a clean way to migrate or partition historical data without breaking customer reporting at scale.
Quality: Data quality is not about perfection; it is about whether error is low enough and visible enough to be managed. Ask what checks exist, what failure classes dominate, and how issues are triaged. In ingestion-heavy products, ask how the company handles schema changes, missing fields, duplicates, and out-of-order events. If the product relies on near-real-time signals, ask how it handles late-arriving data and whether customers see numbers change after the fact.
Use a practical quality lens: correctness, completeness, timeliness, and explainability. Correctness: are calculations consistent and reproducible? Completeness: are key events reliably captured? Timeliness: do dashboards update when customers expect? Explainability: can the company trace a number back to source events? If there is no lineage or drilldown capability, trust often collapses under scrutiny and support load rises.
Also evaluate data operations. Ask whether there is a formal “data on-call” rotation or a clear owner for pipeline incidents. In many companies, data issues fall between engineering and analytics teams, creating slow response and repeated customer frustration. If the thesis includes expanding analytics or AI features, unclear data operations ownership should be treated as an execution risk.
To keep diligence efficient, ask for a short set of artifacts that proves operating reality.
- Data flow diagram: a high-level map of sources, stores, and consumers.
- Pipeline monitor view: freshness and failure alerts for key customer-facing pipelines.
- Metric definitions: written definitions for core product and business metrics.
- Cost snapshot: monthly warehouse/logging costs and top drivers.
Connect data foundations to cost and scalability. Data platforms can become margin traps through warehouse spend, log ingestion, and third-party tooling costs, especially when instrumentation is noisy or retention is undefined. Ask whether the company can attribute data platform costs and whether guardrails exist on event volume, log verbosity, and retention. If not, assume scaling analytics and AI will require a FinOps-like discipline for data, plus product changes that reduce unnecessary event noise.
12.2 Analytics and Reporting: Customer Value and Support Load Implications
Analytics and reporting are often presented as a feature set, but in diligence you should treat them as a product promise: “we will help you see what is happening and make better decisions.” This promise has two sides. It can create customer value and differentiation, increasing retention and expansion. It can also create support burden and trust risk when reports are wrong, slow, or confusing.
Begin by identifying which reports and insights actually matter to customers. Many products ship dozens of charts, but customers typically rely on a handful for operational decisions and executive reporting. Ask CS and product which dashboards show up in QBRs, which metrics customers ask about most, and which reports drive renewal conversations. Then validate with customer interviews and telemetry: which report pages are visited repeatedly, which exports are frequent, and which alerts are configured.
Evaluate the analytics experience end to end: freshness, correctness, speed, usability, and governance. Freshness: do customers understand when data updates and can they see last-updated timestamps? Correctness: can the company reconcile reported numbers to raw data and explain discrepancies? Speed: are dashboards usable under real datasets, especially for large customers? Usability: can non-experts answer questions without custom queries and exports? Governance: are definitions stable and documented?
Reporting becomes a support burden for three common reasons. First, customers want metrics that reflect their business logic, which may not match defaults. Second, customers export to spreadsheets because built-in views are insufficient. Third, ingestion issues surface as “the report is wrong” tickets. Your diligence objective is to determine whether this is structural (the product will always require heavy customization) or fixable (better definitions, templates, and defaults).
Assess whether analytics are self-serve or analyst-dependent. If customers frequently request custom reports, need vendor-built dashboards, or rely on professional services to interpret data, then analytics are acting like services, not products. That can still be viable, but it changes scaling assumptions and margin. Ask how many “reporting requests” are handled per month, how often those requests require engineering, and whether the most common requests have been productized over time.
Ask for a support category breakdown specifically for reporting and data questions. If ticket volume is high, drill into what those tickets are: usability confusion, performance timeouts, or correctness disputes. The fix differs by class. Usability issues require UX and education. Performance issues require platform work. Correctness issues require data quality checks and lineage.
Also examine how reporting interacts with pricing and revenue integrity. If higher tiers include advanced analytics, reliability must justify pricing. If usage-based pricing depends on measured events, analytics correctness becomes a billing trust issue. Ask whether there have been disputes tied to metered usage and how reconciliation works in practice.
When time is tight, run a simple “reporting reality” test in 30 minutes. Ask the team to walk through the reporting workflow a typical customer uses and watch for where complexity and trust friction appear.
- Create and filter: can a user build a view that matches a common business question?
- Drilldown: can the user trace an aggregate number to underlying records?
- Explain definitions: can the product show what a metric means and how it is calculated?
- Export and API: are exports reliable, and do APIs support the same view without special cases?
- Performance at scale: do the same screens remain usable on a large tenant dataset?
A high-yield method is to select two customer workflows and follow the analytics chain. For each workflow: what event is generated, how it is transformed, how it appears in the UI, how a customer uses it to decide, and what happens when the number is wrong. This reveals whether analytics are a first-class product capability or a bolt-on reporting layer, and where support burden is created.
Finally, translate analytics findings into both upside and risk. Upside shows up when analytics are a trusted system-of-record for customers, enabling workflow lock-in and making expansions natural. Risk shows up when reporting is inconsistent, when customers need heavy customization, or when the data platform cannot support large tenants without degradation. In both cases, connect to the model: retention, expansion, support cost, and roadmap investment needs.
12.3 AI Claims: Evaluation Framework (Data Rights, Accuracy, Cost, Risk)
AI is now a default narrative in software. Buyers ask about it, competitors market it, and investors want to know whether it is real differentiation or a temporary marketing layer. Diligence should neither dismiss AI nor accept it at face value. Use a repeatable evaluation framework that tests whether AI claims can be underwritten and whether AI features will create durable value without unacceptable cost or risk.
Start with a simple classification of what “AI” means in the product. Assistive: drafting, summarization, semantic search, and copilots that improve productivity. Analytical: predictions, anomaly detection, scoring, and recommendations based on data patterns. Automated: actions executed by the system with limited human review. Each class has different risk and evidence requirements. Assistive features can create value quickly but may be easier to copy. Analytical features can be differentiated if the workflow and data are unique. Automated features carry the highest risk because errors become operational outcomes.
For any AI claim, force a statement of the job-to-be-done. What decision or action is being improved? Who is the user? What is the baseline process today? AI features that do not replace a meaningful workflow often become novelty features with low adoption. AI features that target a core workflow can increase lock-in, but only if reliability and governance are built in.
Then evaluate along four axes: data rights, accuracy and evaluation, cost and scalability, and risk and governance.
Data rights: Underwrite whether the company has the right to use the data it plans to use for AI. This includes customer contracts, DPAs, subprocessor agreements, and internal policies. If models are trained on customer data, confirm explicit consent and boundaries. If AI features depend on third-party models, confirm whether customer data is sent to external providers and under what terms. The diligence goal is to avoid a post-close rollback because contracts, privacy commitments, or customer expectations do not permit the intended data use.
Also evaluate the “data footprint” used for AI. Is it primarily telemetry, customer content, metadata, or external datasets? The more sensitive the data, the higher the governance and customer-acceptance bar. In regulated segments, buyers often require clear handling, retention, and opt-out controls for AI features.
Accuracy and evaluation: Ask how the company measures AI performance. For assistive features, evaluation often includes relevance, helpfulness, and user acceptance rates. For predictive or recommendation systems, evaluation must include quantitative metrics and an explicit view of false positive/false negative costs. Most importantly, evaluation must be tied to the workflow: what happens when the system is wrong? If the cost of being wrong is high, the product needs guardrails such as human review, confidence thresholds, and explainability.
Request evidence of evaluation, not just demos. Look for testing methodology, validation datasets, and ongoing monitoring. If the company cannot describe how it measures accuracy, treat AI claims as low confidence. Also ask whether evaluation is segmented by customer type; AI performance often varies across industries and data profiles.
Assess what is actually being built: proprietary models, fine-tuning, retrieval-augmented generation, or simply calling an external API. None is inherently “better,” but each has implications. External APIs accelerate time-to-market but create vendor dependence and variable cost. Fine-tuning can improve fit but increases governance burden. Proprietary models can be differentiating but require significant investment. Your underwriting conclusion should reflect the real approach and whether it matches the holding period.
Operationalization is where AI programs succeed or fail. Ask who owns model versions, prompts, and retrieval indexes, and how changes are deployed. Look for a release process: staged rollouts, A/B tests, shadow traffic where feasible, and automated rollback when key metrics degrade. Ask how drift is detected and handled: when customer behavior or data distributions change, does performance degrade silently or is it surfaced through dashboards and alerts? Confirm feedback capture: do users rate outputs, correct them, and does that feedback become labeled data under governance? Finally, ask how AI incidents are handled—who is paged, what is the mitigation playbook, and how customers are notified when AI behavior is wrong or unavailable.
Cost and scalability: AI features can change unit economics. Inference costs, vector databases, higher compute, and increased logging can become material, especially in usage-based models. Underwrite AI cost by mapping: which actions invoke AI, how often, the per-call cost, and what guardrails prevent runaway usage. Ask whether the company tracks AI usage and cost by tenant, and whether pricing captures those costs. If AI costs are not visible or monetized, margin assumptions may be fragile.
Risk and governance: AI risk includes privacy risk, security risk (prompt injection, data leakage), compliance risk, and reputational risk. Underwrite whether guardrails exist: safe prompt handling, input sanitation, role-based access to AI features, audit logs of AI actions, and opt-in/opt-out controls. For automated actions, require stronger controls: human approval steps, confidence thresholds, and rollback mechanisms.
Ask how the company handles prompts and outputs. Are they stored? For how long? Who can access them? Are they included in logs? Many teams inadvertently increase data exposure by logging prompts broadly. If the company sells to an enterprise, these details can become deal blockers.
Finally, connect AI to differentiation. AI is defensible when it is tightly integrated into a proprietary workflow and improves outcomes in a measurable way, especially when the improvement depends on data competitors cannot easily obtain. AI is less defensible when it is a generic assistant layer using public models with minimal unique data. State which case applies and what is required to improve defensibility.
Conclude AI evaluation with a confidence statement. High confidence: evidence of adoption, evaluation, cost visibility, and governance controls. Medium confidence: credible prototypes and partial evidence but gaps in evaluation or cost tracking. Low confidence: primarily demos and narratives with limited evidence. This confidence level should influence whether AI is underwritten as a near-term growth driver or treated as optional upside with a funded validation plan.
12.4 Templates: AI Feature Diligence Checklist, “AI-washing” Red Flags
Templates help keep AI diligence practical when deal timelines are short and narrative pressure is high. Use the checklist below in a single session with product and engineering leaders, then validate with artifacts where possible. Use the red flags list to identify when the AI story is mostly positioning and should be treated as low-confidence upside.
AI feature diligence checklist: Use this when the target claims AI as a differentiator or when the thesis depends on AI-enabled pricing, retention, or expansion.
- Use case clarity: the workflow improved and the metric that defines success.
- Data inputs: what data is used and the quality constraints.
- Data rights: permissions, customer controls, and external-provider terms.
- Model approach: API/RAG/fine-tune/proprietary; why it fits the segment.
- Evaluation: how performance is measured and monitored over time.
- Guardrails: human review, confidence thresholds, role controls, audit logs.
- Cost visibility: per-call cost, usage tracking, and pricing alignment.
- Support and feedback: how users correct outputs and how learning loops work.
- Security posture: prompt injection considerations and tenant separation.
- Commercial linkage: packaging, sales cycle impact, and renewal narrative.
“AI-washing” red flags: These patterns suggest the AI story should not be heavily underwritten without confirmatory work.
- Demo-only evidence: no usage tracking, adoption data, or customer references.
- Undefined success: no metric tied to customer outcome improvement.
- No evaluation method: no testing framework, validation dataset, or monitoring plan.
- Hidden data rights risk: unclear consent or constraints that limit intended data use.
- Cost blind spot: no visibility into inference costs or tenant-level usage.
- No guardrails: outputs acted on without review or auditability.
- Generic positioning: claims indistinguishable from competitors and weak workflow integration.
- Operational mismatch: weak data foundations and observability for AI at scale.
When red flags appear, convert them into a constructive plan rather than a rejection. Many companies can build real AI value, but the path usually starts with foundations: clean data, stable definitions, governance, and observability. Underwriting should treat AI as a layered program. Layer 1: instrument and govern data so outcomes can be measured. Layer 2: ship assistive features that drive adoption and learning with controlled risk. Layer 3: expand into predictive and automated features only when evaluation, guardrails, and cost controls are proven.
The discipline is to keep the narrative honest. If AI is real, you should be able to show adoption, measurement, and operational control. If AI is early, you should be able to describe a credible path with prerequisites and investment. In both cases, you are underwriting substance, not story, and that is what protects value and accelerates post-close execution.
Across data, analytics, and AI, the same principle holds: credibility comes from traceability. When a customer asks “why,” the company must be able to answer with definitions, lineage, and evidence. When the IC asks “how confident are we,” you must be able to point to operating artifacts, not just strategy slides. That is how substance becomes underwritable and how story becomes a plan.
