Time to Value

Metric

The time from sign-up until a user first feels the product is useful, reported as a median across users.

Why it exists

For a long time the number product teams carried around was sign-ups. More sign-ups read as things going well, but the count of people still there a month later rose nowhere near as fast. So teams started measuring what share of new accounts actually used the product, which is what an activation rate is.

A rate was better than a raw count, and meetings still stalled. Someone would report 40 percent activation for the month, someone else would ask what had changed since last month's 40 percent, and that was that. Inside a single rate, a person who used the product 30 minutes after signing up and a person who floundered for nine days before getting there count exactly the same. In the first there is nothing left to fix; in the second, most people leave somewhere inside those nine days.

So time got attached to the rate. Asking how long it took, rather than how many got there, exposes the difference hiding inside a single percentage. Time to value (TTV) is also easier to act on. "Move 40 percent to 45" tells nobody where to look. "Cut a nine-day median to two days" forces someone to go find out what users were doing during those nine days.

How to calculate it

Take the gap between one user's sign-up timestamp and the timestamp where they first got something useful out of the product, then take the median of those gaps. Four steps.

  1. Pin the end point to a single action. The instant a user realizes the product is worth something is the aha moment, and it has to be rewritten as behavior that lands in the event log rather than as a feeling. For a collaborative document tool that sentence looks like "edited the same document at the same time as at least one colleague."
  2. Pin the start. For products people sign up for themselves it's the moment registration completes; for products sold to companies it's the contract date or the day the account was opened.
  3. Take each user's gap. Recording the setup moment stretch separately — the configuration a user has to finish before any value is possible — lets you tell later whether a long gap came from setup or from everything after it.
  4. Use the median, not the mean. Five users at 3, 4, 5, 6 and 60 days average to 15.6 days and have a median of 5.

How you handle people who never reached the end point inside the observation window is where this metric goes wrong most often. Drop everyone who didn't get there within 30 days and the median comes out beautifully, because you deleted precisely the users who struggled longest. Keep them out of the distribution and report them separately instead, as something like "38 percent not reached within 30 days." If the median among those who arrived is two days while 38 percent never arrive, the two days are not the problem.

What a good number looks like

There is no good number in the abstract; the cadence of the job the product does sets the bar. A tool people open daily has to land inside the first session, so the conversation happens in minutes. A reporting tool used once a quarter can take days without anything being wrong. The same four days is an emergency in a document tool and unremarkable in a tax filing tool.

That leaves two ways to judge it. The first is the trend. A median of four days last quarter and two days this quarter means the work done in between was aimed correctly. The second is the shape of the distribution. Two humps mean two different kinds of user are averaged into one figure — people arriving through an invite link at 20 minutes and people arriving through search at nine days, flattened into a single median. Only the second group is worth working on.

There is one line not to cross. If the trial runs 14 days and the median is nine, users spend two-thirds of the trial on setup and decide about paying with the five days left over. A product where value lands after the first invoice loses people before it ever gets paid. Past that line, look at the trial length before you touch the onboarding flow that helps new users settle in.

How it sounds at work

"The median is nine days and the trial is fourteen. Setup eats the trial."

The metric and the pricing design contradict each other, so one of the two has to change.

"The number dropped, but we moved the end point last month. These aren't comparable."

Pointing out that redefining the end point breaks the series.

"Look at people who signed up alone and it's six times higher."

The overall median is blending two populations and hiding the real problem.

At Pagedeck the end point is "edited the same document alongside one colleague." Mia plots the distribution every quarter, and last quarter's plot had two humps. Users arriving through an invite link mostly crossed the end point on day one. Users who found the product through search on their own had a median of nine days.

Noa found the cause by rewatching the first screens that second group saw. Someone arriving alone has nobody to edit alongside, so reaching the end point means inviting a colleague and then waiting for that colleague to accept. No amount of rewriting the tooltip copy was going to shorten that.

What people get wrong

The most common mistake is making the number itself the goal. Shorter obviously sounds better, so it reads that way without anyone deciding. The catch is that the value moves as far as you like depending on where the end point sits. Pull the end point forward to "created one document" and the median drops from nine days to twelve minutes while nothing about the product changed. Teams handed this as a target usually drift exactly that way. The next quarterly report says twelve minutes, and the share of users who reach habit formation, where use hardens into repeated behavior, is the same as it was at nine days. Pick the end point once and leave it alone for the quarter.

The other frequent reading is that this is an onboarding-screen problem. Users are lost in that stretch, so better guidance looks like the answer. But in some products the structure of how value gets produced is what eats the time. When a product only pays off once a colleague joins, a solo user's clock doesn't move no matter how many times the copy gets rewritten. The work there isn't the screen — it's building a path where one person alone can see the point, and if no such path exists, not acquiring solo sign-ups in the first place. Spend a quarter on the screen and the number stays put while the room to fix it runs out.

Where to go next

Last updated 2026-09-16