Feature adoption is the share of your users who actually use a feature after it ships, measured over some window rather than at a single moment.
It is the question that separates shipping from building, and it is measured in a different system from the one that decided what to build. That split is the reason so many teams have a confident roadmap and no idea whether last quarter worked.
How is feature adoption measured?
Three numbers, and quoting only the first is the commonest mistake.
Breadth. What share of users touched it at all in the period. Easy to measure and easy to inflate with a banner.
Depth. How often the ones who touched it come back to it. This is where a feature that was clicked once out of curiosity separates from a feature that entered somebody's week.
Retention of use. What share of the people who used it in the first month were still using it in the third. A feature with high breadth and no use retention is a novelty.
The three together tell a story. Any one of them alone can be moved without the product getting better, which is the general rule about output metrics written up as the feature factory.
What counts as good feature adoption?
There is no benchmark on this page, deliberately, because the honest answer is that it depends on who the feature was for.
A feature built for administrators in a product where one user in twenty is an administrator cannot exceed five percent breadth and should not be judged against a feature every user needs daily.
The comparison that means something is against the size of the group the feature was built for, not against the whole user base and not against a number from somebody else's product.
That is also why adoption targets set before a feature exists are usually theatre. The useful version is naming the group it is for and the behaviour you expect to change, and then looking.
Can a feedback board measure feature adoption?
No. The board stops counting at the moment the card moves to shipped.
This is worth saying plainly on a feedback board's own site. Everything a board records happens before the work exists. Votes, comments and views count people asking.
Nothing in this product observes what anybody does inside your application afterwards, because it is not in your application. Adoption is measured in product analytics, and that is a different tool from this one.
What the board does have is the list of people who asked. That turns one adoption question from a general statistic into a specific one, which is whether the people who requested a feature are the people who ended up using it.
Answering it needs your own analytics on one side and the voter list on the other, and the join is yours to make.
What does a board tell you instead?
Whether the request stopped arriving, which is the cheapest adoption signal anybody has.
If a feature shipped and near duplicates of the original request keep appearing six months later, something is wrong. Either the thing built is not the thing asked for, or the people who wanted it never found it.
Both are adoption failures and both are visible on the board without any analytics at all, provided somebody is reading the new requests against the old ones.
The second signal is the comments on the original request after it ships. They are unprompted, specific and usually the first place a design mistake gets described in words. A board where the card stays open after the release is a better instrument than one where shipping archives the conversation.
How should adoption change what gets built next?
By retiring things, which is the decision nobody schedules.
Adoption data mostly gets used to argue for more promotion of a feature that is not working. The more useful use is the opposite, which is deciding that something is not earning its complexity and removing it.
A product that never removes anything accumulates surface area faster than it accumulates value, and that is feature creep arriving by the front door.
The order of what to build next is a separate question, and here it is answered by what people ask for weighted by what they pay, rather than by what the last release achieved. The formula and the code behind it are published.
14 days, a card at signup, then $9 or $39 a month.