How to Onboard Customers to a New Feature So They Use It (2026)

The feature is live. The changelog post went out, the email was sent, and the accounts that asked for it still have not done the job it was built for. This guide explains why that happens and gives a five-step method, used by the team at BuildBetter, for getting named accounts to a first completed job on their own data. It also shows how that first result earns customer trust for the next release.

What new-feature onboarding actually is

New-feature onboarding is the planned work of getting a specific customer from access to a first completed job with the feature, using their own data. It is part of the release, not a marketing step that happens after it.

This page is built around one readiness test. A feature is ready for its intended test when the customer:

• Has access to the feature in their workspace.
• Understands the result to expect, stated in plain terms tied to their job.
• Has enough help to reach it, whether that is a video, a guide, a call, or you doing the setup.

If any one of these is missing, non-use tells you about the introduction. It does not tell you about demand.

Keep the next distinction in mind for the rest of the guide. An announcement tells people something exists. Onboarding makes sure the people it was built for can use it. Most teams do the first and assume the second will follow.

If customers do not use a feature you never properly introduced, you have learned about the introduction, not about whether they wanted the feature.

The same logic applies in experiment design. If a subject was never adequately exposed to the treatment, you cannot judge the treatment. Low feature adoption after a weak introduction is a confounded result. The problem is also common. Pendo's 2019 Feature Adoption Report estimated that about 80% of features in the average software product are rarely or never used. It is a vendor figure and it measures activity, not cause, but it is a reason to check the introduction before judging the feature.

Why customers ignore new features (what actually breaks)

Customers usually ignore new features because the introduction failed, not because the feature was unwanted. Five failure modes account for most of it.

1. Announcement as onboarding

A broadcast email reaches everyone equally. That includes the people the feature does nothing for. It also gives none of the people who asked for it a path to a first result. Awareness goes up and the job still does not get done.

2. Empty-state onboarding

Demos and product tours run on sample data. The customer never sees the feature handle their field names, their edge cases, or their volumes, so they cannot tell whether it helps. Time to first value stays at zero because there is no value to see yet.

3. The trust deficit

A customer dealing with recurring failures has little patience for a feature announcement. They are still waiting for the product they bought to work. An impressive release calendar can make that customer feel ignored.

4. The wrong help for the question

Step-by-step hand-holding can hide a navigation problem you needed to see. Making someone wait for a polished setup screen can delay finding out whether the output is useful at all.

5. Reading silence as satisfaction

No complaints can mean confidence. It can also mean the customer has given up.

The method: treat onboarding as part of the release

The method is simple: a release is not finished until the people it was built for have reached a real result with it. It comes from Ship First: How to Build Self-Improving Products by Spencer Shulem, cofounder and CEO of BuildBetter. The book is a short companion to Customer-Led Development. The five steps below work manually, with no tooling, and you can start the first one today.

Step 1: Put onboarding in the release plan before you ship

The release is not done until the introduction is planned. Before shipping, write down three things: who receives this version, what result they should see, and what help each person gets.

Prepare the help before launch. At minimum, that means support documentation and a short video tutorial. Shulem writes that at BuildBetter the tutorials are AI-generated. Producing them quickly is fine. What matters is that the material shows the current experience, not last month's mockup, and that it leads to a useful result rather than a tour of buttons.

Choose the help level on purpose. There are four, ordered by human effort:

1. Video or documentation. The customer follows it alone.
2. In-product guide or workflow. The product walks them through it.
3. A person walking the customer through it. A call or screen share.
4. Done-for-you. Your team configures it in the customer's workspace.

Release planning onboarding checklist:

• Access granted to the intended accounts
• Expected result described in one sentence
• Help format chosen for each account
• A named person responsible for follow-up
• A date to check outcomes

Step 2: Reach the people who asked first

Start with named requesters, not the whole customer base. A release built for a named requester gives you a specific person to help and a specific job to follow. A broadcast gives you neither.

Keep it a limited rollout while you learn how much onboarding the feature needs. Feature flags (also called feature toggles) separate deploying code from releasing it to users, so you can keep the feature visible only to the requesting accounts. This is the core idea behind staged rollout and progressive delivery. The broad announcement can come later as a deliberate decision. It should not happen as a side effect of deployment.

Tell each requester personally that the thing they asked for is live, what it now does for their job, and what to expect. For how to write and time that message, see how to close the loop with customers when you ship a feature.

Before you message an account, check whether it has open reliability problems. If it does, fix those first, or acknowledge them in the same message. Announcing new work to someone whose existing workflow is broken spends trust you will need later.

Step 3: Get each account to a first completed job with their own data

