Friction vs Heterogeneity: Two Very Different Product Problems

Most B2B SaaS teams that “care about onboarding” still make the same operational mistake: they see a slow Time-to-Value and immediately treat it as a throughput problem. The language gives it away—“remove steps,” “reduce clicks,” “shorten the flow,” “make setup faster.” The assumption is that users are stuck on the same obstacle, so shaving friction should move everyone left.

Sometimes that’s exactly right. Often it isn’t.

The harder case—the one that keeps fooling even mature teams—is when slow TTV is driven less by friction and more by heterogeneity: different users need different things, take different paths, and encounter fundamentally different amounts of work between signup and real value. When you misdiagnose heterogeneity as friction, you ship “simplifications” that reduce clarity, increase variance, and paradoxically make the slow tail worse.

The discipline here is distribution thinking. Friction and heterogeneity produce different shapes. They move different parts of the curve. And they demand different product moves.

The analytics trap that makes the mistake persist

Most teams review onboarding with two artifacts:

A funnel: signup → connect → invite → first project → “activated.”
A single time metric: average or median time from signup to activation/value.

This is clean, legible, and easy to operationalize. It also collapses exactly the information you need to distinguish the two problem types.

“What teams usually measure” is a scalar and a sequence: conversion rates between steps and a central tendency for time. “What actually matters” is the shape of time-to-value: where the mass sits, how wide the spread is, whether there’s a long tail, and whether cohorts/segments exhibit different distributions entirely.

If you only look at the median, two completely different realities can look identical:

Reality A: most users are blocked by one consistent constraint (friction).
Reality B: users are doing different kinds of work on different timelines (heterogeneity).

Both can yield “median TTV = 5 days.” Only one is solved by “remove a step.”

Mature teams persist in this mistake for structural reasons:

Dashboards reward certainty. A single number trends nicely and produces action.
Funnels imply a canonical path. They nudge you to interpret divergence as drop-off rather than alternative routes to value.
Optimization culture biases toward local fixes. It’s easier to remove friction in an existing flow than to redesign the product so different users reach value in different ways.
Instrumentation is rarely built for path variability. Many event models encode “the flow,” not the space of plausible paths.

So the team keeps treating a distribution problem as a pipeline problem.

Two problem types, one metric: why “slow TTV” is ambiguous

Let $T$ be a user’s time-to-value, measured as the elapsed time between a start timestamp (e.g., first meaningful intent signal) and the first value event that you can defend operationally.

A single statistic like $E[T]$ or $\text{median}(T)$ loses the question that matters: what is the distribution of $T$ and what mechanisms generate it?

At a high level, there are at least two generative stories:

Friction-driven TTV

Users broadly share a similar intent and value path, but something adds delay.

Mechanisms include:

avoidable steps, confusing UX, missing affordances
slow integration setup or permissions hurdles
unclear guidance causing retries
performance issues or waiting on an asynchronous process you control

The hallmark is that the same “wall” affects many users in similar ways.

Heterogeneity-driven TTV

Users differ meaningfully in what “value” requires and how much work is necessary to get—or recognize—it.

Mechanisms include:

different jobs-to-be-done requiring different configuration depth
varying data readiness (clean vs messy data, access constraints)
different stakeholder involvement (solo evaluator vs cross-functional rollout)
differing skill levels, compliance requirements, or procurement timing

The hallmark is that users are not on the same journey, even if they share a product.

Both can coexist. The point is diagnostic: if you treat heterogeneity like friction, you will optimize the wrong thing.

Distribution fingerprints: how the shapes differ

The simplest way to see the difference is to look at the full distribution via a CDF (cumulative distribution function): $F(t) = P(T \le t)$ .

A friction change tends to shift the curve left (faster for most users) and often preserves shape. Heterogeneity tends to create multi-modality (mixtures), fat tails, or segmentation where the overall curve is just an average of incompatible sub-curves.

Alt text

Read the shapes, not the legend:

The friction curve rises relatively smoothly and reaches high cumulative probability by day ~15; it’s “one story” with some variance.
The heterogeneity curve rises slowly early, then continues to climb without ever catching up; the slow tail is structural, not just “a few stuck users.”
The dashed segments show what the heterogeneity curve often hides: two different populations with different timelines. The aggregate is a mixture: $F(t) = p\cdot F_A(t) + (1-p)\cdot F_B(t).$ If you optimize the “average user,” you optimize no one in particular.

