Day 44 · Phase G

The product can sell for you — but only if it finishes all four jobs on its own

PLG vs sales-led · freemium · trial conversion · net revenue retention·4 moves · 4 diagrams
Freemium isn't a marketing tactic. It's a pricing decision — which slice of value you give away forever, and where he starts hitting a wall.
Subscription businesses split selling in two: half moves into the product and runs itself, half stays with people. The hard parts are drawing that line, and making the money still grow in year two. One move per part. One, count how many of selling's four jobs the product can finish alone. Two, cut the free tier along the axis where the better it works for him, the sooner it runs out. Three, a trial's real opponent is "no time this week," not a competitor. Four, tie the price to a unit that grows as the customer grows — because the money is in year two and year three.
MOVE 01

Don't ask "should we do PLG." Ask how many of selling's four jobs the product can finish alone. PLG doesn't delete the selling. It moves it into the product.

the four jobstime to first successuser ≠ payer
A sale always requires four things done by somebody: find out where he's stuck, get him to trust you, prove the thing actually works for him, and ask for the money. Product-led growth doesn't delete those four — it moves them into the product: onboarding does the asking, one free run does the trusting, running his own data through it does the proving, and hitting a usage wall does the asking for money. So there's only one test: with nobody holding his hand, can a stranger get one real success by himself? If he can't, PLG hasn't saved you anything — it has moved the cost from a salesperson's salary to your churn rate, and churn doesn't send you an invoice.
The dividing line isn't price — it's how complicated the decision is ↑ the user IS the one who pays ↓ procurement / legal / IT in between ← first success takes minutes weeks · integration · other people → Pure self-serve · full PLG A free tier and a usage wall do it all. No room for a rep here: one seller's annual cost takes hundreds of small subscriptions to cover. Free tier, then a human takes over He wants it, can't get it running alone. The product gives the first taste; a person moves him from interesting to in production. Usage picks who. Self-serve in, sales closes Let the actual users start free; when several accounts appear in one team, a rep goes in for the company deal — not to argue it's worth trying. Sales-led · don't force a free tier Integration, config and a security review are mandatory. A free tier here only mass-produces accounts that never ran — and you clean it up.
Checklist · who owns each of the four jobs

Write these four lines down and fill one box each: is a person doing it, or the product?

1. Find out where he's stuck | product version: the two required questions at sign-up, plus what he clicked in his first three days.

2. Get him to trust you | product version: one free run. It's the cheapest and strongest trust there is — he doesn't have to believe you, he believes what he just saw.

3. Prove it works | product version: he runs his own data through it once. Running your sample doesn't count; that only proves your sample is good.

4. Ask for the money | product version: the moment he hits the usage wall. A product asking is never awkward and never mistimes it — but it has no flexibility, which is why where you build the wall is the next move.

