Time-to-value, in seconds: a measurement primer

Time-to-value is the most-cited metric in onboarding decks and the least-measured one in actual products. Almost every team can name it. Almost none of them have a chart of it open in a tab right now.

That gap is not an oversight. Time-to-value is annoying to measure properly, and the easy ways to measure it are the wrong ways. This is a primer on the measurement, not the concept.

What you're actually measuring

Time-to-value is the elapsed time, per user, between two events:

1. Sign-up (or whatever you've defined as the start of the funnel — first dashboard load, first authenticated request, etc.)
2. First meaningful action — the moment the product has done something for the user they couldn't have done otherwise.

The "meaningful action" half is where most of the difficulty lives. "Loaded the second page" is easy to measure and useless. "Created a project, added a task, invited a collaborator" is more meaningful but compound, which makes the time bucket fuzzy. Pick one terminal event per product surface, and define it before you start querying.

Why per-user matters

Every team's first instinct is to chart median time-to-value. Median time-to-value is a perfectly reasonable summary statistic and a terrible operational metric. It hides three things you need to see:

• Users who never reach value at all. They have no time-to-value, so they get dropped from the median entirely. The median is computed only over the activated subset, which means the metric improves as you lose more of the people you wanted to help.
• Bimodal distributions. Lots of products have two populations: power users who reach value in 30 seconds, and everyone else who takes 30 minutes or never gets there. The median sits in the empty middle and describes neither.
• Cohort drift. A median across all-time users will move slowly even when this week's signups are dramatically worse off. You want time-to-value plotted by signup cohort, week-over-week.

The chart you actually want is a survival curve: x-axis is seconds since signup, y-axis is the percentage of users who have reached value by that point. Each cohort gets its own line. The shape of the curve tells you what's happening; a single number tells you nothing.

How to instrument it without a data team

If you don't have a dedicated analytics engineer, the cheap version is:

• Pick the two events. Log them with timestamp + user ID + cohort label (signup week is fine).
• Dump them to whatever store you already have (Postgres, BigQuery, even a spreadsheet for the first 1,000 users).
• Compute, per user: time between event 1 and event 2; null if event 2 never fired.
• Plot as a survival curve, one line per cohort.

That's it. There is no step where you need a vendor. The vendors sell you a dashboard with a single number on it; the single number is what you were trying to escape.

In BreakGround

BreakGround's event pipeline captures the underlying activation events automatically — first signup, first action, first repeat session — so you can build the survival curve without instrumenting from scratch.

See event ingestion →

The benchmark trap

Someone on your team will ask "what's a good time-to-value?" The honest answer is that the question is malformed. A 90-second TTV is excellent for a writing tool and embarrassing for a calculator app. The benchmark that matters is your own week-over-week movement.

If you must compare yourself to something external: compare to the workaround your users would otherwise be using. If your TTV is 90 seconds and the workaround takes 4 minutes, you're winning. If the workaround takes 30 seconds, you're not.

What the curve will tell you

Once you've got a survival curve plotted by cohort, you'll start seeing the same three patterns most products see:

• A steep drop in the first 30 seconds (people bouncing before they got anywhere).
• A long flat tail (people stuck partway).
• A small late-spike (people coming back hours or days later to finish).

Each of those is a different design problem. The first is a first-impression problem — the wrong landing surface, the wrong default empty state, the wrong invitation to act. The second is a friction problem — a step in the funnel that everyone gets to and nobody completes. The third is a follow-up problem — and it's the one that vendors will sell you the most product around, because email is easy to ship.

Most teams measure none of this and ship for the third bucket. The first two are where the leverage is.