Time to value: The clock starts before your signup form

Your analytics start the clock at account creation. The user started it days earlier, when they decided the problem was worth solving, asked a manager for approval, or waited for IT to unblock the domain.

Time to value measured from signup and reported at the median hides both ends of that wait. The median describes the person who was always going to be fine. Neither number points at anybody you could have saved.

What is time to value?

Time to value is the gap between a user deciding to try your product and getting something out of it. It is the speed dimension of activation: the aha moment says which outcome counts, this says how long people wait for it, and both sit at the Activate stage of the flywheel.

It is worth splitting into two, because they move for different reasons and only one of them predicts retention.

First value is the earliest moment the product does something real. A recording made, a link generated, a correction suggested. It gets a user through the door.

Value worth keeping is the moment losing it would annoy them. The recording got watched and somebody replied; the scheduling link saved a week of back-and-forth. That is what makes them stay.

Measuring only the first builds products that impress people once.

The clock starts before your signup form

Whatever you measure from signup, the user is counting from earlier. And several of the slowest parts of the experience sit outside the window most analytics tools default to:

Waiting for permission. None of it happens inside your product, and all of it is part of the user’s experience of your speed. A corporate card is often the slowest link. This is why being adoptable without permission is a speed feature as much as a distribution one.

Gathering what you asked for. If a product needs data the user does not already have, its time to value is however long they take to find it. That is often days, and it will not appear in your funnel because they never came back to fail.

Waiting for other people. Anything requiring a colleague inherits that colleague’s calendar.

So the honest measurement runs from first contact to first value, and the honest question is not “how many steps is our onboarding” but what is the longest thing a user has to wait for, and can we remove the waiting rather than the steps.

What the research actually supports

The target most often quoted for this is meaningful value inside five minutes. It circulates as a convention with no study behind it, and it is worth replacing with something better founded.

Jakob Nielsen’s response-time limits, set out in Usability Engineering in 1993 and building on work by Miller in 1968, put the numbers far lower: 0.1 seconds for a system to feel instantaneous, 1 second for a user’s train of thought to survive the wait, and 10 seconds as roughly the limit for holding attention on a task at all. Past ten seconds people start doing something else, and need telling when you expect to be finished.¹

Those are limits for single interactions, not for onboarding, so none of them is a target for time to value. What they establish is the scale. Attention research puts the threshold at seconds; typical onboarding is measured in minutes, which is orders of magnitude past anything the evidence supports. That is a better reason to shorten it than a five-minute rule of thumb nobody can source.

Report the distribution, never the average

The median tells you about the user in the middle, who is generally not in trouble. The people who churn on speed are in the tail: the ninetieth percentile, whose first value arrived after forty minutes rather than four, or never arrived at all.

Three habits follow from that:

Watch P90 alongside the median. A median of three minutes against a P90 of forty-five, to invent a shape, means one in ten users is having a completely different experience of your product from the one you think you shipped.

Count the people who never reach value at all. They are usually excluded from a time-to-value average by definition, since they have no value timestamp. That exclusion quietly removes the worst cases from the metric designed to find them.

Split by segment before drawing conclusions. A slow P90 is frequently one identifiable group (a company size, an integration, a country) rather than a general problem, and the fix is correspondingly specific.

The floor is set by what you need from the user

You cannot be faster than the information the product requires, which means most real gains come from reducing the dependency rather than trimming the flow.

The mechanical version is to put every step of onboarding through three questions, in this order:

Can it go? Does the user need this at all before first value. Can the system do it? Rather than asking them. Can it wait? Until after value has been delivered.

Most flows lose a surprising share of their steps to those three questions, and whatever survives is the real floor. Beyond it, five moves in rough order of effect:

Supply the data yourself. Sample content, a working template, a populated example. This turns “I need to gather things before this is useful” into “I can see it working now,” and it is why what goes on an empty screen determines so much of this number.

Defer everything not needed for the first outcome. Which setup steps are load-bearing and which merely feel mandatory is a question with a precise answer, and answering it is the whole of this move.

Default aggressively. Every choice you ask a new user to make is a pause; a good default is a decision you made on their behalf with more information than they have.

Verify after value, not before. Email verification, mandatory profile fields and forced tours all sit between signup and the thing the user came for, and each is a place to leave. If something is needed for your records, not for the user’s first outcome, collect it afterwards: a gate that gives the person passing through it nothing is pure loss, and it is usually there for an internal reason nobody has revisited.

Do the setup for them where you can. Import from the tool they are leaving, detect what you can detect, pre-fill from what they told you at signup. The best version of this is invisible.

The products usually held up as fast work this way rather than by being simpler: a video tool that records without configuration, a scheduling tool that asks for a calendar connection, a writing assistant that starts working in a text field the user was already typing in. In each case the product asks for almost nothing before it does something.

When speed is the wrong thing to optimize

Not every product should chase this, and pushing it too hard has a failure mode of its own.

A product whose value genuinely requires accumulated data cannot deliver it in minutes, and pretending otherwise produces a hollow first experience: something that looks like value and is not, which costs you credibility rather than time. The right move there is to be honest about the horizon and to make the first step satisfying while the real payoff builds.

The opposite case exists and is worth knowing. Some products deliberately add setup because it produces a better-activated user: requiring a workspace and an invited colleague before anything works costs minutes and guarantees that whoever gets through has the context the product needs. That is friction as a filter, and it is defensible when the product genuinely does not work alone.

There is also a version of fast that is worse than slow. Rushing a user past the setup that would have made the product work for them buys a fast first session and a bad second one. Speed matters because waiting causes abandonment, not because speed is a virtue in itself.

Check yourself against how you actually lose people: if they get through onboarding and disappear later, this is not your problem. That is a habit problem or a churn problem, and shaving seconds off the first session will not touch it.

What to track

1. Time from first contact to first value, at P50 and P90. Two numbers, same definition, dated. The gap between them is the size of your opportunity.
2. The share who never reach value, reported alongside, so the metric cannot flatter itself by excluding failures.
3. Time to value worth keeping as a separate series. It moves for different reasons and it predicts retention better.
4. The longest single wait in the path, named and owned. Expect one step to dominate, and expect it to be something nobody has looked at in a year.

Time to value has its own version of the denominator problem: the number depends entirely on where you start the clock, and every company starts it somewhere else.² The comparison that works is against your own last quarter, and against however long the three closest competitors take when you time them with a stopwatch.

Fix the longest wait first

1. Time it from the outside, as a stranger, twice, at different times of day.
2. Write down every dependency on something the user has to supply, decide or wait for. That list, not the click count, is the real map.
3. Remove one dependency by supplying the data, defaulting the choice, or importing it. Then re-time.
4. Switch your reporting to P50 and P90 and add the never-reached count.
5. Instrument time to value worth keeping, even crudely, because it is the number that connects speed to retention.

Speed gets somebody to value once, on Monday. Whether they are still getting it on Thursday is a separate question with separate answers, and the version of it with the most money attached is people leaving after they have already paid: preventing churn is where activation work either compounds or evaporates.

Updated August 2026