AI Product Teams: Stop Building Features, Start Building Understanding

TL;DR

• AI product teams default to feature velocity as their primary metric, but 80% of features in the average software product are rarely or never used [1], according to Pendo’s analysis of over 600 products
• Teams that shift from output to outcomes, investing in user understanding infrastructure instead of pure feature volume, consistently outperform on retention and satisfaction
• The highest-leverage shift is from “what features should we build?” to “what do our users actually need?” That answer requires infrastructure, not intuition

Most AI product roadmaps are feature lists. The assumption is that more features equals more value. But Pendo’s 2019 Feature Adoption Report [2] found that only 12% of features generate 80% of daily usage in the average software product. The remaining 80% of features are rarely or never used. That is an enormous amount of engineering capacity spent on things users do not care about. This post covers the feature trap, why understanding compounds where features do not, and how to shift engineering capacity toward the investments that actually matter.

The Feature Trap

AI product teams fall into the feature trap for predictable reasons. John Cutler, writing at Amplitude, calls this the “feature factory” [3]: organizations that measure success by output (features shipped) rather than outcomes (value delivered).

Features are visible. You can put them in a changelog, demo them to investors, and count them on a roadmap. Understanding is invisible. You cannot screenshot a user model. You cannot demo a belief inference. The artifact of understanding is better products, not a tangible deliverable.

Features feel like progress. Shipping a feature feels like accomplishing something. Understanding does not give that same reward. Learning that users need depth on three features rather than breadth across ten feels like a reduction in ambition, even though it is an increase in impact.

Competitors ship features. When a competitor announces a new feature, the instinct is to match it. But matching features without matching understanding means you are copying their guesses about what users need, which were probably wrong for the same reasons yours are.

Sales teams demand features. “If we just had X feature, we could close this deal.” This is almost always wrong. The deal is not stalling because of a missing feature. It is stalling because the product does not demonstrate understanding of the prospect’s specific needs. As Clayton Christensen argued in his Jobs to Be Done framework [4], customers do not buy products. They “hire” them to make progress in specific circumstances. A product that understands the job is worth more than twenty features the prospect will never use.

Why Understanding Beats Features

The evidence for prioritizing user understanding over feature volume is consistent across multiple large-scale studies.

McKinsey’s Business Value of Design study [5] tracked 300 publicly listed companies over five years and found that companies in the top quartile for user-centric design practices saw 32% higher revenue growth and 56% higher total returns to shareholders compared to their industry peers. The common thread among top performers was not shipping more features. It was embedding user understanding into every decision.

Marty Cagan of Silicon Valley Product Group draws the distinction sharply in his essay Product vs. Feature Teams [6]. Empowered product teams are given problems to solve, and they develop deep understanding of user needs to find the right solutions. Feature teams are given a list of features to build, and the question of whether those features deliver value is someone else’s problem. The difference in outcomes is dramatic.

Separately, research cited in Harvard Business Review [7] shows that increasing customer retention by just 5% can increase profits by 25% to 95%, depending on the industry. Understanding what keeps users engaged, and building for that, has an outsized financial payoff compared to adding features that go unused.

Understanding as Infrastructure

Understanding is not a one-time research project. It is infrastructure that improves every interaction.

A user interview gives you understanding at one point in time. A survey gives you understanding at one point in time. Teresa Torres describes the alternative in Continuous Discovery Habits [8]: product teams should maintain weekly touchpoints with customers and build systems that continuously surface what users need, not just what they say they want. A self-model takes this further by evolving understanding with every interaction, for every user, automatically.

The infrastructure investment has a different shape than a feature investment. Features have a discrete cost (build it) and a discrete benefit (users have it). Understanding infrastructure has an upfront cost (build the system) and a compounding benefit (every interaction improves understanding, which improves every subsequent interaction).

1// Feature-first: build what seems right← Bet
2await shipFeature('advanced-analytics-dashboard');
3// Hope: users will use it. Reality: low adoption.
4
5// Understanding-first: learn what IS right← Investment
6const selfModel = await clarity.getSelfModel(userId);
7
8// What does this user actually need?
9const needs = selfModel.beliefs.filter(
10  b => b.context === 'product_needs' && b.confidence > 0.7
11);
12// Result: user needs faster export, not more dashboards
13
14// Build what the understanding tells you
15await shipFeature('one-click-export');
16// Result: high adoption. Because it was built on understanding.