All four say "person" → move the easiest one into the product (usually #3). All four say "product" but conversion is bad → move one back to a person (usually #4: someone says a sentence when he hits the wall).

Why it works

Mechanism: who does those four jobs isn't set by your preference, it's set by two facts — whether the user is the person who pays, and how long a first success takes. The moment somebody your product can never touch stands in the middle (procurement, legal, the boss who signs), that stretch has to be walked by a human.

  • Unit economics — arithmetic, not research: a product at a few hundred a year can't support anyone chasing the deal; one salesperson's fully loaded annual cost takes hundreds of small subscriptions to cover. And something at six figures rarely closes fully self-serve, because the buyer's own compliance process needs a human on your side. You can check this reasoning against your own numbers without trusting anybody.
  • Industry report, self-selected sample, read as a trend only: the usual source for "more and more companies are product-led" is OpenView's annual PLG report, running since 2019. It's an investor's industry observation — self-selected sample, definitions that shift year to year, no peer review. I'm citing it to label its weight: it can tell you where things are moving; it can't be evidence that you should do the same.
  • Industry research, moderate strength: Gartner reports repeatedly that a typical B2B purchase involves 6–10 people in the decision. This kind of research doesn't publish its sampling and isn't reproducible, but the direction matches what anyone selling B2B sees: the more deciders, the less any product can close on its own — at best it convinces one of them.

A boundary: don't read this as "cheap means PLG, expensive means sales." The real divider is decision complexity; price is only its shadow. There are cheap things that are nearly impossible to self-serve (a small tool that must be wired into a legacy system) and expensive things that get bought self-serve every day (usage-billed infrastructure an engineer opens with a card).

MOVE 02

Cut the free tier along the axis where the better it works for him, the sooner it runs out Where you cut the free tier is a pricing decision, not a marketing one.

a pricing decisionthe right axisendowment effect
Freemium — a permanently free base tier plus paid upgrades — dies two ways: cut too deep and he's blocked before he ever gets one real success; cut too loosely and he never hits the wall at all. The escape isn't tuning the ratio, it's changing the axis. Don't cut by "how advanced a feature feels" — he won't miss what he doesn't use. Cut by a unit that grows as he succeeds: people using it together, things stored, messages sent, money handled. On that axis, the better it works the more certainly he hits the wall — and by the time he does, he no longer wants to move house.
Build the wall on the wrong axis and he never reaches it Cut by "how advanced it feels" Paywall: reports / permissions / SSO the one thing he actually uses how long he's used it → still enough however well it goes → free forever Cut by "a unit that grows with him" Free allowance: 3 collaborators / 500 sends hitting the wall = upgrade day how long he's used it → the better it works, the more certainly he hits it
Template · three questions that draw the line

1. Can the free tier get him one real success alone? If not, put whatever blocks him back on the free side. People who never succeeded don't upgrade, they disappear — and you never even get to ask why.

2. What will he inevitably need once he succeeds? That's where payment belongs. The test: say the sentence "you'll start paying when you ____." The blank has to take a good thing — more people, more orders, more volume. If it only takes a bad or irrelevant one (wanting to export, wanting a different theme), the axis is wrong.

3. How much of his own stuff is in there when he hits the wall? Data, settings, habits, colleagues he invited — that's the real reason to upgrade. So the free period's job isn't showing features, it's getting him to put things in; anything he could set up himself, don't set up for him.

The reverse case: if all three answers come easily and free users still don't upgrade, don't cut the free tier — most likely the thing he does in your product simply doesn't grow. That's a product problem, not a pricing one.

Why it works

Mechanism: the free period isn't marketing, it's getting him to put things into the product. Once they're in, "not upgrading" changes category in his head — it stops being "missing out on a benefit" and becomes "losing what I already have," and those two carry very different prices.

  • Hard evidence (classic, methodologically contested) · the endowment effect: Kahneman, Knetsch & Thaler (1990, Journal of Political Economy) found that people randomly given a mug asked roughly twice what people without one were willing to pay. The dispute has to be stated: Plott & Zeiler (2005, American Economic Review) showed that with improved procedure — proper practice rounds, anonymous bidding — the effect shrinks sharply or vanishes. So use it as "real, but the size depends on the setting," not as a law.
  • Hard evidence (neural, single study) · gains and losses aren't symmetric: Tom, Fox, Trepel & Poldrack (2007, Science) used fMRI to show that for equal-sized potential gains and losses, activity in the ventral striatum and ventromedial prefrontal cortex fell more steeply with losses than it rose with gains — losses weigh more inside the reward circuit. Small sample (16 people), and replication of "neural loss aversion" is contested, so treat it as a mechanistic clue rather than settled fact.
  • Several experiments, moderate effect · what you built yourself is worth more: Norton, Mochon & Ariely (2012, Journal of Consumer Psychology) — the "IKEA effect": people value objects they assembled themselves significantly above identical pre-built ones. In a product: letting a new user configure his own workflow is worth more than configuring it for him, even though doing it for him makes your onboarding numbers look better.

Where the red line runs: the same mechanism can make someone reluctant to leave a product that genuinely helps him, or simply make leaving hard. The practical test — can he export all his data in one click? If yes, your stickiness comes from value. If no, that isn't stickiness, it's a locked door. Also, the endowment effect is strongest for what he already has: cutting an existing user's allowance provokes far more backlash than a new user seeing the same small free tier.

MOVE 03

A trial's real opponent isn't a competitor. It's "no time this week." A trial converts on one real job finished — not on features seen.

empty statedefault effectcorrelation ≠ cause
In a 14-day trial, most of the people who don't convert didn't compare you with a competitor and pick them — they never started. So trial design has exactly one goal: get him to run his own real work through it in the first few days, even a small slice of it. Three levers, strongest first: one, kill the empty state — open onto a sample that's already loaded and running, not a "new project" button; two, set the defaults to the path you want him on, so he isn't re-deciding at every step; three, push one action — a five-step tour is a zero-step tour.
Churn happens before he starts, not after he compares Empty state · five-step tour sign up a blank page "when I have time" expired · never ran once Sample data · defaults · one action sign up result in 3 min swaps in his data adds a teammate renews on expiry Day 1 Day 1 Day 2–3 Day 5 Day 14 Both paths have identical features. The only difference is the first screen: an empty button, or something already running. So the trial metric isn't "how many features he tried" — it's "has he finished one real job."
Script · the day-3 trial email

Don't write: "11 days left in your trial — go explore all our features!" That email reminds him of exactly one thing: he owes you something he hasn't done, and the first reaction to owing something is avoidance.

Rewrite it as doing the work for him: "I see you imported {his real data} but haven't run your first {core action} yet. It's about five minutes: {one sentence on how}. If you're stuck on {the most common trap}, reply and I'll just set it up for you."

Why that one lands: it acknowledges what he already did, asks for one action, gives a time budget (five minutes is more credible than "go explore"), and drops the reply threshold to a sentence.

The near-expiry email shouldn't just count days: offer an extension on the condition that he tells you where he got stuck. What you get back is worth more than the deal — it's the most honest user interview available, and the people who reply are the ones most likely to pay.

Why it works

Mechanism: defaults and samples work not because people are lazy, but because every place that requires a fresh decision costs attention — and someone in a trial has no attention budget to spend. A default drops the decision cost to zero, and a sample turns "start from nothing" into "change this a bit," which is an order of magnitude easier to begin.

  • Hard evidence (classic, strong) · the default effect: Johnson & Goldstein (2003, Science) compared organ donation consent across European countries: where the default was "not enrolled, opt in if you want" (Germany, for instance) consent sat around a tenth of the population, while where the default was "enrolled, opt out if you don't" (Austria and others) it ran near 99%. Same decision, only the default changed, and the gap is close to an order of magnitude; the authors reproduced the same direction in a controlled experiment.
  • The boundary (important): the default effect is strongest when the decision is hard, the consequences are distant and the person's own motivation is low. On something he cares about and understands well, it gets small. Don't expect a default to sell him something he doesn't want — it only saves him effort at forks he was indifferent about.
  • The red line: the same mechanism can reduce friction or keep people who never noticed they stayed (auto-renew pre-ticked, cancellation buried three levels down). The test is the old one: would he feel tricked if he found out later? If yes, don't — what you make on that charge is far less than what it costs when he tells people about it.
  • One honest word about activation thresholds: the famous numbers you've read — "10 friends in 7 days," "2,000 messages" — trace back to talks and interviews, not checkable papers, and worse, they're correlations: someone who already intended to stay naturally does more of everything. Copying another company's number is meaningless. Do it properly: compare what stayers and leavers did in their first 7 days, find the pushable action with the widest separation, then A/B test whether pushing it actually raises retention. Skip that test and you're probably pushing people toward something that changes nothing.

What I'm unsure about: I've seen no clean public experiment on which categories benefit most from sample data — my basis is the mechanism and first-hand observation, not research. One thing is certain, though: the empty state is a measurable drop-off point, so go look at the bounce rate on that exact step.

MOVE 04

The money is in year two and three, so the price has to grow with the customer Net revenue retention is the only number that compounds on its own.

NRRthe billing unitstatus quo bias
NRR (net revenue retention) = what the same cohort of existing customers pays you this year ÷ what they paid last year, counting upgrades, downgrades and churn but never new logos. It's the one number that grows by itself: at 100% you tread water without new sales; at 120% revenue rises even if you never sign anyone again. The route above 100% isn't nagging customers to upgrade, it's tying the price to a unit that grows as they succeed — the same axis your free tier should be cut on. Charge a flat price per company and their growth is none of your business; charge by seats, usage or volume handled and you grow when they do.
One more deal is addition. Getting the billing unit right is multiplication. ↑ revenue from this same cohort (year 0 = 100) Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 NRR 120% → 249 by year 5 NRR 100% → still 100 NRR 90% → down to 59 Below 100%, part of every new deal is just patching the bucket. Fix the bucket, then add water.
  • Calculate your real NRR once: take last year's customer list as of this month, and divide what they paid this month by what they paid a year ago. Don't include new customers — that's self-deception.
  • Find your billing unit: write the sentence "the more successful the customer, the bigger ____ gets." If you can't fill it in, your pricing can't participate in your customer's growth and your NRR ceiling is 100%.
  • Fix the downgrade path: a customer who can downgrade doesn't churn, he shrinks. A customer whose only options are renew-or-don't disappears the moment budgets tighten. Downgrades feel bad; what they save is the whole relationship.
  • Separate two kinds of NRR: the kind built on price increases and the kind grown from usage. The first takes revenge at renewal; only the second compounds.
  • Watch the customer count alongside it: high NRR with a shrinking number of accounts means you're getting more entangled with a few big customers. That's concentration risk, not achievement.
Why it works

Mechanism one is arithmetic: NRR multiplies, it doesn't add. 90% leaves 59 after five years; 120% reaches 249 — same cohort, four times apart. Mechanism two is psychological: renewals are easier than new sales largely because not moving is the cheapest option, not because the customer loves you more.

  • Hard evidence (classic, direction well supported) · status quo bias: Samuelson & Zeckhauser (1988, Journal of Risk and Uncertainty) found that when one option in a set is labelled "the one you're already on," it gets chosen significantly more often; the authors also saw the same inertia in real retirement- and health-plan choices, and found that the more options there are, the stronger the pull to stay put. That explains two things at once: why existing customers' money really is easier to earn, and why adding tiers can freeze people in place instead of moving them up.
  • Unreliable-citation warning: "keeping a customer is 5–25× cheaper than acquiring one" is everywhere, but it doesn't trace to a checkable original study and the definition is never stated (which businesses? does expansion count?). Don't build on it. Your own books answer the question directly: the same cohort's net revenue in year two ÷ year one. That number beats any industry multiple, because it's yours.
  • The red line: status quo bias can be used to remove friction (auto-renew so he doesn't re-sign every year) or to make him forget to cancel (two steps to subscribe, five to leave). In many places that line is now a legal question, not only an ethical one. The safe version: send a reminder before the charge, with one-click cancellation in it. You lose a small slice of revenue you'd have got from forgetfulness, and you avoid the resentment that otherwise detonates all at once at renewal.

Boundaries and definitions: NRR only applies where customers can renew and expand on their own — one-off projects, perpetual licences and on-premise deployments don't fit, so don't force it. Cross-company comparison is limited too: whether downgrades count, which cohort is used, how currencies are converted all differ, so don't treat somebody's published figure as your benchmark. There's only one useful comparison: your own last quarter.

Your Day 44 Action

Two hours to land these four on whatever you're actually selling — software or not.

One (30 min) · The four-jobs table: write the four rows — find the pain, build trust, prove it works, ask for the money — and mark whether a person or the product does each today. All person → move the easiest one into the product. All product but converting badly → move one back to a person.

Two (20 min) · Find your axis: write the sentence "the more successful the customer, the bigger ____ gets." That one line decides both where the free tier gets cut and whether your price can grow with him.

Three (40 min) · Walk through as a brand-new account: sign-up to first real success, with a stopwatch. For every step over 10 minutes ask whether it can be pre-filled, sampled, or deleted outright.

Four (30 min) · Calculate real NRR: last year's customers as of this month, and what they paid this month. Under 100%, don't spend more on acquisition yet — the bucket is leaking.

A boundary: all of this assumes customers who renew and expand by themselves. If you sell one-off projects, perpetual licences or on-premise software, skip the fourth job entirely rather than forcing a metric that doesn't belong to your business model.
Think It Through
1. We sell six-figure enterprise software. Does any of this apply to us?
Yes, but not as "switch to free self-serve."

What applies is the part where the product walks one stretch of the sale by itself: build a small tool or a sandbox the actual user can run without anyone holding his hand, and let him get one success in it. The order then flips — instead of convincing the payer first and rolling it down to the users, you let the users have something to say and let them convince the payer for you. And when your rep does walk in, the conversation isn't "is this worth trying," it's "how do we roll it out."

What you shouldn't force is freemium. If your thing requires integration, configuration and a security review, a free tier only mass-produces accounts that never got running — they won't pay, and they'll tell people "I tried it, it didn't work." One test decides it: can the user, with nobody helping, get one meaningful small thing done in 30 minutes? If not, skip the free tier and run a guided pilot instead.
2. Free users never upgrade. Should we make the free tier thinner?
First separate which kind of non-upgrader, because the three need opposite treatments.

One: those who never succeeded. Cutting won't help — they aren't economising, they never got it working. A thinner tier only lowers the success rate further and turns "didn't upgrade" into "never heard of you." What they need is a shorter path to first success, not a higher wall.

Two: those using it happily who never hit the wall. That means the wall is on the wrong axis: either the thing they do in your product simply doesn't grow, or you cut by how advanced features feel and they don't want that advancement. Change the billing unit, not the ratio.

Three: those who will never pay but bring people. Accept them. Their value is carrying your name into the next company they join — they're a channel, not a cost.

And one piece of ballast: cutting the free tier is the least reversible move on the list. Taking back an allowance existing users already have provokes far more backlash than a new user seeing an identically small tier — that's loss aversion. If you must tighten, apply the new rules to new accounts only.
3. Should the trial be 14 days or 30?
That question almost always points the wrong way. The right one is: how long does one real piece of work take him, and does he have to wait on anyone or on some cycle?

For something one person can finish in a day, 14 days is already too long — the main side effect of a long trial is that nothing feels urgent, so he puts it off until the last day and then it expires without ever starting. Conversely, if he needs colleagues involved, or has to wait for a monthly cycle (a month-end close, a monthly report), 14 days can't work: the thing he'd actually use it for hasn't happened yet this month.

So the more useful version is don't count days, count whether he's completed that one run: someone moving fast should see the upgrade prompt on day 3, when the value is most vivid, not on day 14 when he's forgotten; someone stuck gets one extension in exchange for telling you where he's stuck — which is the most honest user interview you'll ever get, and the people who reply are the likeliest to pay.

If you want a starting value: 7–14 days for products that produce a result the same day, 30 for anything depending on a cycle or on several people. That's experience, not a research finding — change it once you have your own data.