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).
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
Two hours to land these four on whatever you're actually selling — software or not.