When Two AI Features Compete for the Same Click

A user lands on a search results page. Team A's smart summary fires in the top banner: "Here's the gist — skip the list." Team B's inline assistant pulses on the side: "Stay here, I'll keep reading with you." Both prompts compete for the same 800ms of attention, and the user — annoyed — closes the tab. The next morning, Team A reports a 6% lift in summary clicks; Team B reports a 4% lift in assistant opens; nobody in the room is wrong, and the product is worse than it was a quarter ago.

This is the failure mode that the standard playbook of independent feature teams and per-feature A/B tests cannot see. Each team locally optimized against its own metric. The user — who only has one attention budget, one mental model, and one click to give — paid the bill for the integration both teams declined to do.

The shape of the problem is not new. Product cannibalization has been a portfolio concern for decades in retail and pricing — what's new is that AI features cannibalize each other in a much subtler currency than revenue. They cannibalize attention, intent, and the user's willingness to trust any AI surface in your product. And the metrics that would have flagged the conflict don't exist at the team level, because they cannot exist at the team level.

Why Local A/B Tests Cannot Detect This

An A/B test is a comparison between a treatment group and a control group, holding everything else equal. That "everything else equal" clause is doing a lot of work, and it quietly breaks when two AI features ship into overlapping surfaces.

When Team A runs a test on its summary banner, the control arm has no summary banner — but it still has Team B's inline assistant. When Team B runs a test on its assistant, the control arm has no assistant — but it still has Team A's summary banner. Both teams measure their feature against a background that includes the other team's feature. Each test answers a narrow question: "Does my feature add value on top of the current product?" Neither test answers the broader question: "Is the current product better than the product where one of us doesn't ship?"

There's a real possibility — and in practice, a common one — where both features pass their independent A/B tests and the combined experience is worse than either feature alone. The math is not exotic. If feature A creates +6% engagement against a baseline that already includes feature B, and feature B creates +4% engagement against a baseline that already includes feature A, you cannot add them. You may not even be able to keep one of them once you account for the user friction the other introduced.

The platform A/B test that would detect this — a four-arm test of (neither, A only, B only, both) — is rarely run, because it requires coordination between two teams who have no reason to coordinate. Their goals, their sprint cycles, their OKRs, and often their VPs are different.

Each Team's Win Is the Other Team's Loss

The harder version of this problem is that the two teams are not just failing to coordinate — they are structurally incentivized to disagree. Their metrics are mirror images.

Consider the smart-summary team. Their thesis is that the user should not read the result list — the summary captures the gist, the user accepts it, the user moves on. The right success metric for them is something like "summary acceptance rate" or "time-to-answer," and both metrics improve when the user spends less time scrolling.

Now consider the inline-assistant team. Their thesis is that the user should engage deeply with the current page — the assistant comments, asks questions, surfaces related context, and keeps the user reading. The right success metric for them is "session depth" or "time-on-page," and both metrics improve when the user spends more time engaging.

The user only does one thing. Either they accept the summary and leave, or they engage with the assistant and stay. Whichever happens, one team's metric moves up and the other's moves down. The two teams are running a zero-sum competition disguised as parallel feature work. And because neither team's dashboard shows the other team's metric, they each see only their share of the move — which means both teams can simultaneously believe their feature is succeeding even when one is clearly winning the user from the other.

This is what local optimization looks like when the local optimum is structurally incompatible with the other team's local optimum. It is not a bug in any individual team's process. It is a missing layer of organization.

The Missing Forum

Most engineering orgs have a forum for resolving conflicts in the data layer ("who owns the customer table?"), a forum for resolving conflicts in the infra layer ("who pays for this compute?"), and a forum for resolving conflicts in the brand layer ("does this UI match our voice?"). Almost none of them have a forum for resolving conflicts in the attention layer — the layer where two product surfaces compete for the same instant of user focus.

The closest analogue is a design review, but design reviews tend to evaluate the aesthetic and ergonomic quality of one surface in isolation. They are not set up to ask: "Of the 800ms the user spends on this page, which feature has earned the right to fire first?" They are not set up to issue rulings like "the inline assistant cannot pulse while the summary banner is animating in" or "no AI surface may interrupt during the first 1.5 seconds of a page load."

The forum that's needed is closer to what air traffic control is to airports. Each individual aircraft is fine. Each individual pilot is competent. The job of the controller is to sequence them — to decide who lands, who takes off, and who circles, because the runway is a shared resource and the planes do not negotiate with each other. AI features inside a product are exactly this: each is competent on its own, and the user's attention is the runway.

In practice this forum looks like a small, recurring meeting — sometimes called an AI portfolio review, an experience council, or an interaction budget review — owned by a senior product lead who has authority over multiple AI-feature teams. The agenda is the set of moments where two or more AI features could fire. The output is a sequencing decision, a yielding rule, or in the hard cases, a directive that one feature must move to a different surface entirely.

Attention-Budget Accounting as a Portfolio Concern

Once you have the forum, the question becomes what you measure inside it. The team-level dashboards are not enough — they are precisely what got you into the conflict in the first place. The portfolio needs its own instrumentation.

A useful starting point is to think about attention the way a finance team thinks about a budget. Each user session has a finite supply of moments where the product can intrude — the page load, the result render, the search submit, the idle pause, the back-button press. There are perhaps a dozen such moments per session, generously. Each AI feature is an outgoing line item against that budget. The portfolio question is: "Of this session's twelve intrusion-eligible moments, how many did we spend, on which features, with what return?"

Three metrics tend to be worth tracking at the portfolio level:

• Cross-feature collision rate: how often two or more AI surfaces fire within the same 2-second window. This is the metric that, when it goes up, makes both team-level dashboards look healthier while the user experience degrades.
• Per-moment net value: across all features that could fire at a given moment, what was the user's downstream behavior — did they engage, did they leave, did they return? This is measured per moment, not per feature, which is the point.
• Yield rate: how often a feature chose not to fire because another feature had priority. A healthy portfolio has a nonzero yield rate. A yield rate of zero means no feature is deferring to another, which means the runway is being treated as unlimited — and it is not.

These metrics are visible only at the portfolio layer. No team-level dashboard contains them, because no team owns "the user's session" in aggregate. Someone has to own that view explicitly, or it does not exist.

The Leadership Move

The leadership realization, when it happens, is that the team-level success metrics that built the AI features are now the things preventing the AI portfolio from cohering. Every individual team is doing what their manager asked. Every individual feature passed its launch criteria. And the combined product is fragmented, loud, and slightly hostile to the user who is trying to do one thing.

The move that surfaces this — before the users do — is to elevate the question of "which feature owns which moment" from a coordination accident to a deliberate review. That means a forum, a portfolio-level metric set, and a senior product owner with the authority to tell a team: "Your A/B test passed, and we are still not shipping this in that surface, because the surface already has an owner."

That conversation is uncomfortable. It overrides a local win in service of a global one. It tells a team that did good work that their work cannot ship in the form they built it. It also is, in 2026, one of the few organizational practices that distinguishes companies whose AI features compound into a coherent product from companies whose AI features compound into a coherent mess. The teams keep shipping; the difference is whether anyone is sequencing the runway.