This is why funnel optimization so often disappoints. You can improve step conversion without materially moving the time distribution that matters.

How the wrong diagnosis leads to ineffective changes

A friction diagnosis typically yields changes like:

collapse steps
reduce required fields
add progress indicators
improve defaults
in-product guides
better performance

These are sensible. The failure mode is not that these changes are “bad.” It’s that they are orthogonal to the dominant variance driver when heterogeneity is the real issue.

If heterogeneity dominates, simplifying the flow can even backfire:

It removes disambiguation. You needed branching questions or setup choices to route users to the right path. Removing them makes the early experience faster but less correct.
It increases variance. Users self-navigate into mismatched configurations, which creates delayed failures. Your median might improve while your $P90$ gets worse.
It hides false activation. If you lower the bar for “activation,” you can inflate early completion while the true value event shifts right or becomes less likely.

A useful litmus test: if you ship onboarding “simplifications” and see early-step completion improve, but $P(T \le 7)$ barely moves and the long tail stays put, you probably didn’t have a friction problem. You had a heterogeneity problem—or a value-definition problem.

Reframing with distribution-based thinking

Stop asking “How do we make onboarding faster?” and ask two sharper questions:

Where is the mass of the distribution, and where is the risk?
For TTV, risk usually lives in the tail. The median is often fine; the $P75$ – $P95$ region is where expansion dies.
Is the spread explainable by a shared mechanism or by population mixture?
In practice, this becomes: do we see a relatively stable curve that shifts, or do we see a curve that changes shape across cohorts/segments?

A distribution-first approach also forces you to be explicit about what improvement means. “Faster” can mean:

higher $F(7)$ (more users reaching value within 7 days),
lower $P90$ (tail compression),
reduced variance $\operatorname{Var}(T)$ (more predictable outcomes),
or a left shift of the whole curve.

Those are different product goals with different trade-offs.

Applying Watch → Understand → Improve

This is where Tivalio’s framing is genuinely useful—not because it’s a “process,” but because it forces the right sequencing. Diagnosis before optimization.

WATCH: Surface the current reality of TTV

Start with the distribution, not the average.

Look at:

CDFs over time
percentiles: $P50, P75, P90, P95$
tail mass: $1 - F(t^\*)$ for your acceptable window $t^\*$ (e.g., 14 days)
cohort shifts: week-over-week or release-over-release curve changes

A friction-driven regression often looks like a consistent right shift: $F_{\text{new}}(t) < F_{\text{old}}(t)$ for most $t$ , with similar curvature. Heterogeneity issues often show shape change: early progress looks similar but the tail thickens, or there’s a kink where a subgroup “drops behind.”

Watch should also make “false activation” visible. If your activation proxy is upstream of true value, you’ll see a suspicious pattern: activation time improves while value time doesn’t. The delta between proxy and value becomes part of the distribution story.

UNDERSTAND: Explain why TTV looks the way it does

This step is about conditioning and mixture detection.

Instead of “What is overall TTV?”, ask “What is TTV given $X$ ?”: $F(t \mid X=x) = P(T \le t \mid X=x).$

Pick segment variables that plausibly represent heterogeneity, not just demographics:

product intent (what they did first, what feature they touched)
data readiness signals (connected source type, record counts, schema complexity)
company topology (single-user eval vs multi-user workspace)
integration surface area (one connector vs many)
role or persona if it maps to different workflows

If the overall curve decomposes into distinct conditional curves, you’re looking at heterogeneity. If conditional curves are similar but shifted by a consistent amount, you’re likely looking at friction.

Then go one level deeper: path analysis in time, not funnels as a fixed sequence. You’re trying to identify divergence points—moments where users’ trajectories separate into different time regimes.

A practical diagnostic pattern:

Friction: many users pile up at the same time window after the same event. You see density around a bottleneck interval. Removing it moves many percentiles.
Heterogeneity: users who reach value late are not “stuck at step 3.” They are doing different sequences (or waiting on different externalities). The late group’s preceding events differ qualitatively.

