Feature adoption: get users to try what you ship

You spent a month building a feature. It shipped on Tuesday, the changelog went out, and two weeks later almost nobody has touched it. The feature works. Your users just never found it, or found it at a moment when they had something else to do.

Product adoption doesn’t end at sign-up. Every feature you ship has its own small adoption problem: existing users have habits, and a new button in a menu they never open doesn’t change those habits on its own. This post is a how-to for the launch itself: decide what “adopted” means, tell users in the place they’d use it, and check the numbers after two weeks. There is a worked example with made-up numbers at the end.

Step 1: pick the adoption event before you ship

Before the announcement, decide which single action means a user has adopted the feature. Write it down, and make sure your product logs it.

A good adoption event has the same shape as a good activation event:

• It is a result, not a look. “Opened the reports tab” is a look. “Scheduled a report to send weekly” is a result.
• It is something only the new feature can do. If users could already do it another way, you are measuring old habits.
• It happens in the product, and you can log it. If you can’t see it, you can’t count it.

Then decide who counts as eligible. A feature for team admins shouldn’t be measured against every user, and a feature for paid plans shouldn’t be measured against free ones. Your adoption rate is only as honest as the group you divide by.

Finally, pick a second, later event: using it again. A user who tries a feature once out of curiosity hasn’t adopted it. A user who comes back to it in the following week probably has.

Step 2: announce it where it’s used

Most launches announce a feature somewhere the user isn’t working: an email, a changelog page, a banner on the dashboard. Those are good for reach. They are weak at the moment that matters, which is when a user is on the screen where the feature helps, doing the job it was built for.

A few ways to put the announcement in context:

• Trigger on the screen, not the release date. Show a short note the first time an eligible user opens the area the feature lives in, not to everyone on launch day.
• Tie it to the job. “You can now schedule this report to send every Monday” beats “Introducing Scheduled Reports”.
• One message, one action. End on the single step that starts it, with a button that goes there.
• Don’t block the screen. The user came to do something. Let them dismiss the note and get on with it.

1. Step 1Pick the eventOne result only the new feature gives›
2. Step 2Define who’s eligibleThe users the feature is for›
3. Step 3Announce in contextOn the screen where it helps›
4. Step 4Make the first try easyOne step to start, help on hand›
5. Step 5Check at two weeksSaw it, tried it, came back

Step 3: make the first try easy

A user who reads the note and wants to try still has to work out how. New features often come with new settings, new terms and a screen they haven’t seen before. That first try is where interest turns into either a result or a closed tab.

The usual kinds of in-app help each cover part of it:

Kind of help	Good for	Where it runs out
In-app announcement	Telling the right users at the right moment	Getting them through the setup
Short product tour	Pointing out where the new parts are	The user’s own data and settings
Help article or video	Explaining the feature fully	The user has to leave the screen to read it
In-app AI agent	Doing the steps when the user asks	Anything the app itself can’t do

Most teams use a mix. The in-app guidance guide covers each kind in more depth, and when product tours work has a checklist for keeping a tour short.

Step 4: check the numbers after two weeks

Two weeks gives users who log in weekly a couple of chances to see the feature. Then work out three numbers for the eligible users who were active in that time:

• Saw it: eligible users who opened the screen where the feature lives, or saw the announcement.
• Tried it: eligible users who did the adoption event at least once.
• Came back: users who tried it and did the adoption event again on a later day.

In words, the feature adoption rate is the number who tried it divided by the number of eligible, active users. The other two numbers tell you where the gap is.

A worked example

For example, say a project tool ships scheduled reports, for workspace admins only. These numbers are made up to show the method.

In the two weeks after launch, 800 eligible admins were active. Of those, 480 opened the reports screen and saw the note. 120 scheduled a report. 72 of those scheduled or edited a report again on a later day.

Active and eligible800

Saw it480

Tried it120

Came back72

Show as a table

Active and eligible	800
Saw it	480
Tried it	120
Came back	72

Example

saw it (480 of 800)

60%

adoption rate (120 of 800)

15%

tried it, of those who saw it

25%

came back, of those who tried

60%

Read the drops, not the headline. Here the announcement reached most of the admins, so reach isn’t the problem. The large drop is between seeing it and trying it: three in four who saw the note didn’t schedule a report. And most who did try it came back, so the feature itself seems to be doing its job once it’s set up.

That points at the first try. The next move is to look at what users had to do between the note and a scheduled report, and which step they stopped on. If “saw it” had been the small number, the fix would have been the announcement instead. If “came back” had been small, the question would be whether the feature is worth the effort to users at all.

For the same kind of step-by-step reading at sign-up, see where new users stall in setup.

How an in-app agent like Stiro helps users try it

The gap in that example is a common one. The user saw the feature and wanted it, then met a set of new screens and settings. An in-app AI agent fits there: the user asks for the result in plain words, and the agent does the steps in your app.

Stiro is one. You add it with one script tag, and there is nothing to train and no flows to record. An admin who has just read the note can type or say “send me this report every Monday at nine”, and Stiro clicks, types and moves through your real interface to set it up while they watch.

• It can use the feature as soon as it ships. Stiro reads the live screen, so there is nothing to record or update on launch day.
• Users ask for the result, not the menu. They don’t need to know what you named the feature to get to it.
• It says so when it can’t. If a request isn’t possible in your app, it stops, explains why and changes nothing.
• The user keeps the final say. Anything that sends, spends or deletes is set up and handed back for them to press.
• Stuck goes to your team. If it can’t finish, a signed-in user can message your team or your help desk from the same panel.

We tested Stiro cold in three open-source apps it had never seen, a CRM, a project tracker and a scheduling app, and it passed every everyday request, each checked in the app’s own database:

requests done, first run, cold

44 of 44

on a repeat run of the same code

43 of 44

median time from request to reply

19.5 s

The benchmark lists every task and reply.

Launch it, then measure it

Pick the adoption event before you ship, decide who it’s for, announce it on the screen where it helps, and look at saw, tried and came back after two weeks. When the drop is at the first try, give users a way to ask for the result. Stiro does the steps in your app when they ask, and the free plan includes 50 runs a month on localhost and a staging address, so you can try it on your next feature before it goes live.