Chapter 23

Paid But Doesn't Stay

The Problem Most Founders Would Love to Have

One founder I advised had the problem most of the people reading this book would trade for immediately. He could sell.

The landing page converted. Paid acquisition produced trials at a cost that made sense. Trials became customers who entered credit cards. Revenue grew fast enough that the team had, reasonably, concluded the hard part was behind them and the remaining work was to pour more into the top of the funnel. By the standards of the previous twenty-two chapters, this business had done nearly everything right. It had a buyer, a paid problem, a bounded offer, a tested price, a purchase moment that people actually reached, and a path that reliably delivered them to it.

Then the cancellations accumulated.

The team’s first response was the response nearly every team has, and I want to be fair to it because it is not stupid. If customers are leaving, replace them. New ads, new audiences, new offers, a discount on annual plans to lock people in before they could reconsider. Each of those worked in the narrow sense that more customers arrived. The revenue line kept rising for a while, which is the cruel part, because a rising revenue line is the last thing a founder wants to interrogate. The bucket simply leaked faster. Acquisition was being asked to outrun a problem it could not see, and for a few months it did, which delayed the diagnosis by exactly that long.

I include the story here, at the end of a book about getting paid, because it is the counterexample the book needs. Every earlier chapter has treated payment as the strongest evidence available, and it is. But strong is not final. Payment is the point at which the buyer’s optimism is highest and the product has delivered nothing yet. What the buyer discovers in the weeks after paying is a separate body of evidence, and a business can be excellent at producing the first kind while quietly failing the second. When that happens, the founder is holding an acquisition success and a retention failure, and the two look, from the revenue dashboard, like one thing.

This chapter is about telling them apart. It is deliberately not a retention handbook; there are good ones, and the mechanics of onboarding flows and churn cohorts are not what a book about the commercial side of an app needs to teach. What it needs to teach is diagnostic. Once somebody pays, the evidence changes category, and the questions change with it. The founder should stop asking whether the promise was sold well enough and start asking whether the customer actually reached the promised value, because the answer to the second question is what the customer will use to make the next decision, which is whether to stay.

That distinction turned out to be the whole story for the founder who could sell. What was leaking out of the bucket was not customers who had been sold badly. It was customers who had been sold accurately and then never got what they bought, for a reason that took an afternoon to find once anyone looked, and that no amount of acquisition could have fixed.

Before returning to what the afternoon found, the distinction itself needs to be made precisely, because “retention problem” is nearly as vague as “marketing problem,” and the book has spent some effort on why vague diagnoses produce confident wrong fixes.

Activation and Time to Value

We stopped looking at acquisition and reconstructed the first fourteen days after purchase.

That sounds like an obvious move and it was resisted for a while, because the acquisition dashboard was the one with good news on it and the post-purchase period had no dashboard at all. What existed were event logs, support tickets, and cancellation reasons, none of which anybody had assembled into a picture of what a new customer actually experienced between entering a card and, in too many cases, leaving. So we assembled it, more or less by hand, for a few dozen recent customers: what they did on day one, what they connected, where they stopped, when they came back, and what they said if they wrote in.

The key finding was almost embarrassingly simple, which is often how activation problems look once found. The product’s main value required the customer to connect two external systems and import historical data. The marketing, honestly and accurately, showed the result. The result was real. But a new customer could spend roughly forty minutes configuring the product before seeing anything useful, and a large percentage never completed the second integration. They paid, opened the product, hit a setup sequence that asked them to authorize systems and wait for imports, got as far as the first integration, and stalled. Some came back and tried again. Many did not. From the customer’s side, they had paid for an outcome and received a configuration task. The cancellation, when it came a few weeks later, was not a verdict on the product’s value. It was a verdict on never having reached it.

I want to draw out why this was invisible from where the team was standing. Every acquisition metric was healthy, because acquisition ended at payment and payment was working. The product, tested by the team, worked beautifully, because the team had long since done the setup and was looking at a fully configured system. Support tickets existed, but a stalled customer usually does not write in; they intend to finish setup later and then quietly decide the whole thing was more trouble than it was worth. The only place the problem was visible was in the gap between payment and first value, and nobody owned that gap, because it was after sales and before “real” usage.

This is the technical founder’s version of the bug that only reproduces in a fresh environment. The system worked for everyone who had already done the setup. The setup was the product, as far as a new customer was concerned, and nobody had run it cold in months.

