How to increase adoption of an AI feature: find the stage where users drop, then fix that one

An AI feature with low adoption almost never has a generic awareness problem. It has a specific break at one of four stages, and the fix for each stage is different. Google's People + AI Guidebook names the cost of getting the first impression wrong: "Mismatched mental models can lead to unmet expectations, frustration, misuse, and product abandonment."

Trust is the stage most teams underrate. In the Stack Overflow 2025 Developer Survey, 84% of respondents said they were using or planning to use AI tools, yet 46% said they actively distrust the accuracy of those tools, against 33% who trust it. Those are developers rating AI tools in general, not your users rating your feature, so treat the numbers as a direction rather than a benchmark. What they still show is that trying an AI tool and relying on it are two separate decisions, and your feature has to win both.

Where does adoption of an AI feature usually break?

Adoption of an AI feature breaks at discovery, first use, trust or habit, and you can see which one from four numbers you can pull from your event data this week.

Stage	What the user does	Number to pull	First fix to try
Discovery	Never sees or opens the feature	Share of eligible users who opened it at least once	Put the entry point inside the task, at the moment it applies
First use	Opens it, then leaves without a result	Share of first sessions that produce an output the user keeps	Replace the empty prompt with actions built from the current context
Trust	Uses it once or twice, then stops	Second-week return rate among users who kept one output	Make the output editable and show what it was based on
Habit	Likes it but forgets it exists	Bypass rate on eligible tasks	Trigger the feature from the step users already perform

Fix the stage with the largest drop first. A team that redesigns onboarding when the real break is trust gets more first uses and the same churn a week later.

If you have not instrumented the feature yet, define the eligible population before anything else: the users and tasks where the AI feature could have helped. Every rate above divides by that number, and the same discipline applies as in defining an activation metric.

How do you get users to discover an AI feature?

Users discover an AI feature when it appears inside the task it helps with, not in a launch banner or a new tab. The Mental Models chapter of Google's guidebook puts the rule as one line: "Introduce an AI-driven feature at the moment it is relevant to the user." The same chapter adds that "People learn better when short, explicit information appears right when they need it."

In practice that means the summarise button sits on a long thread, the draft button sits in the reply box, and the analysis suggestion appears when the user opens a chart. A separate AI page that users have to remember to visit fails the discovery stage by design.

Generic tours rarely fix discovery for AI features, because the tour shows the feature before the user has a task for it. If you use a product tour tool, trigger the step from the context where the feature applies, not from the first login.

Why do users stall at the first prompt, and what fixes it?

Users stall at the first prompt because an empty text box asks them to invent a task and phrase it well before they have seen what the feature can do. BJ Fogg's behavior model explains why that kills the first use: "Behavior happens when Motivation, Ability, and a Prompt come together at the same time. When a behavior does not occur, at least one of those three elements is missing." A blank prompt is an ability problem: the user is motivated enough to click, then hits a step that is harder than doing the task by hand.

Replace the blank box with two or three ready actions built from what the user already has open: summarise this thread, draft a reply to this ticket, list the open questions in this document. Each one should run in a single click and produce something the user can judge in seconds. Google's Mental Models chapter recommends the same move for onboarding AI products: "Suggest a low-risk or reversible action they can try right away".

Keep the free text box, but put it second. Users who know what they want will type; users who do not will pick a starting action, and their first output teaches them what to ask next.

Why do users try an AI feature once and then abandon it?

Users abandon an AI feature after one or two tries when an early output is wrong and they have no way to fix it short of starting over. Researchers call the pattern algorithm aversion, and the 2018 study by Berkeley Dietvorst, Joseph Simmons and Cade Massey describes it as people failing to use evidence-based algorithms "after learning that they are imperfect". The same study found the remedy: "Participants were considerably more likely to choose to use an imperfect algorithm when they could modify its forecasts, and they performed better as a result."

The study used forecasting tasks, not software features, so the finding is about how people treat imperfect automated advice rather than a measured effect on product retention. The design lesson still carries over directly. An output the user can edit survives a mistake; an output the user can only accept or reject loses them on the first bad answer.

The Stack Overflow 2025 survey shows what the frustration looks like in practice: 66% of respondents said they had run into "AI solutions that are almost right, but not quite", the most common frustration with AI tools in the survey. An answer that is almost right is the case editing handles best, which is one more reason to ship an editable draft rather than a final answer.

