Feature Gating

A paid product has to get people using it while making them reach for a card at some point. The two pull in opposite directions. Open everything and nobody upgrades; lock everything and nobody arrives.

For a long time that tension got resolved with time. A free trial opens the whole product for 30 days and closes it when the clock runs out. It's easy to build, and it fails in two places. On the last day everything a person was using stops working, which feels like having something taken back rather than never having had it. And 30 days has nothing to do with how much that person needs the product. Someone keeping private notes and a company with twenty people in a shared document see the same screen on the same date.

Pagedeck hit this directly. Ninety percent of accounts left when their trial expired, and when Grace opened the records of the accounts that left, most of them were people who had written a few documents alone. The product was closing a door on people who never had a reason to pay in the first place.

So the criterion moves from time to behavior. Not how long someone has been using it, but what they are trying to do. Everything needed to work alone stays open; the features people only reach for once they work as a team sit behind a plan. Only users who have acquired a reason to pay end up standing at the door.

1. Find the dividing line. Lay out what paying accounts did differently from departing ones in their first two weeks, and the split usually shows up in one or two behaviors. At Pagedeck, accounts that invited a colleague and edited the same document together converted at six times the rate of accounts that didn't.
2. Pick what to lock. Good candidates are features a solo user never needs and a team can't work without: permission settings, revision history, the admin console. Lock export — the feature that lets people take out data they created — and what comes back is resentment, not revenue.
3. Write the plan table. One page showing which features are open in free, team and enterprise. That table becomes both the sales sheet and the engineering spec, so name features plainly instead of describing them.
4. Decide what a locked feature looks like. Per feature, choose between hiding it entirely and showing it with a message on click. Showing it helps with the upsell, the nudge toward a higher plan, but a free screen studded with padlocks starts to read as a demo.
5. Keep the check in one place. Scatter plan checks across individual screens and adding one plan means editing ten files. This resembles a feature flag, the switch that turns a feature on and off while the code stays deployed, but a flag is something engineering hides temporarily and a gate is a boundary you sell to customers.
6. Count what happens after it ships. Track how many people hit each locked spot and what share of them went on to pay. Getting a conversion rate — the share of people who took the target action — per gate shows which doors are doing work and which are just in the way.

It fits products where user types separate cleanly. Solo users versus teams, individual contributors versus administrators — when the features each group needs differ to begin with, the line is easy to draw. The same holds when enterprise buyers ask for audit logs or single sign-on. Individual users never look for those, so locking them costs nothing.

It doesn't fit a product everyone uses the same way. If a file converter has everyone repeating one action, there is no feature worth locking. That situation calls for a usage limit, which meters quantity rather than capability.

Three limits are worth knowing. First, a free plan cut down to half a product loses people before they understand what it's for. The moment a user first grasps the value is the aha moment, and gates belong after it, never before. At Pagedeck that moment was a colleague leaving the first comment on a document.

Second, locking more features raises short-term conversion while shrinking the free user base. Free users are a referral channel in their own right, so the bill arrives about three months later as a drop in signups.

Third, a feature opened for free is hard to take back. When something people already use gets locked, customers consider canceling before they consider upgrading. Safer to decide which column a new feature belongs in before it ships.

"Let's leave this open on free and start the team plan at permission settings."

Only the features a solo user never reaches for should go behind the paywall.

"Do we hide the locked ones or show them with a message?"

Weighing upsell value against making the free screen look like a demo.

"We put the gate in front of the aha moment. It has to move back."

People are hitting the wall before they see the point, so this produces churn rather than conversion.

When Pagedeck first launched paid plans, Grace and Mia spent three days on the feature list. Following the dividing line Mia had pulled from usage records, they kept invitations and simultaneous editing free and started the lock at permission settings and revision history. Grace did propose moving document export behind payment, then withdrew it: a product that won't let people take out what they wrote doesn't survive a team's procurement review.

It's tempting to think the better the feature, the more it should be locked. Putting the valuable thing behind the counter is mostly sound advice for selling objects, so the instinct is natural. But lock the core of a product and free users never experience why it's good. What they're left with is the memory of a shell, and those people don't stop at the checkout screen on their way out. The features worth locking are not the valuable ones but the situational ones.

The other mistake is treating this as the whole of pricing. Once the plan table exists the job looks finished. But that table settles what you sell, not what it costs. The same feature split at $8 per seat per month and at $40 per seat per month produces two entirely different products. Setting the number is pricing, a separate piece of work that remains after the table is done.