Software diligence can be technically perfect and still be wrong if it misunderstands the customer. Customers are where product claims meet reality: do the workflows actually get used, do promised outcomes show up, and do failures create churn risk? Customer evidence is also where you discover the “why” behind the numbers. A churn rate tells you the outcome; customer evidence tells you the mechanism.
6.1 Interview Plan: Who to Speak With, Scripts, and Triangulation
Customer interviews are often treated as a formality: call a few friendly references, hear that “things are going well,” and move on. That approach produces false confidence. The value of interviews comes from structure. A disciplined interview plan gives you a balanced sample, a repeatable script, and a triangulation method so you can separate one-off anecdotes from systemic patterns.
Start by defining what you need interviews to answer. Most P&TD workstreams need customer evidence on five themes: the job-to-be-done and value achieved, onboarding and time-to-value, product adoption depth and workflow fit, reliability and support experience, and competitive alternatives. If the deal thesis includes enterprise expansion, add trust and governance topics (security posture, auditability, admin controls). If the thesis includes pricing uplift, add willingness-to-pay and value-metric clarity.
Next, design a sample that reflects the underwriting model rather than convenience. A common failure mode is sampling only satisfied customers and then concluding the product is strong. Instead, select customers across outcomes and contexts. When access allows, ask for a list of accounts with a few fields (ARR, segment, tenure, renewal date, implementation model, product modules, integration count, and CS health score). Use that to select a purposeful mix.
Customer type | Why you need them | How many (typical) |
New customers (last 6–12 months) | Validate onboarding friction and early value delivery | 2–3 |
Long-tenure customers | Test durability, embedded workflows, and switching costs | 2–3 |
High expansion accounts | Identify what “success” looks like and what drives NRR | 1–2 |
At-risk or recently renewed under pressure | Surface near-term churn drivers and trust issues | 1–2 |
Implementation-heavy / high services accounts | Quantify cost-to-serve and product gaps masked by services | 1–2 |
If you cannot get a balanced sample, document the limitation and compensate with other evidence. For example, if the company will only provide “reference accounts,” ensure you also review churn notes, support drivers, and telemetry so you are not underwriting solely from curated narratives.
Interview roles matter as much as accounts. When possible, speak with at least two personas at one customer: the executive sponsor (value and renewal decision) and the day-to-day admin or power user (workflow reality). Executives tend to describe strategic outcomes; practitioners describe friction, workarounds, and operational load. When the two views diverge, you have discovered a key diligence thread.
How you frame the call determines candor. Open with a short confidentiality statement: you are speaking on behalf of an investor, the conversation will be summarized without attribution, and you are not evaluating the customer’s team. Ask permission to take notes and, if the customer seems cautious, offer to keep details at the “pattern” level rather than quoting specific incidents. Keep the tone operational, not promotional. Avoid fishing for sensitive commercial terms; instead, ask for the practical constraints that shaped the relationship, such as procurement requirements, security reviews, or internal change management hurdles. Close by asking what internal metric they track that the product influences, because that reveals what “value” means in their language.
Use a consistent script that is short enough to run in 30–40 minutes but deep enough to generate evidence. The script should be built around concrete examples rather than opinions. Ask for specific moments, metrics, and comparisons. Avoid leading questions like “What do you like about the product?” which invite politeness. Instead, ask questions that force tradeoffs and recall.
- Context: What problem were you solving, and what was happening before you bought this product?
- Decision: Who evaluated alternatives, what else did you consider, and why did you choose this vendor?
- Time-to-value: What did “go-live” mean for you, how long did it take, and what almost derailed it?
- Workflow fit: Which workflows run through the product weekly, and which still happen outside the product?
- Adoption depth: Who uses it, how often, and what features are essential versus rarely touched?
- Reliability and support: What incidents or failures have mattered most, and how does support behave when something breaks?
- Trust: What did security and procurement require, and what commitments did you need in the contract?
- Economics: What are you paying for, do you feel price matches value, and what would make you pay more or less?
- Renewal narrative: If you had to justify renewal tomorrow, what would be your strongest argument and your biggest concern?
- Switching: If you had to replace the product, what would be difficult, and what would you do instead?
Make triangulation explicit during the interview. When customers make broad statements, ask for proof points. If a customer says “support is great,” ask for a recent ticket example and what resolution time felt like. If they say “the product is easy to use,” ask who onboarded the last new user and how long it took. These follow-ups are not adversarial; they are how you convert sentiment into evidence.
After each call, write a short, standardized summary while details are fresh. Use the same fields for every interview so you can compare across customers. A practical template is: Outcome achieved: what improved; Time-to-value: key milestones and friction; Daily workflow: what is used and what is not; Reliability/support: incidents and responsiveness; Competitive context: alternatives and differentiators; Renewal risk: what could cause churn; Expansion triggers: what would lead to more spend. Keep it to half a page per call; discipline matters when you synthesize.
Finally, integrate interview evidence into the workstream in real time. Do not wait until the end to “summarize interviews.” As soon as you hear a repeated theme, test it against telemetry or operational data, and bring it into the issue log. Customer evidence is most valuable when it changes what you examine next: which integrations to review, which reliability metrics to request, which roadmap items to validate, and which risks to quantify.
6.2 Usage Telemetry and Adoption: The “Feature Truth” Checklist
Interviews tell you what customers believe. Telemetry tells you what customers actually do. The combination is powerful because each corrects the other’s biases. Customers often overstate adoption to support their own purchase decision or because they confuse “available” with “used.” Vendors often overstate adoption because they track superficial metrics (logins, page views) rather than workflow completion. Telemetry—when defined well—provides the feature truth.
Start by defining the product’s core workflows by segment. A workflow is a sequence of actions that produces an outcome the customer values, not a single click. For an analytics product, the workflow might be “ingest data → model metrics → publish dashboards → share to stakeholders.” For a workflow tool, it might be “create request → route approvals → execute tasks → audit outcomes.” Your telemetry review should focus on the steps in those workflows and the drop-off points where customers stall.
Next, assess the telemetry system itself, because weak telemetry can mislead. Evaluate three layers: Instrumentation: what events are captured and how consistently; Definitions: how metrics are calculated and whether definitions are stable; and Availability: whether the business uses dashboards that are trusted across product, CS, and sales. If the company cannot explain how “active user” is defined, treat the adoption story as uncertain.
Before trusting any dashboard, run a quick sanity test. Pick three accounts you discussed in interviews—one clearly successful, one average, and one at-risk—and check whether telemetry reflects that reality. If the successful account shows “no usage,” your instrumentation is missing key events or your definition is wrong. If the at-risk account shows high activity, you may be measuring workarounds rather than value. This cross-check is fast, and it prevents diligence narratives from being built on misleading metrics.
A practical way to proceed is to request a small set of standard dashboards or exports and then run a checklist against them. Your goal is not analytics perfection; it is enough fidelity to validate adoption and diagnose retention mechanisms.
- Activation: Time from contract signature to first meaningful action; distribution, not average
- Core workflow frequency: Weekly/monthly completion of the primary workflow steps
- Depth: Breadth of feature use tied to outcomes (not every feature, just outcome-enabling ones)
- Stickiness: Ratio of daily to monthly active users where applicable, or repeat usage patterns for the workflow
- Expansion signals: Growth in users, projects, volume, or connected systems within an account over time
- Drop-off points: Steps where users stall (setup, integration, configuration, publishing, sharing)
- Admin behaviors: Use of roles, permissions, audit logs, billing controls, and governance settings
- Quality signals: Error rates in workflow steps (failed imports, failed syncs, validation errors)
When telemetry exists, the fastest path to insight is cohorting. Compare accounts acquired in different periods and compare healthy accounts to churned accounts. Look for early indicators: activation within the first 30–60 days, frequency of core workflow use, and whether usage spreads beyond the initial champion. In many products, churn is visible as an adoption plateau months before renewal. If you can show that pattern, you can translate it into a post-close playbook: instrument the early indicators, build interventions, and reduce churn risk systematically.
Be careful about vanity metrics. A high login count may reflect a product that requires constant manual work, not a product that delivers value efficiently. Similarly, high feature usage can reflect complexity rather than adoption. Anchor metrics to outcomes and to customer narratives. If a customer says “we rely on automated alerts,” confirm that alerts are configured and firing. If they say “reporting drives weekly decisions,” confirm that reports are generated and shared. This is where the “feature truth” checklist becomes a triangulation tool, not just a measurement exercise.
Telemetry can also reveal hidden cost-to-serve. If many workflow actions fail due to data validation errors, that failure is often handled by support or professional services. If imports frequently fail, someone is cleaning data. If integrations frequently resync, someone is babysitting them. These are product and platform opportunities that show up as unit economics. Connect the dots: the same telemetry that indicates adoption can indicate why support burden is high.
When telemetry is missing or unreliable, you still need feature truth. Use substitutes. Support ticket taxonomy: categorize tickets by workflow step and feature area. Implementation artifacts: onboarding checklists, configuration scripts, and integration logs. CS health scoring: even if imperfect, it often correlates with adoption. Product release impact: ask for examples where a release changed adoption or reduced tickets. These substitutes are weaker than telemetry but stronger than opinions.
In your output, describe adoption with specificity and boundaries. Instead of “adoption is strong,” say “Core workflow usage is strong for Segment A, with X% of accounts completing the workflow weekly, while Segment B shows slow activation and low depth, driven by integration friction.” This level of detail is what allows an investor to underwrite the plan and to fund the right fixes.
6.3 Churn and Expansion Diagnostics: Renewal Narratives That Matter
Churn and expansion are where customer evidence becomes financial truth. Your objective is to understand not only what happened, but what was decisive. Many companies have churn reason codes that are too generic to be useful: “budget,” “no longer needed,” “moved to competitor.” Those labels often hide product and delivery issues that are fixable, as well as segment-fit issues that are structural. Diligence should rebuild the renewal narrative using evidence.
Start with a simple dataset request: a list of churned and downsized customers for the last 12–24 months with ARR at churn, segment, tenure, primary product/module, implementation model, and stated churn reason, plus renewal notes if available. Pair it with a list of expansions for the same period with ARR expansion, segment, and trigger. Even if these lists are imperfect, they create a basis for pattern detection.
Then select a small sample for deep review. A practical approach is 10–15 churn/downsells and 10–15 expansions, weighted by ARR impact. For each, build a timeline: onboarding, first value, key usage milestones, major incidents, major support escalations, major product changes adopted, renewal negotiations, and final outcome. The timeline does not need to be perfect; it needs to be consistent across accounts so you can compare.
As you review timelines, look for a few repeatable churn mechanisms. Failed onboarding: the customer never reaches stable usage. Shallow adoption: the product never becomes the system of record, often because integrations fail or workflows are incomplete. Reliability or data quality breakdown: incidents or errors undermine trust. Value mismatch: the customer expected a different outcome than the product delivers. Vendor effort fatigue: customer success and support are too involved, and the customer chooses a simpler path. Competitive displacement: a bundled suite or incumbent replaces the product when switching costs are manageable.
Expansion mechanisms are equally informative and often underutilized. Expansion tends to follow one of four paths. Seat/user growth: the workflow spreads internally. Use case expansion: the customer adopts additional modules or capabilities. Volume growth: the product is tied to business activity, driving usage-based expansion. Standardization: the customer consolidates tools and makes this product the default. Each path has product implications. Seat growth requires simple onboarding and admin controls. Use case expansion requires coherent packaging and discoverable adjacent value. Volume growth requires cost-efficient scalability and spend visibility. Standardization requires enterprise trust features and integration reliability.
In renewal diagnostics, pay special attention to “rescued” renewals. Many companies retain customers by discounting, adding free services, or promising roadmap items. Those rescues protect ARR in the short term but can destroy unit economics if they become a pattern. In diligence, treat rescues as a signal. If the renewal depended on a roadmap promise, validate feasibility and timing. If it depended on bespoke work, quantify the cost-to-serve. If it depended on a discount, assess pricing power and whether the segment is strategic.
When you present churn diagnostics, weight themes by ARR, not by logo count. Ten small churns can matter less than one large downsell driven by a platform limit. Build a rough ARR-weighted driver view: assign each churn/downsells a primary driver and sum ARR. This keeps the narrative investor-grade for the IC.
Also examine the role of implementation partners, if any. Partner-led implementations can improve scale or can create variability. If churn clusters in partner-led accounts, the issue may be partner quality rather than product fit. Conversely, if vendor-led implementations are required for success, the business may be constrained by its own services capacity. These dynamics matter to both growth and margin and should be explicit in the value-creation plan.
Translate churn and expansion findings into underwriting implications using a consistent structure. Mechanism: the primary driver by segment. Leading indicators: what you can observe early (activation delays, drop in core workflow usage, ticket spikes). Intervention levers: product or operational changes that address the mechanism. Timing: how quickly the lever could plausibly affect renewals (some changes impact next quarter; others take 12–18 months). This translation converts narrative into an actionable plan and helps the IC judge whether retention and expansion improvements are plausible within the holding period.
Where possible, quantify the “revenue at risk” tied to specific churn mechanisms. For example, if a reliability issue appears in a meaningful share of at-risk accounts, the mitigation program’s cost and timing should be compared to the ARR protected and the expansion unlocked. Even rough ranges are useful: investors can price risk and fund interventions when the linkage is clear.
6.4 Referenceable Customer Profile vs Risky Concentration
References are a double-edged tool. They can validate product value and market positioning, but they can also hide concentration risk if the “best customers” are not representative of the business. A company can have a handful of enthusiastic references while the rest of the base struggles. Your job is to assess whether the customer base is broadly referenceable in the thesis segment and whether concentration—by customer, industry, channel, or integration environment—creates hidden fragility.
Begin with the referenceable customer profile. A referenceable customer is not simply happy; they are successful in a repeatable way that the company can reproduce at scale. Define the profile in concrete terms. Segment: size, industry, and sophistication. Use case: the workflows they run. Implementation path: what it took to succeed. Adoption: who uses the product and how deeply. Outcomes: measurable benefits. Operational load: the level of ongoing vendor effort required. When a company has true fit, this profile appears repeatedly, not as a single trophy logo.
Then test representativeness. Compare reference accounts to the median customer in the target segment. Are references unusually large, unusually sophisticated, or unusually supported by bespoke work? Do they have internal teams that can absorb product complexity? Do they have unique integrations or data quality that make the product look better than it is for typical buyers? If references are exceptional, they may still be valuable evidence of what is possible, but you should not underwrite them as typical.
Concentration risk can take several forms. The most obvious is revenue concentration: a small number of customers represent a large share of ARR. Less obvious is “operational concentration,” where a small subset of customers drives most support tickets, escalations, or custom work. There is also “segment concentration,” where growth depends on a narrow vertical that may face cyclical risk or regulatory change. Finally, there is “integration concentration,” where the product’s success depends on one or two third-party platforms that could change terms or APIs.
Assess concentration with both financial and operational lenses. Ask for the top 10 and top 20 customers by ARR and their renewal dates, plus any bespoke contractual commitments (SLAs, roadmap promises, custom security terms). Then ask for support volume by account and escalation frequency to engineering. It is common to find that a few accounts create most of the operational burden. That pattern matters because it constrains scalability and can distort the roadmap toward one-off demands.
Also evaluate reference risk: what happens if you lose one or two “flagship” customers? In some markets, flagship logos serve as proof and fuel pipeline. Losing them can damage momentum beyond the direct ARR impact. If the go-to-market strategy relies on such signaling, the deal team should understand which accounts play that role and what their renewal risk is.
From a diligence perspective, concentration is not automatically bad. Some vertical leaders naturally have large accounts. The question is whether concentration is managed. Look for evidence of account plans, executive engagement, risk monitoring, and product roadmaps that avoid customer-specific forks. Also look for diversification motion: are new cohorts less concentrated, and is the company expanding into adjacent segments intentionally?
Close this section by linking referenceability and concentration to the investment plan. If the customer base is broadly referenceable in the thesis segment, that supports confidence in scalable growth and in margin expansion through productization. If referenceability is narrow and concentration is high, the plan should include specific mitigations: diversify segments, reduce bespoke commitments, productize the most common custom needs, strengthen reliability and trust features that protect strategic renewals, and build instrumentation that detects at-risk accounts early. The IC does not need a perfect customer base; it needs a clear view of where the base is durable and where it is fragile, and what the owners will do about it.
