If a user signs up, opens your product, and doesn't get to the thing they came for inside the first minute, the rest of the funnel is academic. They don't churn — they evaporate. You won't see them in your retention dashboard because they were never there long enough to count.

The first 60 seconds is a different problem​

Long-arc retention design is about value compounding: making each session a little more useful than the last, building up a graph, learning preferences, training the user. It's a beautiful and patient kind of design.

The first 60 seconds is the opposite. The user has zero context, zero investment, zero patience, and a browser tab full of alternatives. They are, in design terms, the most hostile audience you'll ever have, and they're never more hostile than right now. Whatever you can teach them in 60 seconds, they'll learn. Whatever you can't, they won't — they'll close the tab and you'll never get a second shot.

So the first 60 seconds is its own discipline. Not "onboarding" in the bloated, multi-modal-tour sense — that's actually the opposite of what works in the first minute. The first 60 seconds is more like a single, very well-rehearsed question and answer:

"What did this person come here to do? Show them how to do it."

That's it. Everything else is decoration.

Why most onboarding flows fail this test​

Walk through five SaaS onboardings this afternoon and you'll see the same pattern: a welcome modal, a product tour with five steps, a checklist, and a sample data set. Each piece is well-intentioned. Together they're a maze.

The user came to do a specific thing. They typed your URL or clicked your ad with a specific outcome in mind. The welcome modal is in the way. The product tour is in the way. The checklist is in the way. The sample data set is the most damning of them all — it's the product saying "we know you came to upload your data, but we'd prefer you look at our pretend data first."

A good first 60 seconds asks: what's the smallest version of the user's actual goal we can let them complete right now, with the data and context they brought with them? Then it removes everything between them and that.

The activation arithmetic​

Here's the calculation that makes activation the highest-leverage problem in most products:

Suppose your product has a 25% activation rate (one in four sign-ups completes their first meaningful action) and 60% month-1 retention of activated users. Lifting activation from 25% to 35% — a relative improvement of 40% — produces a 40% lift in active users next month, compounding through the rest of the funnel.

To get the same lift through retention work, you'd need to push month-1 retention from 60% to 84%. Possible, but a much harder design problem, and the absolute ceiling is closer than you think.

Activation has more headroom because it's where the most users are sitting. Every funnel narrows from top to bottom; the most leverage is at the widest point.

What "activated" actually means​

The most common mistake is defining activation by something easy to measure rather than something correlated with retention. "Created an account" is not activation. "Visited three pages" is not activation. "Clicked the primary CTA" is not activation.

Activation is the user reaching the moment where the product has done something for them they couldn't have done otherwise — the aha moment — and where the cost of leaving is now slightly higher than the cost of staying.

For a project management tool: not "created an account," but "created a project with at least one task and invited at least one collaborator."

For an analytics product: not "installed the SDK," but "saw the first chart populate with real data from their app."

For a writing tool: not "opened the editor," but "wrote and saved 200 words."

The pattern is "did the thing they came to do, well enough that the next session is worth showing up for." Anything less is a vanity metric.

A short list of things to fix this week​

• Cut the welcome modal. If a user has to dismiss it before doing anything, it's not welcoming, it's tolling.
• Skip product tours. Replace them with contextual prompts that fire when a user is about to need the explanation.
• Use the user's data, not yours. Sample data is the strongest possible signal that you don't trust the user to bring their own.
• Defer settings. No one configures preferences before they've used a product. Ship sensible defaults, and let preferences appear in flow when they become relevant.
• Measure time-to-value, in seconds. If you can't draw a chart of "median seconds from sign-up to activation event," you're flying blind on the metric that matters most.

The teams that ship the best onboarding don't ship more onboarding. They ship less, and what they ship is closer to the user's actual goal.

Real understanding is more boring than that, and harder to fake.

The gap between "users" and "the people who use this"​

When you say "our users," your brain reaches for a composite — a cartoon, really. Friendly. Predictable. Conveniently aligned with the feature you're already planning to build. The cartoon is useful for slide decks and useless for design decisions.

