Unit economics are often presented as finance outputs—ARR, gross margin, CAC payback, NRR—but in software those metrics are downstream of product and technology. What customers buy, how quickly they reach value, how reliably the system runs, and how much human effort is required to keep accounts successful all show up as “economics.” P&TD adds value by making those linkages explicit so the deal team can separate structural constraints from fixable execution gaps.
4.1 Revenue Model Map: SaaS, Usage-based, Hybrid, Services Attach
The revenue model is a system, not a price list. From a diligence standpoint, you want a “revenue model map” that answers four questions: what the customer pays for, how the product measures and enforces that purchase, what the company must do operationally to deliver it, and where the model tends to break (leakage, disputes, discounting, churn). This map is the bridge between product/tech reality and unit economics.
Start with the simplest classification, then immediately push into mechanics. Many targets describe themselves as “SaaS,” but their actual commercial engine may include meaningful usage components or a large services footprint. Those differences change the risk profile and which product/tech capabilities are underwriting-critical.
- Subscription SaaS: Recurring access fee, often per seat, per account, or per module; renewals depend on adoption and perceived indispensability.
- Usage-based: Variable billing tied to consumption; success depends on accurate metering, customer spend predictability, and cost alignment.
- Hybrid: A base subscription plus usage add-ons; success depends on clarity and in-product controls that prevent surprises.
- Services attach: Implementation or managed services sold alongside software; success depends on repeatability and declining effort per dollar of ARR.
For subscription SaaS, the key product/tech diligence topics are packaging and entitlements. Packaging: Are packages truly differentiated by segment or use case, or are they a collection of one-off features created to close deals? Packaging sprawl drives operational exceptions and support burden. Entitlements: How does the product enforce what a customer bought (features, limits, roles, environments, support tiers)? Manual entitlements—managed by support tickets, spreadsheets, or custom flags—are a common source of margin drag and inconsistent customer experiences.
For usage-based models, focus on the metering-to-cash pipeline. Metering definition: Are billable events unambiguous, stable, and tied to customer value? Metering capture: Is event capture reliable under load and failure conditions, or can usage be lost? Reconciliation: Does the company reconcile meter data to invoices and investigate anomalies? If not, expect disputes, revenue leakage, and conservative revenue planning. Usage models also expose cost structure. If delivering a billable unit consumes meaningful cloud resources or third-party fees, margin can compress as volume scales unless the platform is designed for efficiency.
Hybrid models add an adoption and trust requirement: customers must understand what drives their bill. Spend visibility: Do customers have in-product dashboards, alerts, and admin controls that let them monitor and manage usage? Without these, “bill shock” becomes a churn driver, and customer success labor expands to explain invoices and negotiate exceptions.
Services attach needs a sober view because it can inflate reported “software” economics while hiding recurring labor. Treat services as one of two things: a profitable, time-bounded implementation phase, or a structural dependency required for value delivery. The second case often shows up as engineering involvement in implementations, recurring “free” work buried in COGS, and customer environments that rely on bespoke integrations or configurations. Your diligence goal is to separate what is productizable from what will remain a labor tax.
Build the revenue model map using a small set of components rather than a long narrative. For each major revenue component, capture: Value metric: what the customer is paying for; Product requirements: what must exist in the product for the model to work; Operational requirements: what must happen in delivery/ops; and Common failure mode: the most likely way economics degrade. Keep it short enough that the deal team can use it in discussions about pricing power, margin, and value creation.
To validate the map quickly, run a small set of “revenue mechanics” checks. The objective is to confirm that what is sold can be delivered repeatedly without hidden labor or leakage.
- Contract-to-entitlement consistency: Do contract terms and order forms map cleanly to product entitlements, or do exceptions require manual handling?
- Discounting pattern: Are discounts concentrated in specific segments or tied to specific product/tech gaps (security reviews, integrations, reliability concerns)?
- Billing accuracy and disputes: How often do invoices get challenged, credited, or reissued, and what are the root causes?
- Unit cost visibility: Can the company attribute major cost drivers (cloud, third-party APIs, support) to products or high-usage customers?
- Services dependence: What percentage of new deals require paid services, and what percentage require “free” effort to reach go-live?
Ask for a small evidence set that is usually available even in tight timelines: a handful of recent order forms across tiers, a sample invoice and usage report (for usage models), a list of top discounts with stated reasons, and a simple view of cloud spend by service category. You are not auditing revenue recognition; you are testing whether the revenue model is operationally executable and whether economics degrade through exceptions.
Then translate the map into underwriting implications. Two translations matter most. First, identify where the revenue model is sensitive to product adoption. Per-seat models live and die on activation, onboarding, and sustained usage. Second, identify where the revenue model is sensitive to platform cost and reliability. Usage and integration-heavy products are often more variable-cost intensive and require strong observability to prevent support costs from scaling linearly with growth. If the thesis depends on margin expansion, make sure the platform has the technical prerequisites for variable cost control (cost attribution, capacity management, and a credible FinOps loop).
Close the loop by identifying the “deal compression points”—the places where revenue mechanics create sales friction or renewal friction. These often show up as repeated security addenda, bespoke SLAs, custom reporting promises, or discounts tied to delivery concerns. In P&TD terms, these are not merely commercial facts; they are product and technology work items that can improve win rates, shorten cycles, and reduce discounting if addressed systematically.
4.2 Retention Mechanics: Where Product and Delivery Actually Drive Churn
Retention is usually the largest driver of value in software, and it is the area where “why” matters more than “what.” A headline churn number tells you the outcome, not the mechanism. P&TD’s job is to surface the mechanism: how product value realization, onboarding experience, integration reliability, platform stability, and trust signals combine to produce renewals, downsells, expansions, or churn.
Start by separating the retention measures you will reference in the investment narrative. Logo retention: whether customers renew at all. Gross revenue retention: how much revenue remains after churn and downsells. Net revenue retention: GRR plus expansions. Usage retention: whether customers continue to use the product’s core workflows over time. These measures often diverge, and divergence is information. If usage declines before renewal, you have an early-warning signal. If customers renew while usage is thin, you may be seeing inertia rather than durable value.
Next, build a practical “retention chain” that you can test with evidence. A simple chain is: customers must reach value, adopt the core workflow, embed the product in operations (often through integrations and governance), experience consistent performance and reliability, and trust the vendor on security and data. Breaks in the chain look like churn causes later, but they are usually visible earlier as onboarding delays, low depth of adoption, repeated incidents, or recurring support escalations.
Triangulate retention mechanics using three evidence types. Customer narrative: what customers say about outcomes, friction, and alternatives. Behavioral evidence: telemetry showing activation, frequency, and depth of core workflow usage. Operational evidence: incidents, escalations, and support patterns that reveal fragility and hidden labor.
Customer interviews are most valuable when you avoid the “renewal script.” Ask for concrete moments. Value moment: when did the product first feel indispensable? Friction moment: what nearly derailed adoption? Workarounds: what do they still do outside the product because it is easier or more reliable? These questions uncover product and delivery issues that are often missing from churn reason codes.
Telemetry is powerful when it is tied to outcomes rather than clicks. Define the core workflow for each segment and measure: time-to-first-core-action, repetition frequency, breadth of feature adoption that supports the outcome, and whether usage expands to additional teams or use cases. If telemetry is weak or definitions are inconsistent, treat that as a diligence finding: the company will struggle to run a data-driven retention and expansion program post-close.
Operational evidence often explains “mysterious” churn. If support ticket volume increases in the months before churn, or if a customer experiences repeated incidents, renewal outcomes are rarely independent of those events. Look for patterns like: frequent escalations to engineering, repeated integration failures, performance complaints during peak periods, or long-running data quality issues. Even a small sample—top churn accounts and top expansion accounts—can reveal the difference between accounts that are self-sufficient and accounts that require constant vendor intervention.
A high-yield diagnostic is to compare churned accounts to expanded accounts in the same segment and ask what is different in their product journey. Expanded accounts usually show faster activation, broader workflow adoption, fewer severe operational disruptions, and clearer internal ownership on the customer side. If the target cannot provide this comparison, build it manually from a small sample: pick 5 churns and 5 expansions, review their timelines, and look for repeatable patterns.
Capture those patterns in a concise “retention mechanism” template so the findings convert cleanly into the risk register and value-creation backlog.
Mechanism | Evidence signal | Typical root cause | Actionable lever |
Slow activation | Long time-to-first-core-action; onboarding drop-off | Complex setup, weak guidance, integration friction | Guided onboarding, better defaults, validation tooling |
Shallow adoption | Low active-user ratios; narrow feature use | Workflow mismatch, missing reporting, unclear outcomes | Workflow improvements, in-product education, packaging alignment |
Reliability-driven dissatisfaction | Incidents correlate with downgrades or renew pressure | Capacity limits, weak observability, brittle dependencies | Reliability program, SLOs, dependency hardening |
Trust or governance friction | Security review delays; audit log gaps | Incomplete IAM/auditability features | SSO/SCIM/audit logs, security control uplift |
In P&TD, avoid generic churn categories and build an actionable taxonomy tied to product/tech levers. Examples include: onboarding delays due to data migration tooling gaps; missing or brittle integration with a common system; unreliable core workflow due to architecture constraints; insufficient admin controls and audit logs for enterprise governance; poor in-product guidance causing shallow adoption. Each category should map to a remediation or value-creation initiative with an owner and an expected impact pathway.
Finally, be explicit about which retention issues are structural versus fixable. Structural issues include segment-product mismatch (e.g., an SMB motion for a product that requires enterprise-grade implementation) and a revenue model misaligned to deliver value. Fixable issues include reliability improvements, targeted onboarding redesign, instrumentation upgrades, and integration productization. Investors do not need perfection; they need to know what can plausibly improve within 12–18 months and what will remain a constraint even with investment.
When you summarize retention in the diligence narrative, use a consistent translation: Mechanism: the leading drivers by segment; Evidence: the artifacts and examples that support the view; Implication: how retention might evolve under base and downside cases; and Levers: the specific product and technology initiatives most likely to move the metric, with realistic timing.
4.3 Implementation and Time-to-value: The Hidden Margin and Growth Killer
Implementation and time-to-value often determine whether a software company can scale with attractive economics. Long onboarding cycles reduce win rates, slow revenue realization, consume professional services capacity, and delay the moment when customers experience value strongly enough to renew and expand. Many businesses look healthy on ARR growth while quietly accumulating a delivery and support burden that will cap margin expansion later. P&TD should treat this as an underwriting topic, not an operational afterthought.
Define time-to-value in measurable terms and insist on segment cuts. Implementation time: signature to go-live (or to a defined onboarding milestone). Time-to-first-value: signature to the first meaningful outcome. Time-to-full-value: the point when the core workflow is used reliably at steady state. These measures matter differently by segment: SMB often lives on time-to-first-value, while enterprise is constrained by implementation predictability and risk.
Decompose implementation into stages so you can locate the bottleneck rather than blaming the whole journey. A useful decomposition is: setup and access (provisioning, SSO, permissions), data migration and configuration, integrations, workflow testing and exceptions, training and change management, and stabilization after go-live. For each stage, ask: what is inherently customer-specific, and what is vendor-created friction that could be reduced through product and platform work?
Quantify burden using operational proxies even when perfect data is missing. Ask for implementation duration distributions (not just averages), PS hours per implementation, number of stakeholders involved, and the top reasons projects slip. Then triangulate with customer interviews and support escalation categories. If the company cannot provide basic visibility into these drivers, treat it as a risk: they may not understand their own cost-to-serve, making margin ramp assumptions fragile.
When you evaluate implementation, avoid relying on a single “average days to go-live.” Averages hide the projects that consume disproportionate effort. Ask for the spread and for the drivers of the long tail. A simple way to structure this is to request a small implementation roster (10–20 recent projects) with a few fields: segment, start date, go-live date, integration count, data migration complexity, PS hours, engineering involvement, and whether the customer is healthy after 90 days. This lightweight dataset is often enough to show whether slow onboarding is driven by a few outliers or by structural friction that affects most deals.
Also examine the commercial packaging around implementation. If “standard implementation” is vague and routinely expands in scope, services will behave like a loss leader and margin will be hard to scale. If implementation is standardized and priced to reflect effort, services can be healthy while the product matures. The difference is rarely in intent; it is in repeatable tooling, clear boundaries, and a product roadmap that reduces effort over time.
Common product/tech drivers of long implementations recur across deals. Configuration complexity: setup requires expert-only rule building or scripting. Data model mismatch: customers must reshape data to fit rigid schemas, causing repeated failures and ongoing quality issues. Integration pain: APIs and connectors are hard to build and hard to debug; error handling is weak; sandbox environments are missing. Enterprise governance gaps: SSO/SCIM, audit logs, role controls, and security review requirements are addressed through one-offs rather than productized capabilities. Operational immaturity: unreliable deployments and weak observability turn onboarding into firefighting.
Time-to-value problems often persist after go-live as “recurring onboarding.” Customers continue to depend on the vendor for routine operations—fixing data, monitoring integrations, managing permissions, producing reports—because the product does not support self-sufficiency. That dependence shows up as support ticket concentration, frequent engineering escalations, and renewal negotiations that include stabilization requests. From a unit economics perspective, recurring onboarding is one of the clearest signs that gross margin expansion will require productization, not just staffing changes.
Value creation levers should be framed in a way that connects directly to growth efficiency. Product levers include guided onboarding, better defaults, validation and previews that prevent misconfiguration, in-app education, and admin tooling. Platform levers include hardened integration patterns, customer-facing observability, and data pipeline robustness. Delivery levers include standardized playbooks, reusable templates, and clear segmentation of implementation offers (what is standard versus premium). Measurement levers include instrumenting time-to-first-value, tracking onboarding drop-off points, and linking early adoption to renewal outcomes.
When you size these levers, keep the translation practical. If implementation time drops, how many additional implementations can the same team deliver per quarter? If post-go-live support drops, what does that imply for support headcount growth and margin? If time-to-first-value improves, what uplift is plausible in activation and early retention? Your estimates can be ranges, but they must be explicit enough to influence the investment plan and the first-year operating agenda.
4.4 Cohorts And Segmentation: What to Slice Before You Conclude Anything
Blended metrics can hide the truth of a software business because different customer groups experience different products. They buy different packages, require different integrations, have different governance requirements, and impose different cost-to-serve. P&TD should insist on segmentation that reflects real differences in product experience and platform load so the deal team does not underwrite a fantasy average.
Start with the few cuts most likely to change conclusions. Size/complexity: SMB versus enterprise is often the largest driver of onboarding effort and retention mechanics. Industry/regulation: regulated segments often impose a security and auditability “entry fee” that changes sales cycle and retention risk. Use case: distinct workflows within the same product can have different adoption patterns and different failure modes. Tier and module mix: what customers bought shapes both value and expectations. Implementation path: self-serve, partner-led, or vendor PS changes both margin and time-to-value. Region/deployment: multi-region needs, data residency, or on-prem components change operational risk and cost.
Add cohort analysis to see whether the business is improving over time. A simple approach is to compare customers acquired in the last 12 months, 12–24 months, and 24+ months, and to add boundaries around major product or go-to-market changes. Look for shifts in activation speed, support burden, and retention. Improving cohorts can validate that productization is working; deteriorating cohorts can signal that acquisition quality or onboarding capacity is eroding.
Some of the most predictive slices are operational rather than demographic. Slicing by integration count (none, 1–2, many), by usage intensity (low/medium/high), or by customization footprint often explains both support burden and retention. Similarly, slicing by “go-live path” (self-serve, partner-led, vendor-led) can reveal whether economics depends on scarce expert capacity. These cuts are especially useful when the company’s segment labels are noisy or inconsistently applied.
Include cost-to-serve in your slicing, even if the company does not track it cleanly. Use proxies: support tickets per account, PS hours, number of integrations, usage volume, and frequency of escalations to engineering. Two accounts with similar ARR can have radically different economics if one is self-sufficient and the other requires constant intervention. Identifying margin-dilutive slices early helps the value-creation plan target the right fixes: productization, packaging changes, or segment focus.
Before you conclude “the product is weak” or “the product is strong,” test for selection effects. A segment acquired through heavy discounting or a low-fit channel may churn for reasons unrelated to product quality. Conversely, a segment that is sticky because it is deeply customized may look healthy while accumulating operational debt and limiting scalable growth. Your goal is to separate durable value from inertia, because they imply different competitive risk and different investment needs.
Use a short sanity checklist before final conclusions:
- Definitions: Are segments defined by observable attributes (size, industry, tier) and applied consistently?
- Behavior: Do segments show meaningfully different adoption and support patterns?
- Economics: Do segments differ in discounting, services effort, or cost-to-serve proxies?
- Drivers: Can you link differences to product and technology causes, not just generic explanations?
Close the loop by tying segmentation back to the deal model and the operating plan. State which segments drive returns under the current product and platform, which segments are constrained by onboarding or trust gaps, and what product/technology investments would shift the mix. This translation is where P&TD helps investors avoid a common post-close surprise: discovering that growth is concentrated in the segment that is least scalable. If you surface that early, the investor can price it, fund the right initiatives, and set realistic expectations for the margin and growth trajectory.