The team redesigned onboarding around one objective, which I would state as the rule for any product with a setup burden: get the customer to a meaningful result before asking for the full configuration. A sample-data mode showed the outcome immediately, on the first screen, using representative data, so the customer could see what they had paid for before connecting anything. Integration setup became progressive; the first integration produced a partial but real result, and the second was requested once the customer had something to lose by stopping. And customers who stalled anyway received human help during the first week, which is expensive and, at that stage, cheaper than the churn it prevented.

Activation improved sharply. Ninety-day retention increased by more than 40 percent relative to the previous cohort. The company reduced advertising spend while recurring revenue continued to grow, which is the result that finally convinced the people who had been arguing for more ads. Within eighteen months it was operating above $1 million in annual recurring revenue. I would not attribute that entire trajectory to the onboarding change; a great deal happened in eighteen months that had nothing to do with me, and I am reporting the retention comparison because that is what we could observe directly, not because the onboarding work built the company.

The narrow lesson is about time to value. The longer the interval between payment and the first recognizable outcome, the more of the customer’s optimism is spent before the product has earned any, and the more of them will run out before they arrive. That interval is a commercial variable, not a UX detail. It sits in the offer, because the buyer is comparing what they were promised with when they get it. It sits in trust, because every minute of unrewarded setup is a minute in which “did I make a mistake” gets louder. And it sits in the economics, because a customer who cancels in week three has paid for one month of a product it cost several months of acquisition spend to sell.

The founder who could sell had a retention problem hiding behind a successful sales motion, and it was an activation problem specifically. Not every retention problem is. The next transition in the sequence fails for different reasons, and it fails for customers who did activate.

Realized Value and Continued Need

A customer who activates has reached the state in which value is possible. Whether value arrived is a separate question, and it is the one founders are least equipped to answer, because the founder’s definition of value and the customer’s are not guaranteed to match.

The founder knows what the product does. The customer knows what they wanted. When those align, realized value is the product doing what it does and the customer noticing. When they do not, the product can work perfectly and the customer can still, correctly, conclude that they did not get what they paid for. The offer chapter argued that the buyer purchases a change, not a feature set. Realized value is whether the change occurred, in the customer’s terms, and the only way to know is to ask the customer or observe their behavior, because the product’s own logs will report that it functioned.

This is where the use-case row from the Payer Delta earns a second use. A customer who bought “the platform” and needed one report has realized value if the report arrives reliably and has not if it arrives with the platform’s other capabilities cluttering the path to it. A customer who bought a time saving has realized value only if the time was actually saved, which depends on whether the output needed cleanup, whether the old process was really retired, and whether the person whose time was supposed to be saved has stopped doing it the old way in parallel, which happens more than founders expect. The question to ask a customer at thirty or sixty days is not “are you happy” but “what has changed in how you work,” and the answer either describes the change the offer promised or it does not.

Then there is the transition founders most often ignore, because it is not a product failure at all. Continued use requires a continued need. The problem has to recur often enough, at enough cost, for the customer to keep wanting the solution. A subscription assumes that. Not every problem cooperates.

A hypothetical shows the shape. Suppose a founder sells a tool that produces a specific compliance document, and it does so well. Customers activate quickly, the document is produced, and the value is realized on the first use, unambiguously. Then a large share of them cancel after two or three months, and exit surveys say they liked the product. The founder reads this as a retention problem and starts adding engagement features, reminders, and a dashboard nobody asked for. The actual issue is that the customers needed the document once a year. They bought a monthly subscription because that was what was on the pricing page, used it for the month they needed it, and left, rationally. The product did not fail. The business model was mismatched to the frequency of the need, and the churn was the customer correcting the founder’s assumption.

That is a different diagnosis from the activation failure in the previous section, and it calls for a different response. Instead of fixing onboarding, the founder should be asking how often the problem actually occurs for the customer, whether a subscription fits that rhythm, and whether an annual plan, a per-use price, or a broader offer that touches the customer more often would match the need better. The paid-problem chapter asked how often the problem happens as part of qualifying it. Retention is where a wrong answer to that question shows up, months later, disguised as churn.