The people who actually use your product are stranger than the cartoon. They have constraints you don't know about. They've developed workarounds for problems you didn't realize they had. They're using your product in contexts you'd never have predicted — between meetings, on a phone, with a colleague leaning over their shoulder, after their previous tool got deprecated, while debugging something completely unrelated.

You can only design for the second set. The first set will accept anything because they don't exist.

What understanding actually looks like​

Understanding is not "we did 5 user interviews last quarter." It's a working answer to questions like:

• Why did this person pick us over the four competing options? What did they almost pick instead, and why didn't they?
• What were they doing immediately before they signed up? What were they trying to get done?
• What would they have done if our product didn't exist? (This is the real comparator — not other products, but their default workaround.)
• What does success look like for them this week? Not in the abstract — this Tuesday.
• What's the embarrassing, awkward, or technically-out-of-bounds thing they're using our product to do?

The teams that ship things people actually want can answer these without flinching. The teams that ship things people politely ignore tend to answer with a roadmap.

How to build the model without spending six months on it​

The cheapest way to build a real model is to talk to fewer users, more carefully. Not five interviews — three. But three where you ask follow-up questions until you're embarrassed by how specific they get.

A good rule: for every claim a user makes, ask "what does that look like?" twice. The first ask gets you a generality ("it's slow"). The second gets you the actual moment ("Tuesday morning, I had to load the report twice because the first time it timed out, and I couldn't tell if it was working or not"). The actual moment is the design brief.

You're not collecting opinions. You're collecting operating conditions.

Why teams skip this​

Three reasons, in roughly this order:

1. It feels low-status. Talking to one user doesn't feel as productive as designing a feature for everyone.
2. It produces uncomfortable answers. Real understanding often shows that the next thing on the roadmap is wrong, or that the team has been solving a fake version of the problem.
3. It can't be delegated. A research firm can run interviews, but they can't pattern-match against your product knowledge in real time. The best understanding lives in the heads of the people building.

The teams that get past these three things ship better products. Not because they have more empathy — that's a moralizing way to describe it — but because they're working from a more accurate map.

A starting habit​

If your team isn't doing any of this: pick one user, schedule a 30-minute call this week, and don't end the call until you can describe what their Tuesday morning looks like with our product and without it.

Do this every two weeks. After ten of these, you'll have a model. After thirty, your roadmap will be unrecognizable from what you'd have built without them.

The tour exists because someone — usually someone senior — argued, correctly, that users don't know how to use the product. Then someone else — usually someone in design — built the obvious solution: show them. The tour is the fossil of an honest impulse.

It still doesn't work.

Why tours fail the people they're for​

A new user has one job for the first 60 seconds: figure out whether the product does the thing they came to do. A tour answers a different question — "what does the product do in general?" — and answers it before the user has earned a reason to care.

So the tour gets dismissed. Sometimes it gets read, in which case it gets immediately forgotten, because forgetting is what brains do with information that arrived without context. By the time the user actually needs the tooltip-with-arrow that pointed at the export button, the tour is hours behind them.

Internal dashboards confirm this every time someone bothers to measure: tour completion rates above 30% are rare, and the correlation between completing the tour and activating is somewhere between weak and inverted. Users who complete the tour activate at similar rates to users who skip it — a strong signal that the tour is not the thing doing the work.

What replaced it​

The replacement is so obvious it took ten years to ship: don't explain the product. Explain the next thing the user is about to do, in the moment they're about to do it.

A user hovers over the export button for the first time → a one-line tooltip says "exports as CSV; large reports run in the background." That's it. No tour. No arrow. No modal. Information arrives at the moment the user has a question, in a form small enough to consume in less time than re-reading the button.

This is contextual help, but the word "help" undersells it. It's not help. It's a property of the interface — the same way a button has a label, an interaction has a one-sentence explanation that appears only when needed and disappears the rest of the time.

The practical shift​

If your team is sitting on a five-step tour today, the replacement is not a six-step tour. The replacement is:

• A list of the moments where users have been getting stuck. Build it from session recordings, support tickets, and a single Tuesday morning of watching new users use the product. Sort by frequency.
• A short prompt for each moment, written like a label, not like a coach. "Exports as CSV" beats "Click here to export your data!" by a wide margin. The first respects the user; the second performs.
• A trigger. When does this prompt fire? Not "on first login" — that's the tour. "On first hover," "on second visit to this page without taking the action," "after the user has looked at the empty state for more than 8 seconds." Triggers are the design.
• A retirement plan. Each prompt should disappear once the user has demonstrated they don't need it. A tooltip that fires on every hover after the first is an interruption, not a guide.

The teams that ship the best contextual help write the prompts the way good copy editors write captions: to the point, in the user's language, on the side of brevity. Not "Welcome to Reports! Here you can build, save, and share reports with your team." but "Reports save automatically." The first sentence is a tour. The second is a fact.

Why this is harder, not easier​

Tours are easy to ship because they're a single artifact: one component, one schedule, one A/B test. Contextual prompts are harder because they're not a feature — they're a sustained editorial practice. Every product change adds a new "moment where users get stuck"; every shipped prompt has a half-life; every retired feature leaves an orphaned tooltip pointing at nothing.

The teams that do this well treat in-product copy the way good newsrooms treat headlines: as a job someone owns, every week, forever. The tour was easier because nobody had to own it past launch. That's also why it didn't work.

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.

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.

For most teams, the empty state is the last thing the design org thinks about and the first thing the new user sees. The math is bad.

The empty state is the welcome page​

A traditional "welcome page" — the modal with the wave emoji and three bullet points — is a pre-product surface. It exists in front of the actual product, between the user and what they came for. The empty state is the opposite: it's the actual product, in its natural shape, on the first day of use.

Which means it's the only welcome surface that doesn't require the user to dismiss something to start using your product. That's a structural advantage, and almost nobody uses it.

The default empty state is a sad icon and a "Create your first X" button. That's not a welcome — that's a chore. The user sees the icon, sees the button, and has to choose between an unbounded creation task and a back-button.

What good empty states do​

A useful empty state does three things, in order:

1. Tells the user what this surface is for, in one sentence. Not "Reports" — that's a label. "Your saved reports — drag a chart here to start a new one." That's a sentence that earns the user's attention.
2. Shows the smallest possible example of the populated state. A faded mock chart in the background, an outline of where the next action will land. Not sample data the user has to delete — a visual scaffold that makes the populated state legible before the user has populated anything.
3. Offers exactly one action the user can take right now. Not three primary CTAs. Not a checklist. One verb, one button, one arrow.

Done well, this collapses the welcome modal, the product tour, and the activation checklist into a single, no-interruption surface that the user is already looking at.

The "but our product is too complex" objection​

Every team I've ever shown this to has the same objection: our product has too many surfaces. We can't have a useful empty state on every single one — we'd spend the whole quarter on empty states.

This is true and also a sign that the empty states are correctly the most leveraged thing to spend the quarter on. Each empty state is the very first impression of that product surface, often the only impression — most users never see a populated version of most surfaces. If the empty state is bad, the surface is bad. There is no rescuing it later in the funnel.

The fix isn't to skip the empty state work; it's to prioritize. List your product's surfaces by traffic. Spend the quarter on the top five empty states. Leave the rest as the sad icon. Most of the gain is in the top five.

A short list of empty-state mistakes​

• A picture of the populated state with the word "Coming soon" over it. This is what you ship when you don't have an empty state and don't want to admit it.
• Sample data the user has to delete. Sample data signals you don't trust the user's data. Worse, it signals that real data is annoying to add — because if it weren't, why would you have shipped pretend data?
• Empty state with no CTA. A blank screen with the helpful message "No reports yet." Helpful in the way a closed door is helpful.
• Three primary CTAs. Two buttons of equal weight is the new "no buttons." Pick the one that the user is most likely to want, and demote the rest.

Empty states are the highest-leverage UX work most teams aren't doing. The teams that do it well will outship the teams that ship more features.

What NPS actually computes​

You know the formula but it's worth saying out loud: NPS = % promoters (9–10) − % detractors (0–6). Passives (7–8) don't count toward the number at all.

That formula does two things you might not have noticed:

• It is non-linear. A user moving from 7 to 8 doesn't change the metric. A user moving from 6 to 7 changes it by one detractor's worth. A user moving from 8 to 9 changes it by one promoter's worth. Two of the three boundaries on the 0–10 scale matter; the rest don't.
• It is discontinuous. A 6.99 and a 7.00 are categorically different inputs to the metric, even though no human distinguishes between them on the survey form.

These properties make NPS extremely sensitive to sampling. If your sampling shifts even slightly — different survey timing, different population, different copy — the number can move several points without anything changing about the underlying customer experience.

The sampling lies​

Five common sampling sins, all of them seen in the wild:

1. Surveying after success events only. "We asked NPS after their first big win." Sure, and your number is correspondingly high. The customers who quit before the first big win are excluded entirely. NPS computed only over surviving users is not a measure of NPS — it's a measure of how good your retention already is.

2. In-app NPS surveys to active users. Same problem. The most disengaged users haven't logged in for weeks, so they're not in the sample. The number you get is the NPS of users who like you enough to be in your product. Of course it's positive.

3. Email NPS to all users, but with a low response rate. The users who respond are non-representative — they're either passionate (positive) or angry (negative). Passives skip the survey entirely. Your NPS becomes more polarized than the underlying population, and which direction the polarization tilts depends on whether you've recently shipped something controversial.

4. Surveying right after support resolution. Users who just had a problem fixed feel grateful. The number measures the support team's gratitude factor, not the product.

5. Sampling rolled up across customer types. SMB users and enterprise users have different baselines. Mixing them produces a number that's a weighted average that nobody on your team can interpret.

What to do instead​

You don't need to throw out NPS — you need to read it carefully:

• Sample randomly across all users, not just active ones, on a fixed cadence (quarterly is fine). The number will be lower than your in-app number. That's correct.
• Cohort the result by tenure, plan, and segment. A single NPS number for the whole company is a vanity metric.
• Plot trend, not level. The absolute NPS number is full of methodology bias and not comparable to your competitors'. Your own quarter-over-quarter change is the only signal that's interpretable.
• Read the verbatims, not the score. The free-text response is the actual data. The score is a sorting key for the verbatims.

The board-deck problem​

The reason teams keep reporting a single rolled-up NPS number is that boards and executives like one number. It fits on a slide. The fix is editorial, not technical: ship the number with the cohort breakdown alongside it, every time. Train the room to read it as a distribution, not a level. The team that does this looks more rigorous, not less.

NPS is a perfectly fine metric handled badly by most of the teams using it. Read it like a survey scientist would, and it's useful. Read it like a sales-side dashboard, and it's a story you're telling yourself.

The actual activation funnel — the one that describes what happens to real users — is shaped nothing like that. Most of the leverage in activation is in steps that don't appear on the diagram, because they don't appear in your tracking either.

The steps your funnel doesn't include​

A complete activation funnel includes, in roughly this order:

• Saw an ad / heard about you / searched
• Clicked through to the marketing site
• Read enough of the landing page to form an intent
• Signed up
• Got the verification email
• Found the verification email (this is the one nobody tracks)
• Clicked the verification link
• Landed on the product
• Found the place to do the thing they came for
• Started doing the thing
• Hit the first piece of friction
• Recovered from the first piece of friction
• Completed the thing
• Came back the next day to do it again

Most teams instrument steps 4, 8, 13, and call it a funnel. The other steps are doing all the work, and the team has no way to see them.

The two invisible drop-offs​

Two of the missing steps account for most of the surprise loss:

The verification email gap. A nontrivial fraction of users who sign up never make it to the product, not because they bounced, but because the email went to spam, the user closed the tab, or the verification link 404'd. A few percentage points of activation regularly hide here. Easy to fix once measured; impossible to find without measuring.

The "where do I do the thing" gap. Users land on your product after verifying. The product loads. They see the dashboard. They cannot find the button that does the thing they came to do. They click around for forty seconds. They give up. This shows up in your analytics as a session that visited four pages and bounced, indistinguishable from a session that did the thing. The user, meanwhile, will tell you in the survey that "the product was confusing" — and you will helpfully add another tooltip somewhere, missing the actual problem, which is that the primary action wasn't where they expected it to be.

