Your Roadmap Is Not a Growth Strategy. It Is a Feature Factory.
Pendo found that 6.4% of features drive 80% of click volume in the average product, while almost 94% are untouched or ignored. The founder guide to stopping feature bloat, measuring adoption, and turning product output into customer value.
Your Roadmap Is Not a Growth Strategy. It Is a Feature Factory.
Founders often treat a full roadmap as proof of momentum. More features mean more innovation. More releases mean more progress. More customer requests closed mean more growth.
That logic feels safe. It is also how software becomes hard to use, hard to sell, hard to support, and impossible to explain in one sentence.
The uncomfortable truth is that most product teams do not have a roadmap problem. They have an adoption problem. They keep building because shipping is visible. Customer value is harder to measure.
The Data Says Your Customers Are Ignoring Most of What You Build
Pendo’s 2024 product benchmarks found that just 6.4% of features in the average product generate 80% of click volume. In other words, almost 94% of features are untouched or ignored when measured against this core-event benchmark [1].
The top 10% of products are better, but the number is still uncomfortable. Their feature-adoption rate is 15.6% — 2.5 times the average [1]. Even the strongest product teams are not winning by shipping everything. They are winning by making a smaller set of actions clear, valuable, and habitual.
An earlier Pendo study examined anonymised usage data across 615 subscriptions. It found that 80% of features in the average product were rarely or never used. Only 12% of features generated 80% of average daily usage [2].
That study estimated that publicly traded cloud-software companies had invested up to $29.5 billion in R&D for underused features. For a hypothetical $50 million revenue software company, the estimated spend on rarely or never used features was $8.4 million [2].
A feature is not an asset because it shipped. It becomes an asset only when the right customer uses it repeatedly and receives measurable value.
The Feature Factory Makes Every Team Slower
Unused features do not sit quietly in the codebase. They create support tickets. They create onboarding screens. They create more documentation, more tests, more edge cases, and more choices for a new customer. Every “small” request becomes a permanent tax on the product team.
Then the cycle gets worse. Adoption falls because the product is complex. Sales asks for another feature to win deals. Product builds it. Customer success must explain it. The roadmap gets longer. The customer sees less value, not more.
This is why a roadmap full of customer requests is not automatically customer-led. It may be a company outsourcing product strategy to the loudest buyer.
The Comparison Every CEO Should Put in the Board Pack
| Product behaviour | Evidence | Business result |
|---|---|---|
| Average product | 6.4% of features drive 80% of click volume | Large build effort sits outside core customer behaviour |
| Top 10% of products | 15.6% feature adoption; 2.5x the average | More effort is focused on what users actually do |
| Companies under 200 employees | 7.4% average feature adoption | Smaller, less sprawling product ecosystems can be easier to adopt |
| Pendo’s 2019 usage study | 80% of features rarely or never used | Output can be high while customer value remains low |
Source: Pendo feature-adoption research [1] [2]. Adoption benchmarks vary by industry and product type; the point is to measure your own product rather than assume a shipped feature is valuable.
Stop Funding Features Without an Adoption Contract
Zee’s view is direct: every proposed feature should come with an adoption contract before engineering starts. It should name the target customer, the problem, the expected behaviour, the time-to-adopt target, and the decision if the feature misses the target.
For example: “Within 60 days, 30% of eligible weekly active users will complete this action at least twice.” That is a test. “Customer X asked for it” is not a test.
Feature adoption is not just whether someone clicks once. Pendo separates it into four questions: breadth, depth, time to adopt, and duration of adoption [1]. How many relevant users tried it? How often do they use it? How quickly do they discover it? Do they keep using it after the launch noise fades?
The answer is not always to delete low-use features. Some features are used only at critical moments. Some are needed for compliance. Some are important for a valuable customer segment. But every exception should be explicit. “We built it” is not a reason to keep investing in it.
What Strong Product Companies Do
Strong companies make core workflows boringly good before they add another menu item. They instrument core events. They tie product decisions to customer segments, not to a global click count. They use in-product guidance where discovery is the issue, then retire, simplify, or reprice work that does not create value.
Pendo reported that customers using its adoption tools for a year saw a 50% increase in daily feature use and a nearly 25% decline in unused features. Deploying at least 25 in-app guides was associated with a 25% increase in features used daily [2]. The lesson is not “buy more tools.” The lesson is that adoption must be designed and measured after release.
Growth is not the number of items completed on a roadmap. Growth is more customers receiving more value from the few things that matter most.
Frequently Asked Questions
What is a feature factory?
A feature factory is a product organisation that measures output — releases, tickets, and roadmap completion — more than customer outcomes. It can ship quickly while creating little real adoption or retention value.
What is feature adoption?
Feature adoption measures whether relevant users discover, use, and continue using a specific product capability. Pendo describes four dimensions: breadth, depth, time to adopt, and duration of adoption [1].
How many software features are actually used?
Pendo’s 2024 benchmark found 6.4% of features drove 80% of click volume in the average product. Its earlier study found 80% of features were rarely or never used. These are benchmark findings, not a universal law, so each company should instrument and assess its own product [1] [2].
Should a startup build fewer features?
A startup should build fewer unmeasured features. The right question is whether each feature has a defined customer, expected behaviour, adoption threshold, and review point. High-value features may be niche; low-value features may be popular. Measurement creates the distinction.
How should a CEO measure feature adoption?
Review adoption by customer segment, not only across all users. Track eligible users who use a feature, repeat use, time to first use, sustained use, support burden, and the effect on retention, expansion, or conversion.
When should a company remove a feature?
Consider simplifying, retiring, or de-prioritising a feature when it repeatedly misses its defined adoption and value threshold, is not required for compliance or a strategic segment, and creates material maintenance or support cost.