Log inGet started
← Blog

Time to value: how to measure it

What time to value means, how to pick its start and end events, and a worked example that shows why the median tells you more than the average.

Stiro team ·

A new user signs up because they want something. A sent invoice, a booked meeting, a shared report. Every minute between sign-up and that first result is a minute in which they can get distracted, get stuck or decide your product isn’t for them.

Time to value is the number that tells you how long that wait is. It is simple to describe and easy to get wrong, mostly because of two choices: where the clock starts and stops, and which kind of average you report. This post covers both, with a worked example.

What time to value means

Time to value is how long a new user takes to get their first real result from your product, measured from a fixed starting point.

In words: for each new user, take the time of their first-value event and subtract the time of their start event. Then take the median of those times across a group of users who started in the same period.

It matters because long setup is where many new users leave. A user who gets a result in their first session has a reason to come back. A user who is still connecting, importing and configuring on day three often doesn’t come back at all. If you already track where new users stall, time to value is the companion number: the funnel tells you which step loses people, and time to value tells you how long the whole journey takes for the ones who make it.

Pick the start event

The start event is where the clock begins. Most teams use one of these:

  • Account created. The simplest choice, and the right default for self-serve products. Everyone has one.
  • Email verified or first sign-in. Useful if many sign-ups never come back after creating an account, and you want to measure only people who actually arrived.
  • Contract signed or workspace provisioned. Better for sales-led products, where the account may exist days before anyone uses it.

Whichever you pick, keep it the same every month. A change of start event can move the number more than any product change will.

Pick the end event

The end event is first value: the first action that shows a user got what they came for. It is usually the same as your activation event.

A good end event has three things going for it:

  1. It is a result, not a step. “Sent a first invoice” is a result. “Opened the invoice editor” is a step on the way.
  2. It happens in your product, and you can log it. If you can’t see it in your data, you can’t measure it.
  3. The users who stay almost all did it early. If you aren’t sure which action to choose, look at your retained users and find the result most of them reached in their first week.

Then set a window, such as 14 or 30 days. Users who haven’t reached first value inside the window count as “not yet”, and you report that share next to the time.

Setting up time to value
  1. Step 1Choose the startAccount created, for most self-serve products
  2. Step 2Choose first valueA result the users who stay all reached
  3. Step 3Set a windowSuch as 14 days, the same every month
  4. Step 4Take the medianAcross one month’s sign-ups
  5. Step 5Report who didn’tThe share with no first value yet

A worked example: median versus average

For example, say a small invoicing product had 12 sign-ups in one week. Its start event is “account created” and its end event is “sent a first invoice”, with a 7-day window. These numbers are made up to show the method.

Ten of the 12 sent a first invoice inside the window. Here is how many hours each of them took:

ExampleHours from sign-up to first invoice sent, per user
User 10.3 h
User 20.5 h
User 30.7 h
User 41 h
User 51.2 h
User 61.5 h
User 72 h
User 84 h
User 930 h
User 1070 h
Show as a table
User 10.3 h
User 20.5 h
User 30.7 h
User 41 h
User 51.2 h
User 61.5 h
User 72 h
User 84 h
User 930 h
User 1070 h

Add them up and you get 111.2 hours. Divide by 10 and the average is about 11 hours.

Now sort them and take the middle. With ten users the median sits between the fifth and sixth, 1.2 and 1.5 hours, so it is about 1.4 hours.

Example
median time to value
1.4 h
average time to value
11 h
reached first value in 7 days
10 of 12

Both numbers are correct arithmetic. They tell very different stories. The average says a typical user waits half a day. The median says a typical user is done in under an hour and a half, and two users took far longer. Those two, at 30 and 70 hours, pull the average up on their own.

That is why the median is the usual headline. It describes the typical user, and one person who signed up on Friday and came back on Monday doesn’t move it. The average is still worth a glance: when it sits far above the median, a group of users is getting stuck for a long time, and they are worth looking at.

And don’t forget the two users who never sent an invoice. They have no time to value at all, so they appear in neither number. Report “10 of 12 reached first value” alongside the median every time, or a product that loses more people can look faster.

You can run your own numbers with the free time to value calculator.

Read it carefully

A few habits keep time to value honest:

  • Compare like with like. Use the same start event, end event and window every month, on each month’s new sign-ups.
  • Look at the slow tail. Pull the users who took longest and check which step they spent the time on. It is often the same one.
  • Split by type of user. A median can be fine for small teams and long for larger ones, or fine for one sign-up source and long for another.
  • Watch the share who never got there. If the median drops but fewer people reach first value, the change didn’t help.

Shortening setup with an in-app agent

In most products, the long part of time to value is configuration. Connect the account, import the data, set the defaults, invite the team. The user knows what they want at the end. The slow part is finding each setting and filling it in. That is where an in-app AI agent fits: the user asks in plain words and the agent does the steps.

Stiro is one. You add it to your product with one script tag, and there is nothing to train. A new user can type or say “set my currency to euros and add our company address to invoices”, and Stiro clicks, types and moves through your real interface to do it while they watch.

  • It does the configuration steps. Users don’t have to hunt for the settings page to reach first value.
  • It reads the live screen. When you change setup to shorten it, Stiro works from what is on the page now, with no flows to re-record.
  • It says so when it can’t. If a request isn’t possible in your app, it stops, says why and changes nothing.
  • The user keeps the final say. Anything that sends, spends or deletes, such as sending that first invoice, is set up and handed back for them to press.
  • Stuck goes to your team. If it can’t finish, a signed-in user can message your team or your help desk from the same panel.

We tested Stiro cold in three open-source apps it had never seen, and it passed 44 of 44 everyday requests, each checked in the app’s own database:

requests done, first run, cold
44 of 44
on a repeat run of the same code
43 of 44
median time from request to reply
19.5 s
Source: Stiro benchmark

The benchmark lists every task and reply. For what to do with the first month once you know your time to value, see how to reduce churn in the first 30 days.

Measure it, then shorten it

Pick your start and end events, take the median for last month’s sign-ups and write down the share who never got there. Then look at the setup steps that fill the time. If they are steps your users could simply ask for, AI onboarding with Stiro lets them ask. The free plan includes 50 runs a month on localhost and a staging address, so you can try it on your own setup first.