Tied to retention
See which features the accounts that renew actually use — the ones worth putting in onboarding.
Feature usage
You shipped it. Did it survive contact with users?
Adoption, depth of use and drop-off for every feature you ship — so the roadmap argument has evidence in it instead of the loudest opinion in the room. No tracking plan, no dashboard per feature.
- No new instrumentation
- One call to name a feature
- Replaces Pendo and Amplitude
Also included
Per segment
Adoption by plan, cohort or campaign, so "nobody uses it" can be checked against "nobody on the free plan uses it".
Feature lifecycle
New, adopted, plateaued or dying — inferred from the curve rather than from a label somebody has to maintain.
Evidence for the review
Every number opens the sessions behind it, so the planning argument has recordings in it.
Thermal · feature adoptionWeekly reach · 12 weeksMax 62%Min 1%
DashboardsShipped Q192%
Saved viewsShipped Q184%
AlertsShipped Q268%
FunnelsShipped Q249%
CohortsShipped Q334%
AnnotationsShipped Q25%
Scheduled exportShipped Q33%
Custom SQLShipped Q12%
ColdHot
3 rows never crossed 8%
Three features nobody found.
Annotations, Scheduled export, Custom SQL shipped, and never reached one user in twenty. Nothing in a release note tells you that — the roadmap only shows what went out.
What you get
Two curves that end most planning arguments.
Adoption
Who found it, who came back, how long it took.
Adoption, depth of use and time-to-first-use for every feature you ship — per segment, without building a dashboard for each one.
- Discovery, first use and repeat use on one curve
- Split by the properties your events already carry
- Recomputed daily rather than on request
Adoption after launchLast 28 days
31,480+20%vs previous period
- Discovered
- 100%
- Used once
- 82%
- Repeat use
- 54%
- Retained
- 49%
Decline, inferred
A feature going quiet is a signal, not an absence.
A user who stops touching a feature for two weeks is flagged automatically, so decline shows up while you can still do something about it — instead of at the renewal conversation.
- Fourteen-day drop-off detected per user, per feature
- Tied to the accounts it is happening in
- Surfaced on the feature’s own card, with the reason attached
Gone quiet · last 14 days
- −7
bulk_export
7 of 63 users stopped · Dying
- −22
saved_views
22 of 173 users stopped · Plateaued
- −5
share_link
5 of 87 users stopped · Adopted
Flagged · “bulk_export lost 7 users this fortnight”
Why this one sticks
Every previous attempt died at the tracking plan.
app/exports/run.ts1 line
fg.track('feature_usage', { feature: 'scheduled_exports' })Adoption · scheduled_exports
Dashboards to buildNone
Illustrative — the curve exists as soon as the name does.
No tracking plan
Feature usage rides the events you already send. There is no schema to agree in a document before anyone can measure anything.
One call, not a project
Naming a feature is a single call in the code path that matters. Who, when and how often come along on their own.
Nothing to maintain
No per-feature dashboards to build and no properties to keep in sync — the curve exists as soon as the name does.
- One line integration
- Names a feature. Adoption, repeat use, decline and lifecycle all follow from it.
- 14 day windows
- Of silence from a user who was using a feature, and the drop-off is flagged while you can still act.
- Zero dashboards
- To build or maintain. The curve exists as soon as the name does.
In your words
The questions the roadmap meeting actually needs.
- Did anyone actually use what we shipped last quarter?
- Which feature do our best-retaining accounts rely on?
- Where do people try a feature once and never return?
- What can we deprecate without anybody noticing?
- Which accounts went quiet on the feature they onboarded for?
Before you ask