Progressive disclosure: You hid your own upgrade path

Two products can present exactly the same simplified first screen and be doing opposite things.

In the first, the advanced capability is deferred: it is out of the way now, and it appears when the user’s situation calls for it. In the second, it is hidden: it is behind a menu, and the only route to it is knowing what it is called.

Both teams believe they built the first, and both can believe it sincerely, because nothing in either process forces the comparison. The way to tell is to ask how a user who has never heard of the feature would reach it.

The trap: disclosure and pricing are the same decision, made twice

Progressive disclosure means revealing a product’s depth in step with a user’s need for it, so a beginner is not confronted with an expert’s interface and an expert is not stuck with a beginner’s. It comes from usability research, not from growth: Jakob Nielsen has written on it under that name since at least 2006, and it descends from John Carroll’s “training wheels” experiments at IBM in the 1980s, which tested a deliberately restricted word processor against the full product and found that novices given less interface learned the task faster and made fewer errors.¹

What is specific to product-led growth is that the principle collides with how you make money, and a hidden feature has two effects where teams plan for one. It stops overwhelming new users, which is the point. It also stops existing users discovering the thing you were hoping they would eventually pay for. That collision is a decision nobody remembers making.

Two groups make it independently, and comparing notes is not part of either process.

Product decides which features to keep out of a new user’s way. Pricing decides which features sit behind a paid tier. Both, quite reasonably, pick the advanced ones. So the capability you are counting on to drive upgrades is also the capability nobody is shown, and the paywall you built is one few users reach.

The symptom is a familiar and confusing pair of numbers: healthy activation, and an upgrade rate that will not move no matter what you do to the pricing page. Nothing is wrong with the pricing. The users simply never learned that the thing they would pay for exists.

The design exercise that comes out of this is small enough to do on a whiteboard: complete the sentence “when a user struggles with X, reveal Y” for every advanced capability you have. Repeatedly copying elements is the moment to mention components. Manually aligning things is when layout tools earn their place. If you cannot name the struggle, you do not yet know when to reveal the feature, and it will end up in a menu.

This is the point at which progressive disclosure stops being a design concern and becomes the mechanism behind upgrade triggers: the reveal and the offer should be the same moment.

What does deferring properly look like?

The distinction is whether the product notices. Five routes in, roughly in order of how well they work:

The situation reveals it. The user does something that makes the capability relevant, and it appears there, in context, described by what it does, not what it is called. Someone pasting a fourth near-identical row is the moment to mention templates. This is the strongest version and the most work, because it requires knowing which situations matter.

The product asks. A short prompt at a genuine decision point, once. Cheap, effective, and easy to overdo until it becomes the interruption it was meant to prevent.

Search that understands intent. If someone types “make this repeat every week” they should find the automation feature, whatever it is called internally. Search keyed to feature names, not user language, is a quiet failure worth checking, because it looks like discoverability and functions like a locked door.

Working examples that already use it. The most underrated route, because it inverts the problem: instead of explaining a capability, hand the user an artifact that is already built with it. A template containing a formula teaches the formula, and the user learns what is possible by opening something, not by being told. This is why a template library is a feature-discovery system and not only a time-saver, and it is why the artifacts your users publish end up doing your product education for you.

A visible seam. An “advanced” section that is plainly there, not hidden, just not in the way. The weakest of the five and still better than nothing, because it tells the user depth exists and where it lives.

Two kinds of signal can fire any of them, and the second is the one that goes unwired. Individual behavior is what one person just did. Account-level change is the team growing, a second department arriving, the workspace crossing a size where coordination starts to matter. Features that only make sense for a group should wait for the group, and appear when it forms, not when any one member happens to click something.

What none of these do is depend on the user already knowing the vocabulary. The test for any reveal mechanism is whether it works for someone who cannot name what they want.

The late failure: never graduating anyone

Deferral has to end at some point. A user who has been with you for a year and still sees the beginner interface is being actively slowed down, and they will notice it as the product being simplistic rather than as a setting they have not changed.

Two things go wrong at that end.

Nothing ever escalates. The reveal logic runs during onboarding and then stops, so competence accumulates and the interface does not. The fix is to treat depth as something with a ratchet: once someone has demonstrated they can handle a capability, it stays available.

Everything escalates at once. The opposite failure, where hitting some threshold unlocks a wall of new controls in a single week. Depth revealed in a lump is the same overwhelm you were avoiding, arriving later.

The useful frame is that a product should get more capable as someone uses it, and that this is the same accumulation logic as everything else that makes leaving expensive: a customer three years in should be operating a product a newcomer would not recognize.

When the depth is the whole point

The pattern needs a product with somewhere to go. If yours does one thing, there is nothing to defer and nothing to reveal. If every user is already an expert, deferring is just an extra click for all of them. If the advanced parts are the value, hiding them hides the reason anyone would pay. And if nothing in usage distinguishes a novice from an expert, you have no signal to reveal on, which turns disclosure into guessing.

The products usually cited here are flexible tools with real depth (Notion, Coda, Airtable), design software serving both professionals and everyone else, developer and project tooling, and analytics used by engineers and executives alike.

There is also a more ambitious version of the same idea, worth naming because it changes the market rather than the interface. Simplifying the entry point enough can admit people who could not previously use the category at all: editing video by editing a transcript brings in writers who would never learn a timeline. Deferral protects novices; a genuinely simpler entry point creates customers.

Where the value sits disqualifies most of the products that think they need this. If your differentiator is the sophisticated capability, hiding it means hiding the reason to choose you, and the correct answer is to make that capability legible rather than deferred.

Finding what is buried

1. What share of accounts have ever used each advanced feature, split by tenure? A feature that stays near zero at every tenure is not deferred, it is buried. This is the single most useful table on the topic and it takes an afternoon to build.
2. How long between signup and first use of each capability? Rising over time is fine. Flat and very long means discovery is broken, not paced.
3. Do users who reach an advanced feature retain and expand better? If they do, discovery is a growth lever, not a UX nicety, and it should be resourced accordingly.
4. What do people search for that returns nothing? Your empty-result queries are a list of things users want in their own words. It is the cheapest feature-naming research available and few read it.

Fix the cross-check first

1. Run the two-list cross-check from the callout above. If anything appears on both lists, that is the highest-value fix on this page and probably in the section.
2. Pick your most-hidden paid feature and give it a contextual route in, triggered by something in the user’s own work rather than by a tour.
3. Read a week of failed searches. Then make three of those phrasings find the right thing.
4. Add a ratchet. Once a user has used a capability, stop hiding it. Some products re-simplify after every release.
5. Check your oldest accounts are not still on the beginner interface. If they are, the reveal logic stopped running the day onboarding ended.

Revealing depth grows a user into the product. There is a limit to how much depth any one company can build, and past a certain point the useful move is to stop building it: let other people extend the product instead, and let customers assemble something you could never have shipped. A marketplace is the last and most demanding pattern in this section, and the hardest to start.

Updated August 2026