A first completed job is an outcome, not an activity. Define it for this feature in one sentence. For example: "the account receives its first automated weekly report built from its own tickets." A login, a click, a tour view, or an email open does not count. The feature has to do the job it was built for, on the customer's data, and the customer has to see the result. That is the real aha moment.

For substantial setup, configure it for them. Do the setup in their workspace, then show them how it works on their data and their job. This resembles the concierge MVP pattern from Lean Startup practice. You deliver the outcome by hand to learn whether it is valuable before you automate it.

Some experiments are mostly backend. You configure a workflow, run the process, or produce the result inside their workspace. The customer may never touch a new control, and you still learn whether the outcome is useful.

The reason is direct. Seeing a real result is the only way a customer can judge value. It is also the only way you can judge whether the feature works.

Step 4: Keep the test honest about what you are testing

Separate two questions: "Is the outcome valuable?" and "Can they set it up themselves?" The first is about desirability. The second is about usability. Teresa Torres's assumption-testing approach recommends testing these individually, because mixing them produces results you cannot read.

Assisted delivery validates the assisted experience. It does not prove self-service usability. Record how much human help each account needed, in minutes and touchpoints. Without that record, a feature that only worked because your CSM spent an hour on each account will look like a self-serve success.

If the outcome is valuable, that evidence justifies investing in the interface. Then build a good UI and UX, and test whether customers can complete setup without help. This mirrors Ryan Singer's "Get One Piece Done" in Shape Up: get one real, working slice end to end before polishing the parts.

Match the help to the question:

• Testing navigation? Do not steer them through every click. Watch where they stall. Session replay helps here, because customers often cannot describe a navigation problem.
• Testing whether the automated output saves work? Do not make them wait for a polished configuration screen. Set it up for them.

A failure to onboard is your finding. You cannot leave customers confused and then call their non-use proof that they never wanted the feature.

Step 5: Earn confidence in the next release through reliability

Reliability earns permission to build more. Customers who can depend on the current experience have more reason to explore a new one. Treat fixes to edge cases and failures in the current experience as release work. That work is what makes the next feature welcome.

For context, not as a benchmark: Shulem writes that at BuildBetter a reported bug is often fixed in production within an hour, and cosmetic or small functional fixes within a day. Changes that need design review usually ship the same week. New features commonly reach production within a week, and the path to launch is generally kept under a month, with testing in staging or with selected customers.

Track the mix of incoming requests: failures, awkward workflows, and new capabilities. Read the underlying conversations, not just the counts. A shift toward new-capability requests can signal growing confidence. A spike in failure reports tells you an account has little room for anything new.

Do not mistake silence for health. Check actual use and outcomes before concluding the product is fine.

Worked example: one release, eight accounts, first week

This example is illustrative. The numbers are invented to show the decisions and are not BuildBetter data.

Setup. A B2B tool ships an "auto-generated weekly churn-risk summary." Eight accounts requested it. First completed job: each account receives one summary built from its own support tickets and reads it.

Day 0: who goes first. A pre-check finds that 2 of the 8 accounts have open sync failures. The team fixes one the same day. They message the other honestly: the fix comes first and the feature follows. That account is held back.

Day 1. Personal messages go to 7 accounts with a 3-minute video and a docs link. 3 of 7 complete setup on their own.

Days 2–3. 4 accounts stall at mapping ticket fields. The team configures 3 of them directly, about 25 minutes each (75 minutes total). The fourth gets a 20-minute walkthrough call.

Day 4. All 7 have received a first summary. The team records the help required: 3 self-serve, 1 walkthrough, 3 done-for-you.

Day 5: outcome check. 5 of 7 say the summary changed what they did that week. 2 say it duplicated a report they already had. Those 2 go into the notes as a scope finding, not an onboarding failure.

Days 6–7. The team ships changes based on what happened. They add a default field mapping, because 4 of 7 stalled at the same step. They re-record the video to show the real mapping screen. They onboard the held-back account after its fix ships.

The decision. The outcome is validated with assisted setup. So the team invests in the setup UI next and will rerun the test as self-serve only before announcing broadly. Seven accounts were enough to surface the main stall.

Who should you tell first, and how much change can an account absorb?

Tell the requesters first, keep the rollout small, and introduce one new job at a time per account. The questions below come up in almost every release.

Who to tell first

Start with the named requesters. Then move to accounts with the same job and no open reliability problems. Leave accounts in active firefighting for later, and fix what is broken for them first.

Announcement or onboarding: which comes first?

Onboarding for the requesters comes first. The broad announcement waits until you know how much help the feature needs and the self-serve path holds up without you.

How much change can an account absorb at once?

Introduce one new job at a time per account. Do not stack a new feature on top of unresolved failures. If an account's recent requests are mostly about things breaking, its capacity for new features is low, no matter how much it asked for this one.

Should we remove onboarding steps to make adoption faster?