There is a third failure at this stage, which is the product being valuable and not valuable enough. The customer reached the outcome, the outcome was real, and it turned out to be worth somewhat less than the subscription plus the effort of keeping the tool in their workflow. That is not a failure of activation or frequency. It is the market voting on the size of the value, and it should send the founder back to the offer and the price with a sharper question than they had before the sale: not “will someone pay for this” but “is what they got worth what they paid, in their accounting, after the novelty wore off.”

All three failures produce the same symptom, which is cancellation, and the same wrong response, which is more acquisition. They are distinguished by asking, for each departed customer, whether they reached the outcome, whether the outcome recurred, and whether the outcome was worth it. Those are three questions, and a founder who cannot answer them for the last ten cancellations is diagnosing retention the way the earlier founders in this book diagnosed sales: by symptom, with confidence, and wrong.

The customers who survive all three transitions arrive at a moment the founder has been waiting for and rarely examines: the renewal.

Retention Has Arithmetic

Retention is behavioral evidence, but it also has arithmetic. The math does not diagnose why customers leave. It tells you how expensive it is to postpone finding out.

Start with a cohort. If monthly logo churn is 8 percent, monthly retention is 92 percent. After twelve months, the fraction of the original cohort still present is:

12-month cohort retention = (1 - monthly churn)^12

At 8 percent monthly churn, 0.92^12 is about 0.368. Start with 100 customers, add nobody new, and roughly 37 of the original 100 remain a year later. That is a much more concrete description than "retention needs work."

A second rough calculation is expected customer lifetime. Under the deliberately simple assumption that the churn rate stays constant and customers are reasonably similar, the average lifetime in months is approximately:

rough lifetime in months ~= 1 / monthly logo churn

At 8 percent churn, that back-of-the-envelope lifetime is about 12.5 months. Real cohorts are rarely that tidy. New customers can behave differently from old ones, annual plans create different timing, expansion can offset contraction, and one large account can distort revenue churn. Use the approximation to notice a problem, then use cohort data to understand it.

The same caution applies to lifetime value. A common rough model uses the monthly gross profit per customer divided by monthly customer churn. If an account pays $100 a month, gross margin is 80 percent, and logo churn is 8 percent, the simple estimate is $80 / 0.08, or about $1,000 of gross-margin lifetime value before company overhead. That number is useful only if the assumptions are useful. If expansion revenue, customer sizes, or churn rates vary materially, model the cohorts instead of worshipping the shortcut.

Acquisition payback is easier to interpret. If acquiring that customer costs $600 and the monthly gross profit is $80, the rough payback period is 7.5 months. A business with a twelve-month expected relationship and a ten-month payback has very little room for onboarding cost, support, failed acquisition attempts, or ordinary forecasting error.

Churn can also neutralize a fixed acquisition engine. Suppose the company adds $2,000 of new MRR every month and loses 8 percent of existing MRR each month, with no expansion or price change. The rough equilibrium is:

steady-state MRR ~= new MRR added per month / monthly MRR churn

$2,000 / 0.08 is about $25,000 MRR. That is not a universal ceiling. The company can add more new MRR, expand customers, raise prices, or reduce churn. The calculation simply shows why a fixed acquisition machine eventually spends more and more effort replacing revenue that already leaked out.

Keep the units straight. Logo churn answers how many customers leave. MRR churn answers how much recurring revenue leaves. Gross retention and net retention answer different questions when contraction and expansion exist. Do not mix them because the formulas look similar. For an early business, you do not need a finance department. You do need one clean cohort table and enough arithmetic to know whether acquiring another customer is building the base or refilling the bucket.

A Sales Problem, a Product Problem, or Both

By the time a company has customers leaving, the diagnostic backbone from Chapter 5 has reached its final state: pays but does not stay. The chapter that introduced the Commercial Failure Diagnostic said that the same remedy can help one failure state and hurt another, and nowhere is that more expensive than here, because the remedy founders reach for at this state is the one that made the previous states better, and it makes this one worse.

The company that could sell responded to churn with acquisition, and the reason it was a mistake is structural rather than tactical. More acquisition into a product with an activation failure produces more customers who fail to activate, at a cost per customer that the shortened lifetime cannot repay. The revenue line rises, the cash line does not, and the founder is, in effect, paying to demonstrate the retention problem at larger scale. The discount on annual plans was the same mistake in a more sophisticated form: it locked customers into a year of a product they would not reach the value of, which converted a retention problem into a refund problem and a reputation problem twelve months later.