Three changes rebuild trust at this stage:

• Editable output. Return a draft the user can change in place, not a block of text with a copy button.
• Visible basis. Show which document, record or message the answer came from, so the user can check it in seconds.
• A manual path one click away. When the feature is unsure or fails, the task should continue without it, the same fallback rule the AI feature launch checklist sets as a go/no-go gate.

Watch your own marketing too. The Mental Models chapter warns that many products set users up for disappointment by promising that AI magic "will help them accomplish their tasks", which sets an expectation the first wrong answer breaks.

How do you turn first use of an AI feature into a habit?

Habit forms when the feature fires from a step users already take every day, so they never have to remember it exists. Fogg's three elements apply again here: motivation is high once the user has seen a good output, ability is high once the first use is one click, and the missing piece is usually the prompt. A reminder email is a weak prompt. The draft appearing in the reply box when a ticket opens is a strong one.

Map the workflow the feature serves, find the step that comes right before the AI output is useful, and attach the trigger there. For a meeting summary, that step is the meeting ending, not the user opening a notes page. For a weekly report, that step is the report being due, not a dashboard visit.

Then check the bypass rate weekly. A falling bypass rate on eligible tasks is the clearest sign that the feature has become the default way to do the job, which is the point of an AI copilot in the first place.

What are bypass rate and override time, and how do you track them?

Bypass rate and override time are the two adoption metrics that usage counts hide. Bypass rate is the share of eligible tasks completed without the AI feature. Override time is how long a user spends changing the AI output before accepting it.

Metric	Formula	Events to log	What a bad trend means
Bypass rate	Eligible tasks done without the feature, divided by all eligible tasks	Task started, feature offered, feature used, task completed	Users see the feature and choose the old way
Override time	Time from output shown to output accepted, per accepted output	Output shown, first edit, output accepted or discarded	Users accept the output but redo much of the work
Second-week return	Users active with the feature in week two, divided by users who kept an output in week one	Output kept, feature used, by user and week	Users tried it and decided it was not worth it

Read the two together. Low bypass with high override time means users feel they have to use the feature but do not trust its output, which is common when it is switched on by default. High bypass with low override time means the output is good for the people who use it, and the problem sits earlier, in discovery or the first use.

These adoption metrics sit inside a wider set. The guide on how to measure AI feature success covers the quality proxy, product outcome, cost and latency that decide whether the adopted feature is worth running. Where a person reviews each output before it ships, the review step is also where override time is cheapest to log, which is one more reason to design a human-in-the-loop step deliberately rather than as an afterthought.

Should you force adoption by making the AI feature the default?

Making the AI feature the default is the strongest objection to everything above: skip discovery and first use, put the output in front of everyone, and adoption goes up overnight. The objection is right about the number and wrong about what it means. Default-on raises exposure, and exposure counts users who saw the output and ignored it, deleted it or rewrote it.

Default-on works when the output is easy to inspect and cheap to undo, such as a suggested reply the user still has to send. It backfires when the feature acts for the user, because the first wrong action costs trust the user cannot recover by editing. If you do switch it on by default, judge the rollout on bypass rate and override time, not on how many people were shown an output.

In what order should you work on AI feature adoption?

Work from the funnel, not from a list of ideas. Pull the four stage numbers, fix the stage with the largest drop, and leave the others until that number moves. A typical sequence for a feature that launched quietly runs from discovery to first use; a feature with strong launch numbers and a fast decline usually needs the trust fixes first.

Google's People + AI Guidebook gives the cheapest starting point for every one of them: "Reviewing your product logs can show you behavior or use trends that point to user confusion or frustration." Read twenty sessions where a user opened the feature and left without keeping an output before you design the fix.

Where do you practise designing AI features users adopt?

Builders Camp's AI Product Management bootcamp runs for 2 weeks with 4 live sessions and 7 self-paced microlessons, and its stated goal is to help you design AI-native experiences, evaluate model behaviour, manage risk and deliver AI features users trust. The bootcamp is part of the AI Product Expert Track, and its practical challenge is rated advanced.

See the AI Product Management bootcamp

Before your next adoption review, write down the eligible population for the feature and pull its bypass rate for last week. If you cannot compute it, the first fix is an event, not a redesign.