How to draw the real funnel​

The fastest way to find the missing steps is the manual one: 30 minutes of session recordings of users on day 1. Watch ten of them. Count the steps that show up on the screen but not on your funnel chart. That's your real funnel.

Do this once per quarter. The funnel changes shape every time you ship a UX change.

The fix is rarely "more onboarding"​

When teams discover an unexpected drop-off in their funnel, the default response is to add a tour, a tooltip, a checklist. This is almost always wrong. The drop-off is usually a sign that the underlying interface is confusing — and adding a guide on top of a confusing interface produces a confusing interface with a guide. The correct fix is usually to change the interface so the guide isn't needed.

A test: if you removed the tooltip after a week, would the activation rate drop back? If yes, you haven't fixed the interface — you've propped it up. If no, you didn't need the tooltip in the first place. Most contextual help shipped in response to drop-offs falls into the first category. The teams that ship better products fall into the second.

What to do this week​

• Pull a list of users who signed up in the last 7 days but did not activate.
• Watch ten of their sessions, end to end, in real time, with no playback speed.
• Write down the exact moment each user hesitated, lost, or quit.
• Compare your written list to your funnel chart.
• The gap between the two lists is your work for the next sprint.

This is unglamorous and produces more roadmap ideas per hour than any other research activity. The teams that do it consistently outship the teams that don't, by a wide and persistent margin.

The reason tooltips proliferate isn't that they're useful — it's that they're cheap to ship. A tooltip is the answer the team gives when the interface isn't legible enough on its own and the deadline is too close to redesign it.

When a tooltip is doing real work​

A tooltip earns its place on the screen when all three of these are true:

1. The user is going to need this information at this exact moment. Not "might need at some point" — this moment, before they take the action.
2. The information cannot be expressed in the visible label. "Save" doesn't need a tooltip. "Save" with the additional information that this also publishes to the public site does — but better still, the button label should be "Publish."
3. The information is short enough that a tooltip is the right form factor. Two sentences, max. If it's longer, you needed a help article, not a tooltip.

If any one of those is false, the tooltip is decoration. Decoration in a UI is not neutral — it's interruption.

The half-life problem​

Even tooltips that earn their place have a half-life. A user reads the tooltip the first time. The second time they hover, they see it again, and it's wasted attention. The fifth time, it's an actively annoying interruption. By the tenth time, they've trained themselves to hover-with-eyes-averted, which means the tooltip is now active anti-help.

A tooltip with no retirement plan is a bug. The retirement plan can be:

• Show on first hover only, then not again for that user.
• Show until the user has performed the related action three times.
• Show as a one-time popover on first visit to the surface, then never again.

What you should not do is show the tooltip every time. That's the default behavior of every tooltip library, which is why every product has aggregate tooltip fatigue.

The tooltip vs. the inline​

A subtler design question: should this be a tooltip or an inline note? The default is tooltip because tooltips can be added without touching layout. But the inline almost always reads better, because the user doesn't have to hover to see it.

A test: write the tooltip text. Now read the page with the tooltip text inserted as a one-line note next to the relevant element. Is the page worse? In about 20% of cases, yes — the page becomes cluttered. In the other 80%, the page is better — the user gets the information without an interaction, and there's no fatigue problem.

Most tooltips that exist today should be inline notes. The tooltip is a hiding place for content that doesn't deserve to be on the surface, but does deserve to be reachable.

A short editorial pass on your existing tooltips​

If you haven't audited your product's tooltips in the last six months, the audit will pay for itself. Sit down for an hour with a list of every tooltip in the product. For each one, answer:

• Does the user actually need this at this moment?
• Could the underlying label or layout do this work instead?
• Does it have a retirement plan?
• Is it duplicated by another nearby element?

In my experience, an audit deletes about 40% of the tooltips, rewrites about 30%, promotes about 15% to inline notes, and keeps the remaining 15% as-is. The product gets quieter, faster, and easier to use. None of this requires shipping new code — it's editorial work, applied to the surface that has the most of it.

The teams with the best in-product writing don't have more tooltips. They have fewer tooltips, written better, retired aggressively. The two are correlated.