The aggregate signal stayed green. The cohort signal, if anyone watched, went red.
Feature Cannibalization, How to Tell If Your New Feature Is Growing the Product or Eating It
Telemetry-based approach to distinguishing whether a new feature creates net-new user value or redistributes existing engagement from the core loops that made your product work. Most teams celebrate new feature engagement without asking what it replaced, this is a measurement culture problem, not a product problem.
A new feature that wins on engagement metrics while silently dismantling the retention loop that drove your product's growth is not a product success, it is a measurement failure dressed up as a launch.
Who This Is For
You are running a product with established core loops, features that users return to repeatedly, that drive retention, and that anchor revenue. Your team ships a new capability. The dashboard goes green. This article is for the PM who is not sure the dashboard is asking the right question.
You need: basic event instrumentation, cohort analysis access, and the authority or influence to define metrics before a feature launches rather than after you need to explain a retention drop.
The Problem Nobody Defines Before Launch
Every team measures whether a new feature gets used. Almost no team measures what the new feature displaced.
The displacement question is harder because it requires you to hold two things in your head simultaneously: what users are doing with the new feature, and what those same users stopped doing because of it. Aggregate metrics, daily active users, session counts, feature adoption rate, will not show you this. They blend new behavior with substituted behavior and report a number that looks like growth.
This is not an instrumentation gap. It is a framing gap. The question "what did this feature replace?" is almost never written into a launch brief.
What PhonePe's UPI Lite Launch Revealed
PhonePe introduced Unified Payments Interface Lite in 2022 to simplify low-value transactions, payments under ₹500 processed offline, faster, with less friction. The product rationale was sound. Small-value transaction volume on the Unified Payments Interface network was growing rapidly, and reducing friction was the logical move.
Transaction volume increased. The feature activated at high rates. By aggregate metrics, this was a clean win.
What took several months to surface: within the cohort of existing users who adopted Unified Payments Interface Lite, engagement with PhonePe's savings and investment features dropped measurably during the same window. The simplified flow kept users in the payments surface. The reduced friction also reduced the moments where users would browse into adjacent financial products, the natural discovery path that had been converting payments-first users into investment users.
The cannibalization was not dramatic. It was a slow migration of session intent. Users who had been exploring PhonePe as a financial platform began using it as a utility again. New users, acquired because Unified Payments Interface Lite lowered the barrier to entry, eventually compensated for the cohort-level drop. But the existing cohort, which represented higher lifetime value, quietly shifted its engagement profile for months before anyone was measuring it.
The aggregate signal stayed green. The cohort signal, if anyone had been watching it, went red.
Three Cannibalization Signals You Need to Instrument
Signal One: Session Displacement
Session displacement asks whether time spent in the new feature is coming from somewhere or coming from growth.
You are looking at the same user, the same session window, and whether their total session depth changed or simply redistributed. If a user who previously spent twelve minutes per session, three in payments, nine exploring investments, now spends eight minutes per session with six in the new feature and two in investments, you do not have growth. You have reallocation.
The query you need: for users who activated the new feature in week one, compare their pre-activation session distribution across feature surfaces to their post-activation distribution. Run this at Day 14, not Day 1. Day 1 is novelty. Day 14 is habit.
Signal Two: Cohort Migration
Cohort migration tracks whether users who adopt a new feature shift their identity from one engagement tier to another.
Your product likely has implicit tiers, light users, core users, power users, defined by which features they use and how frequently. A user who was a core user because they engaged with three feature surfaces weekly may become a light user if the new feature collapses their engagement into one surface, even if their session frequency does not change.
The signal: segment your user base into engagement tiers before launch. After launch, track tier membership changes specifically within the adopter cohort. If 15 percent of your previous core users have migrated to light-user behavior patterns by Day 14, and that migration correlates with new feature adoption, you have cohort migration.
This signal is uncomfortable because it shows up in users who are technically "active." They are logging in. They are using your product. But they are using less of it in ways that matter for retention.
Signal Three: Revenue Attribution Confusion
Revenue attribution confusion occurs when a new feature claims credit for conversions that the existing product was already generating.
This is most common in products with upsell or cross-sell surfaces. If your core loop naturally drives users toward a premium conversion point, and a new feature intersects the same user journey at an earlier stage, your attribution model may begin crediting the new feature for conversions the core loop had already primed.
The signal: run a last-touch attribution comparison between the control cohort (users who did not adopt the new feature) and the adopter cohort. If the adopter cohort shows higher conversion rates but equivalent or lower revenue per converted user, the new feature is inserting itself into a conversion journey, not creating a new one.
Cannibalization Indicators vs Expansion Indicators
The distinction between a feature that cannibalizes and one that expands is empirical, not intuitive. It requires a specific set of event-level queries run against the right cohort at the right retention window.
| Dimension | Cannibalization Indicator | Expansion Indicator |
|---|---|---|
| Session depth at Day 14 | Total session time flat or declining in adopter cohort | Total session time increasing in adopter cohort |
| Feature surface breadth | Adopters use fewer surfaces post-activation than pre-activation | Adopters use equal or more surfaces post-activation |
| Cohort tier movement | Core users migrate toward light-user engagement patterns | Light users migrate toward core or power-user patterns |
| Revenue per user | Flat or declining in adopter cohort vs control | Increasing in adopter cohort vs control |
| Conversion path | New feature appears in attribution for pre-existing conversion journeys | New feature opens conversion paths that did not exist before |
| Retention curve shape | Adopter cohort retention curve diverges negatively from pre-launch baseline at Day 14 | Adopter cohort retention curve holds or improves vs baseline |
| Event query to run | SELECT user_id, feature_surface, SUM(session_seconds) FROM events WHERE cohort = 'new_feature_adopter' GROUP BY user_id, feature_surface, compare 14 days pre vs 14 days post activation |
Same query, same window, look for breadth increase, not surface concentration |
The Day 14 window is not arbitrary. Day 1 and Day 7 are contaminated by novelty behavior, users explore new features regardless of whether they find them valuable. By Day 14, users have either integrated the feature into a real habit or reverted to their prior pattern. If cannibalization is happening, it is visible by Day 14 and structural by Day 30.
The Counterfactual Metric: Define It Before Launch
The single most important thing a PM can do before shipping a new feature is define what success looks like for the features it might displace.
This is not complicated. It requires one additional line in the launch brief: "If this feature succeeds, here is what we expect to happen to [core feature] engagement in the adopter cohort, and here is the threshold below which we would call the net outcome a loss."
Without this line, you have no counterfactual. Without a counterfactual, you cannot distinguish cannibalization from expansion. You are measuring the new feature in isolation and calling it a launch verdict.
Defining the counterfactual before launch means you are committing to a specific observable outcome before the result is in the baseline. This is the only point at which you can do it cleanly. Once the feature has shipped and the data has settled into your normal reporting, the cannibalization pattern becomes the new baseline and the pre-launch state becomes a reference point you have to reconstruct from historical queries, if you archived the right data.
In the PhonePe case, the counterfactual would have been: "Existing users who adopt Unified Payments Interface Lite will maintain their current investment feature engagement rate (X sessions per week) at Day 14. A drop below Y sessions per week in this cohort, uncorrelated with market conditions, is a cannibalization signal."
Nobody had to build anything new to track this. The data existed. The frame did not.
The Judgment Turn
Here is the uncomfortable position: your team is not failing to detect cannibalization because your instrumentation is inadequate. You are failing to detect it because defining the counterfactual before launch is politically inconvenient.
It requires someone, usually the PM, to publicly commit to the possibility that the new feature could hurt the product. It requires writing down a threshold at which the launch would be classified as a net loss. In most planning cultures, that conversation does not happen. The launch brief defines success for the new feature. It does not define failure for the existing ones.
This is a measurement culture problem. The tools exist. The data is being collected. The question is whether anyone is required to ask it before launch, not after the retention anomaly lands in a quarterly review.
Teams that catch cannibalization early share one practice: they treat the core loop as a first-class metric with a defined owner, and that owner's sign-off on a new feature launch requires answering the displacement question explicitly. Not as a risk section in a launch doc. As a pre-defined metric with a threshold and a monitoring window.
Everything else is instrumentation. This is accountability structure.
Key Takeaways
- Aggregate engagement metrics will not show you cannibalization, they blend new behavior with substituted behavior and report a number that looks like growth.
- The three signals that reveal cannibalization are session displacement, cohort migration, and revenue attribution confusion, all measured at Day 14, not Day 1.
- The counterfactual metric must be defined before launch, with a specific threshold, or it becomes impossible to cleanly distinguish from the post-launch baseline.
- Cannibalization hides most effectively behind features that drive volume, because volume growth masks cohort-level engagement decline in aggregate dashboards.
- The measurement failure is a culture and accountability problem: teams do not define failure conditions for existing features when launching new ones, so nobody is watching the right signal.