So the first discipline at this stage is to stop treating the revenue line as the health of the business and to separate the two systems it combines. The commercial motion, everything from buyer through purchase, can be strong. The product’s delivery of value, everything from activation through renewal, can be weak. Or the reverse: a product that delights every customer who reaches it, sold through a path that rarely delivers the right customer. Or both can be weak, which is common and which looks, from the top-line number, exactly like either one alone.

The way to tell is to ask a version of the question the Payer Delta asked, applied to the retained customers. Who stays, and what do they have in common? If the customers who stay are the customers the offer was built for, and the customers who leave were never a good fit, the retention problem is upstream. The sales motion is delivering the wrong buyers, and the product is correctly failing to retain them. Fix the buyer definition and the qualification, not the product. If the customers who leave are exactly the buyers the offer was built for, and they leave because they never reached the value or the value was less than promised, the problem is in the product or the offer’s honesty, and no change to acquisition will touch it. And if retained customers and churned customers look alike on every variable the record contains, the founder is missing a variable, and the next step is to interview the churned customers until the difference appears.

The economics belong in this diagnosis too, and the book has deferred them until now on purpose. A customer who stays but requires ten hours of support a month, a custom integration, and a founder on call is retained in the sense that they renew and unprofitable in every other sense. Revenue that costs more to keep than it produces is not evidence that the business works. It is evidence that the founder has found people willing to pay for a service the product does not yet deliver on its own. That can be a reasonable stage to pass through. It is not a destination, and a founder who does not know the support and implementation cost per retained customer does not know whether retention is good news.

I want to say plainly what the founder should stop doing at this stage, because it is the habit the whole book has been working against and it reappears here in a new costume. Stop blaming marketing for problems that occur after the purchase. The customer who cancels in week three because setup took forty minutes was not sold badly. The customer who leaves after the annual document was produced was not acquired through the wrong channel. The customer who renews and never expands is not a lead-quality issue. All of those are the market voting on what happened after the money moved, and the vote is about the product, the offer, the model, or the fit. Acquisition can be asked to bring different customers. It cannot be asked to make the existing ones stay.

The founder who could sell learned that lesson in the least comfortable way available, which was to discover that the sales team had done its job. Payment told us customers expected value. Retention told us whether they found enough of it to stay. Both were true, and the second one was the one the business had to fix.

Walk the Sequence

The practical exercise for this chapter takes an afternoon and requires no new software.

Write the sequence across the top of a page: payment, setup, activation, first value, repeated value, renewal. Under each, write what a customer has to do to reach it, in observable terms. Not “gets onboarded” but “connects both systems and completes the first import.” Not “sees value” but “receives the first automated report and does not also produce it by hand that month.” Then, for the customers who have paid, mark how many reached each step, as far as the record allows. Where the record does not allow it, write that down too, because a transition the founder cannot observe is a transition the founder is guessing about.

Then find the first transition that lacks evidence. Not the first one that looks weak; the first one for which the founder cannot say, with numbers or at least with names, that most customers get through. That is where the diagnosis starts. For the founder who could sell, it was the second transition, and everything downstream of it was noise generated by customers who had never really arrived. For the compliance-tool founder in the hypothetical, it was the fifth, and everything upstream was working exactly as designed. For a founder whose customers activate and realize value and then quietly stop renewing without complaint, it is probably the third or fourth, and the answer is in conversations with the people who left.

Three habits make the map useful over time rather than once. Record the reason for every cancellation in the customer’s words, tagged the way the objection chapter tagged refusals, so that churn becomes a pattern rather than a series of disappointments. Talk to churned customers with the same research framing the Payer Delta used for near-misses; they are the control group for retention, and they are usually more candid than current customers because they have nothing to lose. And put the retained-versus-churned comparison on the same calendar as the payer comparison, because the two deltas together describe what the business is: who buys, and who stays, and where those two descriptions differ.

Where they differ matters, because a business is not a collection of customers who paid. It is a system that can find, deliver to, and keep customers repeatedly, at a cost that makes continuing rational. One retained customer is stronger evidence than one transaction. Several customers, acquired through roughly the same path, delivered value in roughly the same way, and retained for roughly the same reasons, begin to resemble something that could be described, repeated, and, eventually, called a business.

Whether it can be is the last question this book asks.