Be careful. Cutting steps can remove the moments that get a customer to a real result. A shorter flow that ends before the first completed job is not faster time to value. We cover this in why removing steps from your onboarding is losing customers.

Readiness rubric before you contact an account:

• The account has access
• The account has no open critical failures
• The account has a named contact
• The account's job is clear and written down
• The help format is chosen

Common mistakes when onboarding customers to a new feature

Most onboarding mistakes come from confusing awareness with a completed job. Watch for these:

• Treating the launch email as onboarding. Awareness is not a completed job.
• Calling non-use a verdict on the feature when the introduction failed.
• Demoing with sample data instead of the customer's own data.
• Counting assisted success as proof of self-service usability, and not recording how much help was given.
• Over-guiding when the open question is navigation, which hides the exact problem you need to see.
• Announcing new features to customers still waiting for existing ones to work.
• Reading silence as satisfaction without checking use and outcomes.
• Rolling out to everyone before learning how much onboarding the feature requires.

When you need tooling (and when you don't)

The manual method works well for a handful to a few dozen requesting accounts per release. A spreadsheet and a shared doc are enough. It stops scaling when you can no longer trace who asked for what across calls, tickets, and Slack. That usually happens once requests arrive in the hundreds per month or several releases overlap.

Three things break first: matching releases back to the people who asked, tracking the request mix over time, and seeing where users stall in setup. In order of where to start:

1. BuildBetter. Pulls calls, Slack, tickets, and surveys into one place, so you can find the named requesters for a release, track the request mix (failures vs workflows vs new capabilities) over time, and draft loop-closure messages. Tracked Objects links each request to its evidence and to the release that answers it.
2. PostHog session replay. Watch where customers stall during setup instead of asking them to describe it.
3. Unleash. Open-source feature flags to keep the rollout limited to named accounts.
4. Userflow. Lightweight in-app guides once a self-serve setup path exists.

A fair caveat: if your main need is mature research-repository tagging or very large-scale survey distribution, a dedicated tool in that category may fit better. BuildBetter's strength is connecting customer voice, both external feedback and internal team conversations, to the release decision.

FAQ: onboarding customers to new features

Why aren't customers using our new feature?

Usually they were told about it but never reached a first completed job with their own data. Check the three readiness conditions: access, understanding of the expected result, and enough help to reach it. Treat non-use as a finding about the introduction until you have ruled that out.

What is the difference between a feature announcement and feature onboarding?

An announcement creates awareness across your customer base and is measured by opens and clicks. Onboarding gets a specific named account to a first useful result on its own data, with the right level of help. It is measured by a completed job and a checked outcome.

Who should get a new feature first?

The customers who asked for it, in a limited rollout. That gives you a named person to help and a specific job to follow. Next come accounts with the same job and no open reliability problems. Accounts in active firefighting come last, after their issues are fixed.

Should we set up the feature for customers ourselves?

Yes, when setup is substantial and the open question is whether the result is valuable. Record how much help you gave, in minutes and touchpoints. Assisted success proves the outcome is useful, not that customers can set it up alone.

What counts as a "first completed job"?

A one-sentence outcome where the feature did the job it was built for, on the customer's data, and the customer saw the result. For example: "the account receives its first automated weekly report built from its own tickets." Logins, clicks, and tour completions do not count.

How do we know customers trust us enough for a new release?

Watch the mix of incoming requests. A shift from failures toward new capabilities suggests confidence. Still check actual use and outcomes, because silence can also mean a customer has given up.

When is a feature ready to release to customers?

When the intended customers have access, understand the result to expect, and have enough help to reach it. That help can be a video, documentation, an in-app guide, or you doing the setup.

Sources and further reading

• Ryan Singer, Shape Up, Chapter 11, "Get One Piece Done": basecamp.com/shapeup/3.2-chapter-11
• Teresa Torres, Product Talk, "Assumption Testing": producttalk.org/assumption-testing
• PostHog docs, "How to watch recordings": posthog.com/docs/session-replay/how-to-watch-recordings
• Wikipedia, "Feature toggle": en.wikipedia.org/wiki/Feature_toggle
• Pendo, "The 2019 Feature Adoption Report" (vendor research)
• How to close the loop with customers when you ship a feature
• Removing steps from your onboarding is losing customers: here's why

Make churn optional.

BuildBetter connects every call, ticket, Slack thread, and survey to the releases they shaped. You can find who asked for a feature, get them to a first completed job, and tell them when it ships. Book a demo to see how 30,000+ B2B teams turn customer requests into features customers use.

Get Ship First

This method comes from Ship First: How to Build Self-Improving Products by Spencer Shulem: 24 short chapters on going from a customer request to a working release. Get the free PDF or EPUB, or read it on Kindle.