Your Feature Isn't Being Used: Is It the Product or the Onboarding?

The Real Cost of Unused Features

Every product team eventually faces this moment: you've shipped a feature, instrumented the analytics, and discovered that almost nobody uses it. The instinct is to diagnose quickly—is the feature wrong, or did we just explain it poorly? But this binary framing misses the deeper question that determines whether you waste the next three months rebuilding something that didn't need fixing, or abandon something that could have driven significant value with a two-week intervention.

The stakes are higher than most teams acknowledge. An unused feature isn't just neutral—it's actively expensive. It accumulates technical debt, creates maintenance burden, clutters your interface, and represents opportunity cost on what you didn't build instead. Getting the diagnosis wrong means either prematurely killing something valuable or throwing good money after bad.

What the Debate Revealed

The initial positions clustered around a clear majority view: onboarding is almost always the culprit. Three of four perspectives argued that features reaching production typically had some validated need behind them, making the handoff to users the more likely failure point. As the operator perspective noted, a simple test at one SaaS company—adding a 30-second tooltip and one targeted email—jumped feature adoption from 8% to 34% in two weeks.

But the product perspective challenged this consensus with a harder question: what if users aren't adopting the feature because they simply don't need it urgently enough to change their behavior? This introduced a crucial distinction that the diagnostic perspective sharpened in the second turn:

If no one uses the feature, you're right—wrong job-to-be-done. But if you're seeing 5-15% adoption, that gap between zero and low-but-not-zero is the smoking gun for onboarding failure.

This distinction proved pivotal. The debate wasn't actually about whether features can be wrong—everyone conceded that possibility. The real tension emerged around sequencing: do you test the onboarding hypothesis first because it's faster and cheaper, or do you validate the job-to-be-done because good onboarding can't save a feature solving the wrong problem?

By the second turn, positions had hardened around this sequencing question. The operator perspective conceded that sometimes teams do build the wrong thing, but maintained that "you can't diagnose a JTBD mismatch when users haven't actually tried the feature." The founder perspective went further, calling deeper jobs-to-be-done research a "diagnostic luxury most founders can't afford right now" when you could validate with a sprint.

The product perspective held firm, pointing to a team that spent three months perfecting tooltips and walkthroughs only to see adoption creep from 4% to 7%—because users had already developed efficient workarounds. The implication was clear: some features are dead on arrival, and no amount of onboarding resuscitates them.

The Framework: Diagnostic Before Treatment

The debate reveals a practical three-stage diagnostic framework that resolves the sequencing question:

Stage 1: Check for any signal
Look at your power users—the top 10% most engaged customers. If even they aren't using the feature, you likely have a fundamental product problem. If some power users have discovered and consistently use it, you have proof that value exists, which points to an onboarding failure for everyone else.

Stage 2: Test the cheap hypothesis first
If you have any adoption signal, instrument the discovery path and test lightweight onboarding interventions. The consultant perspective offered the Dropbox shared folders example: the feature had abysmal adoption until they redesigned onboarding to show it contextually when users actually needed collaboration. The feature itself never changed.

This stage should take days or weeks, not months. Add tooltips, send targeted emails, move the feature in navigation, create contextual prompts. If adoption jumps meaningfully, you've found your answer. If it barely moves, proceed to stage three.

Stage 3: Validate the job-to-be-done
Now you've earned the right to ask the harder question. Can you name three specific user workflows where this feature demonstrably saves time or reduces friction? Find five users who theoretically have the problem your feature solves, show them the feature with zero context, and watch their reaction. If they don't immediately grasp its value and ask how to access it, you don't have an onboarding problem—you have a product-market fit problem with that specific feature.

The Nuance: When Context Changes Everything

This framework assumes you're operating with typical constraints—limited engineering resources, pressure to show results, and imperfect information. But several factors change the calculus:

Strategic versus tactical features: Some features exist to enable future capabilities or serve a small but critical user segment. Low adoption might be expected and acceptable. The diagnostic framework applies to features you built expecting broad adoption.

Feature complexity matters: A simple button that nobody clicks is almost certainly an onboarding problem. A complex workflow that requires behavior change might genuinely solve the wrong problem, even with perfect onboarding. The more behavior change required, the stronger the job-to-be-done signal needs to be.

Your stage and resources: The founder perspective was right that early-stage companies can't afford lengthy JTBD research when they could test onboarding in a sprint. But established products with dedicated research teams might flip the sequence—validate the job first, then optimize delivery.

Existing workarounds: If users have already developed efficient alternatives, even perfect onboarding faces an uphill battle. This is where the product perspective's skepticism proves warranted. Adoption isn't just about awareness—it's about displacement of existing behavior.

Where to Start: Five Concrete Actions

• Segment your usage data immediately. Don't just look at overall adoption. Break it down by user cohort, tenure, and engagement level. If your power users love it but new users ignore it, that's definitively an onboarding problem. If nobody uses it regardless of engagement level, that's a product problem.
• Run the manual walkthrough test. Take five users who haven't adopted the feature and personally walk them through it. Listen for "I didn't know you could do that" (onboarding) versus "I don't need that" (product). This single qualitative test often resolves the debate in under an hour.
• Ship one lightweight onboarding intervention this week. Don't wait for the perfect solution. Add a tooltip, send an email, or create a contextual prompt. Measure the impact over two weeks. If adoption doesn't move, you have your answer without significant investment.
• Instrument the discovery path. Add analytics to understand where users encounter (or don't encounter) the feature. Are they seeing it but not clicking? Never seeing it at all? Clicking once then abandoning? Each pattern suggests different problems.
• Define your kill criteria upfront. Before you start fixing anything, decide what adoption level would justify continued investment versus sunsetting the feature. This prevents endless optimization of something that should be retired.

The Uncomfortable Truth

The debate's most valuable insight came from recognizing that "fix the onboarding first" isn't just pragmatic advice—it's a forcing function. Testing lightweight onboarding changes gives you real usage data to determine if the feature itself needs work. But it also creates accountability. If you've fixed discoverability and adoption still languishes, you can't hide behind "users just don't understand it." Sometimes the most valuable thing onboarding reveals is that you built something nobody actually needed. The question isn't whether to test onboarding or validate the job-to-be-done. It's whether you're willing to accept the answer when the data comes back.