Quick wins: Cutting steps is the wrong fix

The standard advice is to count the clicks between signup and value, then cut them in half. It is good advice that solves the wrong problem.

Users do not leave because a flow was long. They leave because nothing in it proved that the time they were spending would pay off. A twelve-step setup where step three produces something real will beat a three-step setup that drops someone onto an empty dashboard, every time, and a team that only counts steps will shorten the wrong flow.

What counts as a quick win?

A quick win is the first moment a new user has proof, rather than a promise, that the product does what they came for. The useful test of whether you have one is blunt: at the end of it, can the user point at something?

That rules out the usual celebrations: Finishing a tour is not a win. Reaching the dashboard is not a win. Connecting an integration is not a win, it is a chore with a checkmark. A win leaves something behind: a link they can send, a document that now exists, a number they did not have this morning, a piece of work that is done.

The products with the shortest paths to a first win are the ones whose output is a single small object: scheduling links (Calendly, SavvyCal), recorded video, a form that can be sent, a finished design, a draft that has been improved. If your product’s smallest useful output is that concrete, this pattern is largely available to you already.

Four shapes a first win takes

This taxonomy is an argument, not a survey, but every good first win we can find is a version of one of these. The shape you can reach determines how much work this is going to be.

The artifact. The user ends up holding something. Calendly’s entire onboarding exists to produce one scheduling link, because a link is a thing you can send to someone; the value is confirmed later, by a stranger, at no cost to the user, which is co-experience doing activation’s job for it. If your product can manufacture a small deliverable in the first minute, reach for this one before the others.

The passive catch. The product finds the value without being asked. Grammarly, the writing assistant, installs into the browser and then underlines a mistake the next time you write something, in the places it supports. Nobody has to remember to use it, and the first proof arrives inside something the user was doing anyway. Rare, and very strong when a product can reach into where the work already happens.

The pre-built start. The user begins from something, not nothing. Canva’s template-first navigation asks what you are making, not which tool you want, and hands back a finished design to modify. This is the shape most products could adopt, because building good defaults is unglamorous work with no feature to announce.

The answer. The product responds to a question with something useful before it knows who is asking, which is the same bet a reverse trial makes with paid features. Products in this shape have a second lever available: showing the work. Perplexity, the search assistant, attaches sources to what it tells you, which converts an answer a user cannot check into one they can, and trust is most of what a first session is buying. ChatGPT needed no tutorial because the interface is a conversation and the first reply is the entire proof. UBS analysts estimated it at roughly 100 million monthly active users about two months after launch, from third-party traffic data rather than any OpenAI disclosure, which was an unusually fast climb by any standard of the time.¹

Notice what none of these are: an explanation. Three of the four produce something the user keeps, and the fourth answers a question they actually had.

Mark the moment: a win nobody notices is a win that does not register as one, and the acknowledgement costs a line of interface. And design the output to travel, because the artifact from step one is the thing a user might screenshot, send or publish, and a product whose output is worth showing is doing its own marketing.

”Our product is too complex for this”

Usually untrue, and the belief is expensive, because complex products need an early win more than simple ones do. A user evaluating something with a two-week setup has more reason to doubt, not less.

There is one condition under which the pattern genuinely does not apply: if your product is bought after a long evaluation by a committee that will never touch it, first-session speed is not what decides the deal, and the effort belongs with the people running that evaluation instead.

Otherwise, what is true is that the win has to be a real slice rather than a small version. Where it is available, the shortcut is to remove the learning entirely by borrowing an interface your users already know. A data platform cannot show you its value in sixty seconds, but it can show you one chart built from your own data before asking you to connect everything. The trick is to find the narrowest complete thing the product does, not a shallow demo of the whole thing.

The failure this produces looks like progress: an onboarding checklist with eight items, none of which produce anything, all of which have to be finished before the product does its job. That is not a quick win architecture, it is a setup wizard with a progress bar, and users can tell the difference immediately.

Defer almost everything

Once the quick win is named, the design work is subtraction. Every step between signup and that moment has to justify itself against one question: is this required for the win, or is it required eventually?

Almost everything is the second. Branding, team invitations, notification preferences, advanced permissions, the fields somebody in sales wants populated: all of it can happen after the user has a reason to care. The test is whether the step is load-bearing. Calendly cannot produce a scheduling link without a connected calendar and a URL to put it at, so those stay; the rest of what a scheduling tool can be configured to do arrives later.

This is where defaults do the real work. A default that works out of the box is worth more than the setting it replaces, because few users change it, and the ones who do are already committed. Products that make customization mandatory are asking people to make decisions before they have any information to make them with, which is a close relative of asking onboarding questions whose answers change nothing.

Where the product can go to the user rather than the reverse, that beats all of it. The win arrives in the text box they were already typing in rather than at a destination, which is the beginning of being embedded in a workflow rather than competing with one.

Whether the win is working

The published figures for how fast a first win should arrive are invented, so measure the thing directly. Every check below is one you run against yourself.

1. How long does it take, measured rather than estimated? Sign up as a stranger, on a clean browser, with a stopwatch, using only what a real user would have. Then do it for three competitors. The gap is more informative than the number, and the fastest of them has found a shortcut you have not.
2. What share of signups ever reach the win at all? This is the activation rate that matters, and it is usually below what you assume, because the denominator includes everyone who left during setup.
3. Do people who reach it in the first session retain better than people who take a week? If they do, speed is not just a conversion lever but a predictor of account quality, and the first session deserves resourcing accordingly. If they do not, you have named the wrong win, and it is worth finding out now.

The compound version of all three is return rate after a first session: of the people who reached the win, how many came back at all. It is the leading indicator this whole section exists to move, and it is the number to put on a wall.

The qualitative version is faster and often more useful: watch one person fail. Find a session recording of someone who signed up and left within five minutes without getting there. Whatever stopped them is your largest leak, and it is usually not the thing on the roadmap.

Name the win, then subtract

1. Name the win in five words, as a noun. Everything else on this list is guesswork until this sentence exists, and disagreement inside the team about what it should be is itself the finding.
2. List every click between “sign up” and that moment. Then mark each one required-for-the-win or required-eventually. The second group moves to after the win, and it can move today.
3. Delete the step you are afraid to delete. Every product has one that everybody assumes is mandatory: the company-size field, the preference survey, the email verification before anything works. Remove it for a week and measure. Teams that run this rarely put it back.
4. Make one default good enough to ship with. Pick the setting every new user is forced to choose and give it an answer that works. Then remove the question.
5. Time three competitors with a stopwatch, and write down what they skipped that you do not. Their shortcut is available to you too.

That assumes there is one win to name. Plenty of products have several, because the people signing up came for different things, and a win that is precisely right for one of them is irrelevant to the next. So the question underneath everything on this page is whose win you are building, and whether the product can tell them apart on arrival. Most attempts to do that collect the answer and then ignore it.

Updated August 2026