When we started building Onboardvue, we tracked the usual suspects: signup rate, activation rate, Day-7 retention, Day-30 retention. All useful, all lagging. By the time those numbers moved in the wrong direction, the user had already decided to leave. We needed something earlier.
After about six months of running behavioral event data through our own churn model, one signal kept surfacing above the others: the time between account creation and the moment a user got genuine value from the product for the first time. We call it time-to-value, and it's now the core input to almost every nudge and intervention we send.
This post explains what we mean by time-to-value, why it outperforms most other early metrics as a churn predictor, and where the metric breaks down.
What "value" actually means in this context
Before you can measure time-to-value, you need to define the value event. This is harder than it sounds. Most teams pick something like "user completed onboarding" or "user visited the dashboard." Those are activity metrics, not value metrics.
A value event is the moment the product did something for the user that they could not have easily done without it. For a project management tool, that might be the first time a teammate comments on a task the user created. For a data pipeline product, it's the first successful run that loaded records into a destination. For Onboardvue, it's the moment a product team sees their first behavioral cohort with a complete activation funnel view.
The test we apply: if the user closed the tab at this moment and came back the next day, would they be thinking about what the product showed them? If yes, that's your value event. If they'd barely remember the session, you're still measuring activity.
Getting this definition right is almost always a qualitative exercise first. Interview your best-retained users and ask them to describe the moment the product clicked. The common themes become your candidate value events. Then instrument them and validate with retention data.
The six-month pattern we kept seeing
Looking across our beta cohort over roughly six months, a clear shape emerged. Users who reached their value event within a certain window had dramatically better 60-day retention than users who took longer or never got there.
We're deliberately not publishing specific percentages here, because the numbers vary a lot by product type and user segment, and we don't want people anchoring on our cohort as a benchmark. But directionally: the difference between "reached value in session 1 or 2" versus "reached value after session 5" was larger than we expected, and larger than the difference between other early behavioral signals we tracked.
More importantly, the relationship was nonlinear. It wasn't that slower time-to-value predicted slightly worse retention. There was a threshold effect: once a user crossed a certain number of sessions without a value event, their probability of converting to paid dropped sharply. The slope of churn risk didn't gradually increase. It stepped up.
That threshold shape is what makes time-to-value useful as an intervention trigger. If churn risk increased smoothly with time, you'd need to intervene for everyone at every moment. With a threshold, you can set a window, watch who is approaching it without hitting the value event, and send a targeted nudge.
Why time-to-value outperforms engagement proxies
Teams often track session count or feature usage breadth as early activation proxies. Both correlate loosely with retention, but they're noisy. A user can log three sessions, click through six features, and still be confused about what the product is actually for. High engagement without value delivery is worse than low engagement with value delivery, because engaged-but-confused users spend effort and leave frustrated.
Time-to-value cuts through that noise because it's anchored to an outcome, not an activity. You're not measuring whether the user is busy inside the product. You're measuring whether the product produced the thing the user came for.
We're not saying engagement metrics are useless. Session depth, feature touch breadth, and invite-a-teammate behavior are all real activation signals. They help us understand what users are doing. Time-to-value tells us whether what they're doing is working. These two classes of signal should run in parallel, not in competition.
The segment problem
One of the first mistakes we made was treating time-to-value as a single number. We'd set a threshold, watch for violations, and fire nudges. What we found is that the appropriate window is quite different across user segments.
Consider a simple case: a PLG SaaS product where some users sign up as solo practitioners and others sign up as admins setting up an account for their team. The solo user can get to a value event in their first session. The admin user needs to invite teammates, wait for someone to accept, and potentially configure integrations before the product can do its real job. Time-to-value for that admin might legitimately be four or five days.
If you fire a "we noticed you haven't gotten full value yet" nudge to the admin user on day two, you're flagging a non-problem and making your product feel like it's watching them too closely. If you don't send anything until day five for the solo user, you've already lost them.
The practical fix is to segment your time-to-value thresholds by user type, ideally collected at signup or inferred from early behavioral signals. In Onboardvue, we use the signup question flow to set the initial segment, then update it based on observed behavior. An admin who invites three teammates in session one gets a different threshold than one who hasn't sent a single invite.
How we use time-to-value as a nudge trigger
In our system, time-to-value runs as a continuous watch per user. We track whether the value event has fired. We know the user's segment and the corresponding window for their segment. As a user approaches the window boundary without a value event, we increase the nudge signal strength.
We don't send a generic "reminder" push. The nudge content is specific to where the user is in the product journey. If they've created content but haven't connected a data source, the nudge surfaces the integration step and explains what becomes possible once it's connected. If they've done the setup but haven't explored the core report view, the nudge links directly to it with a one-sentence description of what they'll see.
We've found that nudge specificity matters as much as timing. Sending "hey, don't forget to check us out!" at the right moment is less effective than sending a message that references exactly what the user has done and points to the one step they haven't.
Where the metric has limits
Time-to-value is a strong predictor, but it has meaningful edge cases worth acknowledging.
First, some products have genuinely long setup curves. A complex analytics platform that requires data warehouse connection and schema configuration might have a legitimate 10-day time-to-value for the average user. The metric isn't broken in those cases, but your threshold needs to reflect the product reality, not a generic "get to value fast" instinct.
Second, time-to-value doesn't distinguish between "user hasn't gotten value because the product is hard" and "user hasn't gotten value because they got distracted." Both look the same in the data. You need qualitative research or explicit exit surveys to separate those cases, especially when you're iterating on the onboarding flow itself.
Third, repeat-value delivery matters for long-term retention, and time-to-value only measures the first event. A user who gets value quickly but then experiences a dead end in week three may churn anyway. We track a metric we call value recurrence, which counts value events per 7-day window. Users who show high recurrence are substantially more likely to stay past month two. Time-to-value gets them to activation; value recurrence tells you about stickiness.
None of these limits mean you should swap out time-to-value for something else. They mean you should build a signal stack: time-to-value for early intervention, value recurrence for medium-term health, and behavioral cohort analysis for understanding what's working structurally.
Getting started with a narrow definition
If you're not currently measuring time-to-value, the path in is narrower than people expect. You don't need a complex event taxonomy on day one. Pick one candidate value event, instrument it, and start tracking the distribution of how long it takes users to hit it. That distribution alone will tell you a lot.
Look at the users who hit it fastest. What are they doing differently in sessions 1 and 2? That behavioral pattern becomes your optimization target. Then look at users who take more than twice the median time. Are they bouncing from a specific step? That friction point is your next product fix.
The goal isn't to have a perfect metric definition before you start. It's to get a working instrument in place so the data can correct your assumptions. In our experience, the first version of a value event definition is almost always wrong in some small way, and the data shows you how to fix it.