Shipping a feature is not the same as users finding it. Feature discovery — how people come across functionality they aren't already using — is the quiet gap between the roadmap and the usage charts, and most products lose more value there than they realize. Pendo's 2019 Feature Adoption Report found that 80% of features in the average software product are rarely or never used, while just 12% of features generate 80% of daily usage. A lot of that unused 80% isn't bad — it's invisible. Users never discover it, so they never get the chance to adopt it.
This is a guide to closing that gap from inside the product: eight in-app tactics that improve feature discovery, how to measure whether they're working, and how to do it without turning your app into a wall of popups.
Feature discovery vs. feature adoption
The two terms get used interchangeably, but they're different stages of the same funnel, and conflating them hides where the drop-off actually happens.
- Discovery is awareness: a user encounters a feature and understands it exists. Nielsen Norman Group draws a useful line here — discoverability is when "users encounter new content or functionality that they were not aware of previously," as opposed to findability, which is locating something they already know is there.
- Adoption is behavior: the user tries the feature, gets value, and comes back to it. Pendo defines feature adoption as a measure of activation for a specific feature.
The order matters. A feature can't be adopted before it's discovered, so a low adoption rate is sometimes a discovery problem wearing an adoption costume. Before reworking a feature nobody uses, it's worth asking whether anybody has seen it at all. The tactics below target the first stage — getting the feature in front of the right user at the right moment — because that's the cheapest lever and the one teams skip most often.
1. Turn empty states into discovery surfaces
Empty states are the most-wasted real estate in most apps. A blank reports screen, an empty integrations list, a project with no members — each one is a moment where the user is already looking at the feature and waiting to be told what it does. Instead of a shrug ("No data yet"), an empty state can name the feature, explain the payoff in one line, and offer the single action that fills it.
Empty states work for discovery because they're contextual by definition: the user navigated to the feature, so the intent is already there. They just need the on-ramp.
When it backfires: an empty state that demands a five-step setup before showing any value reads as a chore, not an invitation. Keep the first action small — connect one source, add one item — and let the screen fill before asking for more.
2. Surface features with contextual hints, not a feature dump
The instinct to show everything at once — a welcome modal listing twelve features — is the fastest way to get everything ignored. People skim, dismiss, and forget. Contextual hints invert this: a small, dismissible marker appears next to a feature when the surrounding screen makes it relevant, not on login.
A hint next to a newly relevant filter, an export button, or a settings toggle teaches the feature in the exact context where it's useful. That context is what makes it stick — the user learns the feature and its use case in the same glance.
When it backfires: hints that never dismiss, or reappear on every visit, train users to tune out the whole pattern. A hint should be seen, understood, and gone — with a frequency cap so nobody sees the same one twice.
3. Announce new features where they live
Most teams announce a feature in a changelog and a launch email, then wonder why adoption is flat. The problem is location: the announcement lives where the user isn't. A changelog reaches people who go looking; an email reaches an inbox days later. Neither reaches the user inside the product, on the screen where the feature works.
In-app announcements close that distance. A short, targeted message — shown once, near the feature, to the users who'd benefit — turns a passive release note into an active discovery moment. Pair the announcement with a way to try the feature immediately, so awareness converts to a first use in the same session.
For teams that ship often, treating announcements as a repeatable change-communication motion — rather than a one-off blast — keeps discovery flowing as the product evolves.
When it backfires: announcing every minor change with equal weight. If a tooltip update and a major capability get the same modal, users learn to dismiss all of them. Reserve interruptive announcements for things genuinely worth interrupting for.
4. Walk users through complex features with an interactive tour
Some features can't be explained by a single hint — a multi-step workflow, a builder, an analytics view with several linked panels. For these, an interactive product tour outperforms a static tooltip because it shows the feature in motion: step one highlights the entry point, step two the key control, step three the payoff.
The discovery value isn't only the walkthrough itself — it's that a tour can be triggered the moment a user lands on the complex feature for the first time, converting a confusing screen into a guided one. Tours built visually, without engineering time, also stay in sync with the product as it changes.
When it backfires: auto-launching a long tour on a user who didn't ask for one. Tours land best when the user has just arrived at the feature and signaled intent — not as a mandatory gate between them and the thing they came to do. Always leave an obvious exit.
5. Use a getting-started checklist that resurfaces unused features
A checklist is usually framed as onboarding, but it doubles as a standing discovery surface. Unlike a one-time tour, a checklist persists: it sits in a corner of the app and quietly lists the high-value actions a user hasn't taken yet. As the user completes some and ignores others, the remaining items become a personalized "features you haven't tried" list.
The trick is to scope the checklist to outcomes, not chores — "Invite a teammate," "Create your first report" — so each item is a feature wrapped in a reason to use it. Tying checklists into a broader user-onboarding flow keeps early discovery deliberate instead of accidental.
When it backfires: a checklist that never goes away even after the meaningful items are done, or one padded with trivial steps to look fuller. Let it collapse or disappear once the user has reached real value.
6. Trigger discovery on behavior, not on login
The same hint shown to everyone on login is noise; shown to the right user at the right moment, it's helpful. Behavioral triggering is what separates the two. Instead of firing on session start, a discovery prompt fires when a user does something that makes a feature relevant — exports data three times (suggest scheduled exports), hits a plan limit (surface the upgrade path), finishes a project (point to the next workflow).
Behavioral triggers raise the odds that a discovery moment is welcome rather than interruptive, because it arrives in response to what the user is already trying to do. Segment-based targeting — by plan, role, or lifecycle stage — does the same on a slower clock.
When it backfires: over-triggering, where every small action spawns a prompt. A good rule is one discovery nudge per session at most, and only when the behavioral signal is strong.
7. Keep a findable changelog or "what's new"
Not every user wants to be interrupted, and the power users who drive expansion often prefer to pull information rather than have it pushed. A persistent, findable "What's new" surface — a changelog widget, a notification bell, a dedicated page — gives motivated users a place to discover features on their own schedule.
This is the low-pressure complement to the interruptive tactics above. It catches the people who dismiss modals but will happily browse a list of recent additions when they have a minute. It also gives announcements a permanent home, so a feature a user skimmed past last month is still discoverable today.
When it backfires: a changelog written for the release-notes archive — terse, internal, jargon-heavy — instead of for a customer deciding whether to care. Each entry needs a plain-language "why this matters," not just a commit summary.
8. Ask users what they can't find
The fastest way to find discovery gaps is to ask. A short in-app survey — "Did you know StepsKit could do X?" or "What were you trying to do when you got stuck?" — surfaces the features users want but never found. The answers map directly to where discovery is failing: a feature that exists, solves a real need, and still gets a "no idea that was possible" is a pure discovery problem.
Microsurveys also catch the inverse: features users found but couldn't figure out, which is a discovery success and an onboarding failure. Separating those two signals tells you whether to fix the path to a feature or the experience of it.
When it backfires: surveying constantly, or asking before a user has done enough to have an opinion. Cap the frequency, target by milestone, and keep it to one question.
How to measure feature discovery
Discovery is measurable, and the metrics sit just upstream of the adoption numbers most teams already track:
- Feature discovery rate — of users who could use a feature, what share have at least seen it (viewed the screen, dismissed the hint, opened the announcement). This isolates awareness from usage.
- Time to discover — how long after signup, on average, a user first encounters a given feature. Falling time-to-discover is the clearest sign a tactic is working.
- Discovery-to-adoption conversion — of users who discovered a feature, what share actually adopted it. A high discovery rate with low conversion points back at the feature or its onboarding, not its visibility.
- Feature adoption rate — the downstream number. Pendo's formula is straightforward: feature monthly active users divided by monthly logins. Watch it move as discovery improves.
The point of measuring discovery separately is diagnostic. When adoption is low, these metrics tell you which half of the funnel to fix — whether users aren't finding the feature, or are finding it and walking away. Pairing discovery work with a clear feature-adoption goal keeps the two stages connected instead of optimized in isolation.
Discovery without the annoyance
Every tactic here shares a failure mode: do too much of it and the product becomes hostile. A user buried in tooltips, modals, and checklists doesn't feel guided — they feel nagged, and they start dismissing everything reflexively, including the prompts that would have helped. The line between helpful and annoying is mostly about restraint, and three controls hold it:
- Frequency capping. Show each discovery moment once. A hint, tour, or announcement that reappears after it's been seen or dismissed is the single fastest way to erode trust in the whole system.
- Targeting. A discovery prompt is only welcome when it's relevant. Targeting by plan, role, page, and behavior is what keeps a nudge from reaching the 90% of users for whom it's noise.
- One thing at a time. Multiple overlapping prompts cancel each other out. At most one discovery moment per session, reserved for the highest-value action available to that user right now.
Discovery that respects attention compounds; discovery that spends it carelessly trains users to ignore the product's own guidance. The goal isn't more prompts — it's the right prompt, once, to the right person.
Putting it together
Feature discovery isn't a single feature to build; it's a set of surfaces — empty states, hints, announcements, tours, checklists, surveys — each catching users at a different moment, all governed by the same restraint. The teams that close the discovery gap don't ship more popups than everyone else. They ship fewer, better-targeted ones, and they measure the awareness step separately from the usage step so they know which one to fix.
StepsKit covers the in-app surfaces in one place: hints for contextual nudges, interactive tours for complex features, and in-app surveys to find the gaps — all targeted by plan, role, and page, all frequency-capped, and all installed from a single script tag. The pricing page has the details. Whatever tooling you use, the principle holds: ship the feature, then make sure the right users actually find it.