Retention and expansion

# Retention and expansion

## Goal

Design how the company keeps a beachhead customer after first value, and when it may ask for more money or a broader job. Retention is continued use or renewal at the product’s natural cadence. Expansion is a new job, volume, or seat that the customer actually takes, not a hoped-for land-and-expand slide.

This is operating design. Do not message customers or invent LTV. Do not treat a single renewal as a retention system.

Complete the analysis autonomously. Do not stop to ask clarifying questions. When evidence is missing, define the observation window and return `HOLD` on claims that need more time.

Do not modify application code.

## Prerequisites

Read the latest ICP (especially retention mechanisms and expansion paths), pricing, onboarding, billing, usage, cancellation, support, and founder-labor records; and any existing `docs/gtm/retention.md`, `docs/gtm/retention.yaml`, and `docs/gtm/retention-changelog.md`.

If activation is undefined, return `REVISIT ONBOARDING`. You cannot retain what you cannot see start.

If ICP v1.0 does not exist, treat long-term retention and LTV as `UNKNOWN`. You may still design the system.

## Evidence standard

Use the shared GTM labels.

Login is not retention. A multi-year contract prepaid is not usage. A champion who likes you is not renewal. Expansion revenue from a one-off services SOW is not product expansion.

Measure at the product’s natural cadence. Weekly tools are not judged on annual logos alone.

Separate: continued usage, contractual renewal, expansion, contraction, churn reason, cost to retain, founder labor to save the account.

## Step 1: Define the cadence and the retained unit

State:

* what a retained customer is
* the observation window
* whether the product is event-driven (value may pause between triggers)
* the unit: account, seat, workflow volume

For event-driven products, do not call quiet periods churn without checking whether the trigger disappeared.

## Step 2: Map why people stay or leave

From repository evidence, list mechanisms that would cause continued use: recurring job, switching cost, embedded workflow, reporting someone needs, budget cycle.

List churn hypotheses: no second job, champion left, value was a one-time cleanup, support burden, price, product gaps, bad-fit sale.

If customers exist, attribute each continuation and each loss. If not, label the map `INFERRED`.

## Step 3: Renewal motion

Write the renewal play:

* who owns it
* when it starts relative to term or usage fade
* evidence reviewed (usage, value metric, support burden, unpaid invoices)
* save offers that do not silently break the pricing floor
* when not to save: RED fit, unprofitable support, product cannot do the job

A discount to hide a failed product is not retention.

## Step 4: Expansion rules

Use only expansion paths the ICP already named, or new ones with evidence.

Each path:

* new job or volume
* buyer
* package or price
* prerequisites
* whether it distorts the roadmap
* whether it attracts YELLOW/RED work

Do not invent a platform upsell because other companies have one.

Cross-sell requires a second job the product actually performs today.

## Step 5: LTV as a derived range, not a slogan

If data exists, calculate a low / base / high LTV from observed retention, expansion, and cost to serve. Show the formula. Include founder labor.

If data does not exist, do not publish an LTV. Record the missing inputs.

Never compute LTV from a single happy account.

## Step 6: Desk-test

1. Retention is defined at the right cadence.
2. Event-driven quiet is not automatically churn.
3. Expansion cannot sell a product that does not exist.
4. Save motions cannot violate the pricing floor without a named subsidy.
5. LTV is `UNKNOWN` or derived, never invented.
6. Bad-fit customers are allowed to leave.

## Decision

* `INSTALL`: retention and allowed expansion plays may be used
* `INSTALL NARROWLY`: usage watch and renewal only, no expansion
* `HOLD`
* `REVISIT ONBOARDING` or `REVISIT ICP`

Lead with:

“As of [date], a [beachhead] customer is retained when [definition] over [cadence]; expansion is [allowed paths or none]; LTV is [range or unknown]; decision [INSTALL / INSTALL NARROWLY / HOLD / REVISIT ONBOARDING / REVISIT ICP].”

## Deliverables

### 1. `docs/gtm/retention.md`

Definitions, stay/leave map, renewal play, expansion paths, LTV math or unknown, desk tests.

### 2. `docs/gtm/retention.yaml`

`version`, `status`, `decision`, `retained_unit`, `cadence`, `mechanisms`, `churn_hypotheses`, `renewal`, `expansion_paths`, `ltv`, `assumptions`, `unknowns`, `sources`.

### 3. `docs/gtm/retention-changelog.md`

Append only.

## Boundaries

* Do not invent retention rates, NRR, or LTV.
* Do not message customers.
* Do not treat prepaid contracts as proof of ongoing value.
* Do not expand into RED work to grow an account.
* Do not save every logo.
* Preserve uncertainty.

## Done when

* Retention, cadence, renewal, and allowed expansion are explicit.
* LTV is calculated or honestly unknown.
* Desk tests passed or forced `HOLD`.
* The three files agree.