April 4, 2026 · Mukesh
When to use a product tour (and when not to)
Tours work for orienting new users and announcing UI changes. They fail as a patch for confusing products. Four good cases, four bad.
Every few months a PM asks the same question. Should we add a product tour?
The answer almost always depends on what you think a tour will do. Most of the time, teams reach for tours for problems tours don’t solve.
Here’s the split.
Use a tour when
You have a dense interface with five or six important surfaces. Linear, Figma, Notion. A new user has to learn where things live before they can do anything. A tour of the top three or four surfaces, thirty seconds total, earns its place.
You shipped a significant UI change and returning users are disoriented. One step. Shown once. Anchored to the thing that moved, with a link to the change post. This is the best tour anyone builds because the success metric is obvious. Clicks on the “what changed” link.
You want to drive discovery of a specific new feature. A one-step popover, anchored to the feature, shown the first time a user opens the page. Not a tour at all, really. A contextual hint. The distinction matters because it changes the design. No progress bar, no “next,” no closing modal. Just the hint.
You’re running an activation experiment on tour vs no-tour. Fine. Run the test. Decide up front what result kills the tour, and stick to it.
Don’t use a tour when
The product’s empty state is confusing. If the first screen after signup is blank, users want content on the screen, not a tooltip explaining where content will eventually go. Fix the empty state first. Preload sample data. Give them one default project. A tour on a confusing blank slate doubles the confusion.
The product’s value isn’t visible without explanation. A tour is the wrong layer to teach value. It can show mechanics. It can’t make a user feel the thing. If the user needs a tour to see why the product is useful, the product has a bigger problem than onboarding.
Signups are coming from the wrong acquisition source. If your tour is trying to fix a mismatch between what the landing page promised and what the product delivers, you’re using the wrong tool. Fix the landing page. Users who came for the wrong job won’t stay for a tour.
The tour has more than six steps. Six is already too many. If you need more than four, you’re either writing a help doc inside a tour, or the product’s information architecture has failed and you’re papering over it.
A few things to know before you build one
Most tour analytics are useless. Completion rate of a skippable tour tells you almost nothing. Users finish the tour because they were going to be engaged anyway. The tour didn’t cause the engagement. If you want a real activation metric, measure behavior two days later, not how many steps they clicked through.
Selectors rot. The button you anchored to in version 1.4 gets refactored in 2.1, nobody notices, and the tour silently breaks for three months. Use data-attributes. Set up a smoke test. Both.
The copy does 90% of the work. Most “bad tours” aren’t bad components. They’re bad writing. Five words of plain, outcome-focused copy on each step will do more for activation than any feature the tour library can ship.
If your product already has clear value, a working empty state, and acquisition that matches reality, then yes. A short, skippable, pointed tour is worth building.
If it doesn’t, the tour is the third thing to ship, not the first.