Low Feature Usage: Is Promotion the Right Response?

Low feature usage can make promotion look like the obvious next step. The feature exists, people aren’t using it, and an announcement or onboarding message offers something concrete to try. But low use doesn’t tell us whether another message would help.

My starting question would be who the feature is useful to, and what is stopping those people from using it. That leaves room for promotion, but also for a product fix or a decision to leave a useful, specialised feature alone.

PostHog’s 15 October announcement brought this question into focus. Its new scout looks for underused features and suggests possible reasons. The published instructions already consider access, tracking problems and actions that are meant to be rare. Those distinctions matter because each can change where product effort belongs.

A feature can serve only part of a product’s audience. Its use across the whole customer base may look low even when it works well for the people it was built to help. Including people whose plan or permissions exclude it makes that overall figure less useful for deciding whether to promote it.

The smaller audience still needs to make sense. Defining it as the people who already use the feature would explain away every adoption problem. The useful reference is the work the feature was meant to help with, including people doing that work who haven’t adopted it.

Promotion has a clearer purpose when there is evidence of an unmet need for something the product already does. Requests for an existing capability, or difficulty finding it in the relevant workflow, give a team a reason to improve discovery. The response could be a better entry point or a timely explanation. A broad announcement is only one option.

The useful follow-up is whether more of the intended users can now complete the work. Extra visits can help explain what changed, but they leave open whether the feature helped anyone.

Sometimes the obstacle sits inside the feature. People can know it exists and still find that it doesn’t do enough for them. Intercom described this in its 2023 account of developing its ticketing product. The team distinguished customers with simpler, ad-hoc needs from those with established support processes and more demanding requirements. It wanted to serve the latter, but its ticketing capabilities were falling short.

Intercom explained that increasing adoption among the easier-to-serve group could distract from those missing capabilities. It continued tracking adoption while concentrating on whether the product met its intended customers’ needs. Improving onboarding would not supply the capabilities those customers needed to do their work.

That choice is relevant well beyond ticketing. A campaign and a product improvement can both increase usage, while addressing very different problems. Evidence that people cannot find a useful capability supports one investment. Evidence that they find it but cannot complete their work supports another.

There is a quieter outcome worth considering too: the feature may already be doing enough. A small group completing a valuable task does not necessarily justify a campaign to attract everyone else. Nor does a task performed occasionally need to become frequent to earn its place.

I would be comfortable leaving a feature’s usage low when its intended users get a worthwhile result and the maintenance and support costs remain reasonable. The case for promotion becomes stronger when we can name the people it would help and explain how reaching them would improve their work.

That gives the next adoption review a practical question: Who would this promotion help, and what is stopping them from using the feature today?