The Shift in Practice

Making this shift requires changing three things about how a team operates.

Change what you measure. Replace “features shipped” with “user value delivered” as the primary team metric. Measure how many users found value in what you built, not how much you built. This is harder to measure but infinitely more useful for decision-making. As Cutler notes, feature factories [9] rarely measure the impact of what they ship.

Change how you prioritize. Instead of prioritizing by competitive pressure, sales requests, or intuition, prioritize by observed user needs. Self-models surface what users actually care about. Not what they say in surveys (which is biased by question framing) but what they demonstrate through behavior and expressed beliefs.

Change how you allocate. Reserve 20-30% of engineering capacity for understanding infrastructure: self-models, feedback systems, usage analysis that goes beyond analytics. This feels like a tax on feature velocity. It is actually an investment in feature accuracy. Consider that Pendo estimates public cloud companies collectively spend $29.5 billion [10] on features that are rarely or never used. Even recapturing a fraction of that waste through better understanding would be transformative.

The Counterargument

The obvious pushback: “We cannot afford to ship fewer features. Our market moves fast. Competitors will pass us.”

Here is what actually happens. The feature-first team ships many features. Competitors copy the few that matter. The bulk of engineering capacity goes to features nobody uses. Net advantage: marginal.

The understanding-first team ships fewer features, each one precisely targeted to real user needs. Competitors can copy the features but cannot copy the understanding that informed them. Net advantage: compounding. This is exactly the pattern McKinsey observed. The top-quartile design companies [11] did not ship more. They shipped better, because they understood their users more deeply.

Feature velocity is a vanity metric. Feature accuracy is the real game.

Trade-offs

The understanding-first approach has real costs.

Short-term velocity decreases. You will ship fewer features. Your changelog will be thinner. In competitive markets with feature-comparison buyers, this feels dangerous. You are betting that quality will beat quantity, and that bet takes 3-6 months to prove out.

The investment is front-loaded. Building understanding infrastructure costs engineering time before it delivers product insight. The ROI is delayed. Teams under cash pressure may not have the runway to wait for the compounding returns.

Cultural resistance is real. Engineers want to build. Product managers want to ship. Telling both groups to slow down and invest in understanding feels like bureaucracy. It requires leadership conviction and clear communication about why this approach wins in the medium term.

Understanding does not replace all features. Some features are table stakes. You need them regardless of user understanding (security, compliance, basic functionality). Understanding-first does not mean feature-never. It means feature-informed.

What to Do Next

1. Audit your feature adoption. For every feature shipped in the last 12 months, measure adoption (% of users who use it weekly) and value (satisfaction or task completion for those who use it). Multiply adoption by value for a rough value score. Rank features by this score. The bottom half represents wasted capacity, and the opportunity for understanding investment. Pendo’s feature adoption benchmarking [12] offers a useful reference for what “good” looks like.

2. Reserve 20% for understanding. In your next sprint planning, reserve 20% of engineering capacity for understanding infrastructure. This could be self-model integration, feedback loop improvement, or deep usage analysis. Clarity provides the self-model infrastructure that turns interactions into understanding. Measure whether the features built with understanding input have higher adoption than features built without it.

3. Replace one feature bet with one understanding investment. Take the lowest-confidence feature on your roadmap, the one where you are least sure users will adopt it, and replace it with an understanding project that would tell you whether users actually need it. The knowledge you gain is worth more than the feature you might have wasted capacity building.

Stop building features your users do not need. Start understanding what they do. Build the understanding layer.

References

1. 80% of features in the average software product are rarely or never used
2. Pendo’s 2019 Feature Adoption Report
3. “feature factory”
4. Jobs to Be Done framework
5. McKinsey’s Business Value of Design study
6. Product vs. Feature Teams
7. research cited in Harvard Business Review
8. Continuous Discovery Habits
9. feature factories
10. public cloud companies collectively spend $29.5 billion
11. top-quartile design companies
12. feature adoption benchmarking

Related

• Why AI Products Churn Faster Than SaaS
• When to Add Personalization to Your AI Product
• Shipping Fast in the Wrong Direction