The support dashboard says 98% of tickets resolved within SLA. The product dashboard says feature X has 64% adoption. The metrics look healthy. Then a quarterly review reveals that customer effort scores are slipping, NPS is drifting down, and the support team is quietly handling the same five questions hundreds of times a month. Both dashboards were technically correct. Both were missing the picture.

Mayuri Dekate calls this friction debt: the accumulated cost of recurring user friction that gets resolved at the ticket level but never gets fixed at the product level. Like technical debt, it does not break anything individually. Like technical debt, it compounds silently until it limits everything.

When resolution looks like success

Resolution and improvement are not the same thing. A support ticket gets closed when the user's immediate problem is solved. The underlying cause of the problem usually remains. The next user hits the same friction, opens a similar ticket, gets a similar resolution. The system feels like it is working because each ticket has an answer. The product is silently accumulating debt.

Resolution is not the same as improvement. When you confuse the two, you begin accumulating what I call friction debt.

What support sees that product often misses

Support teams sit on the most concentrated source of product friction data in the company. Every ticket is a small signal: this thing was confusing, this thing did not work as expected, this thing took users longer than it should have. The signals stay in the support tool because the product team is busy looking at adoption metrics and feature usage.

The gap is structural. Product analytics measure behavior (did the user click?). Support tickets capture comprehension (did the user understand what to click?). The two answer different questions, and most product teams optimize for the first while ignoring the second.

Why dashboards give you false confidence

Common metrics that hide friction debt:

  • Feature adoption %. Counts who used the feature. Does not count who tried and failed.
  • DAU/WAU. Counts active users. Does not count users who became active despite friction (and will churn faster).
  • Time on page. Counts engagement. Does not distinguish engagement from confusion.
  • Ticket resolution rate. Counts closed tickets. Does not count the same problem appearing 200 times.
  • NPS averaged quarterly. Smooths over the friction patterns visible in detractor verbatims.

None of these metrics are wrong. They are insufficient. Without complementary signal from support patterns, they create a story of health that the lived user experience contradicts.

The friction gap, illustrated

Imagine a product launches a new feature. Day 1 analytics:

  • Feature adoption: 42% in week 1 (great)
  • Average session length: up 8% (great)
  • Activation metric: hits target (great)

Meanwhile, in support:

  • 67 tickets in week 1 with variations of "I turned the feature on but nothing happened"
  • Resolution: 4-minute reply explaining the additional step nobody knew about
  • Ticket closure rate: 100%

The dashboards say success. Support is handling daily confusion. The product is technically working but is silently teaching users that this team ships things that need explanation. Two quarters later, this is the friction debt that explains why NPS dropped and why the next launch lands flatter.

Silent friction is more dangerous than loud failure

A feature that crashes generates a flood of tickets, leadership attention, and a fast fix. A feature that confuses generates a slow trickle of tickets, none of which look urgent individually, and a long-term decay in trust. The crash gets fixed in a week. The confusion accumulates over months.

This is why silent friction is the dangerous kind. It does not trigger the systems that fix things. It triggers the systems that close tickets one at a time forever.

How to actually reduce friction debt

1. Make support a roadmap input, not a separate function

Once a month, the support lead presents the top 10 recurring ticket patterns to the product team. Not aggregate metrics. Specific patterns: "23 tickets this month about confusion at step 4 of onboarding." Each pattern goes into roadmap consideration with the same weight as a feature request from sales.

2. Define and track friction debt explicitly

Add a friction debt list to the roadmap, parallel to the feature backlog. Each item names a recurring pattern, the ticket volume it generates, and the proposed product-level fix. Treat it like technical debt: allocate quarterly capacity to paying it down.

3. Stop celebrating resolution metrics alone

Support team metrics should include "reduction in recurring ticket patterns" alongside "resolution time." A support team that resolves the same problem 100 times is doing heroic work in a system that is failing them. Measure success by problems that stopped recurring, not just tickets closed.

4. Use support transcripts in product reviews

Once a quarter, the product team reads 30 support transcripts as a group. Not metrics about transcripts. Actual transcripts. Notice the language users use, the points where confusion appears, the moments where they give up. This single practice changes more roadmap decisions than any analytics dashboard.

5. Audit feature launches at 30 and 90 days for friction signal

The launch metric should not just be "did adoption hit X%?" It should be "did adoption hit X% without generating Y volume of confusion tickets?" A launch that adopts well but creates a chronic support pattern was not a clean success.

The takeaway

Resolved tickets do not mean a healthy product. They mean a competent support team holding the line against accumulating product friction. The friction debt below the surface is what slows the next year of growth. The fix is structural: make support patterns a roadmap input, track friction debt explicitly, measure recurring problems alongside resolution speed, read transcripts as a team, and audit launches for confusion patterns. The metrics that look healthy stop being your full picture. The product that emerges is the one users actually enjoy using, not the one the dashboards say is fine.