One useful decomposition is to separate “product-controlled time” from “externally constrained time.” Even a crude split helps: $T = T_{\text{in-product}} + T_{\text{waiting}}.$ If $T_{\text{waiting}}$ dominates the tail and is correlated with segment variables (procurement, approvals, data access), simplifying UI won’t touch it. You need product moves that reduce dependency or create interim value earlier.

IMPROVE: Connect insights to concrete product decisions

Once you know whether you have friction or heterogeneity, the solution space changes.

If it’s friction-driven

You can justify investments that aim for global left shift and tail compression via removing a shared constraint:

eliminate redundant steps that most users must complete
improve defaults where misconfiguration causes retries
reduce latency or asynchronous processing time
tighten copy and error handling where users churn time
make the “next right action” unambiguous

The key is to measure success as a curve movement, not a step conversion. A meaningful outcome is something like:

$F(7)$ increases by 10 points and $P90$ decreases, not “step 2 completion went up.”

If it’s heterogeneity-driven

The goal is not to make “the flow” shorter. The goal is to make value reachable across different legitimate paths, and to reduce variance by routing users earlier.

Typical moves are structural:

Early routing, not early completion. Add questions or signals that branch users into the right setup path. This can increase early friction while decreasing tail time. That trade can be correct.
Multiple value milestones. If true value requires heavy setup for some segments, create an earlier, defensible “first value” for them—without lying to yourself. This is about staging value, not redefining it to look good.
Segment-specific onboarding. Different connectors, templates, recommended defaults, and success criteria. One onboarding is often a tax on everyone.
Design for external dependencies. If waiting on approvals or data access is common, build mechanisms that let users progress: offline configuration, simulated data, parallelizable tasks, clearer delegation flows.

Heterogeneity also forces a strategic implication: you may be serving multiple products under one UI. If the distributions remain bimodal even after routing, you might have two distinct value propositions that warrant separate experiences—or even separate packaging and sales motions.

A concrete example of “wrong fix, worse tail”

Imagine a platform where “value” is defined as the first time a team member uses an automated report in a live workflow. The team notices median TTV increased from 4 to 6 days. They simplify onboarding: fewer required fields, fewer steps, a faster “finish” screen.

Results:

Activation proxy time drops from 30 minutes to 10 minutes.
Median TTV improves slightly: 6 → 5.5 days.
$P90$ worsens: 18 → 24 days.
Support tickets rise: users misconfigure, invite the wrong roles, or connect incomplete data.

This is classic heterogeneity misread as friction. The “slow users” weren’t blocked by the same steps; they were dealing with data access, cross-team coordination, or a deeper configuration path. The simplified onboarding removed the guardrails that previously helped the complex cases succeed.

A distribution-first team would have noticed that the median moved, but the curve’s curvature changed: the tail got heavier. They would have treated the regression as a predictability problem, not a speed problem.

What to operationalize going forward

If you want a simple rule that prevents the mistake: stop debating onboarding changes without looking at at least two percentiles and one CDF overlay.

If $P50$ and $P90$ both improve meaningfully, you likely removed friction.
If $P50$ improves but $P90$ stays flat or worsens, you likely increased heterogeneity costs (or created false activation).
If the curve decomposes into stable segment curves with very different shapes, you’re managing a mixture, not a single experience.

And if you can’t explain your tail, you don’t understand your product yet—no matter how clean your funnel looks.

Conclusion

Slow time-to-value is not one problem. It’s an ambiguous symptom that can come from shared friction or from legitimate heterogeneity in what users need to do to reach value. Those are different realities, with different distribution fingerprints and different product moves.

The practical risk is not that teams fail to optimize; it’s that they optimize confidently in the wrong direction—reducing surface friction while increasing variance, masking false activation, and leaving the real constraints untouched.

The antidote is to treat TTV as a distribution and to sequence the work: Watch the shape, Understand the mechanisms and mixtures behind it, then Improve with changes that match the diagnosis. This is the kind of analysis Tivalio is designed to support: not reporting that TTV moved, but explaining why it looks the way it does and what structural changes will actually move the curve you care about.