I don’t think that account was unusual. If anything, it captures a problem I see more often now in customer success conversations. Users are completing onboarding experiences without becoming onboarded.<\/p>\n
Part of the reason is that the job of the interactive walkthrough<\/a> is changing. For years, walkthroughs existed to teach people how to use software: click here, then here, then here.<\/p>\n Today, that role is increasingly being absorbed by AI. Users expect products to guide them toward outcomes, automate setup, and reduce the amount of learning required in the first place. As that expectation spreads, walkthroughs that focus primarily on explaining the interface are becoming less valuable.<\/p>\n Still, I do think interactive walkthroughs aren’t disappearing, but the approach to building has to change. In this article, I want to focus on what is changing, what has to be true before AI-assisted walkthroughs work, and what I’d do differently if I were rebuilding one today. Yes.<\/p>\n The problem is that a lot of walkthroughs are still trying to do a job that matters less every year.<\/p>\n A walkthrough can still be useful when it helps someone take an action they were already trying to take. That’s very different from the old model, where onboarding meant dragging users through the interface and explaining what every button does. Because completing a walkthrough and making progress are not the same thing.<\/p>\n At the same time, if AI is helping users configure the product, answer questions, generate content, or complete setup tasks, then a lot of traditional walkthrough content starts to feel redundant. Explaining where something lives matters less when the user can simply ask for it.<\/p>\n That’s why I don’t think interactive walkthroughs are disappearing. I think they’re losing one job and being forced into another.<\/p>\n Its old job was explaining the product, while its new job is helping users make progress.<\/p>\n The walkthroughs I see on my CS calls were designed for a product that shipped four features a quarter and had two ways in. Most of our customers no longer have that product.<\/p>\n Part of the problem is that products change too quickly now. Engineering teams are shipping faster than they were two years ago. Cursor-style AI coding tools have dramatically reduced the cost of building software, and it’s no longer unusual to see teams release seven or eight meaningful features in a quarter where they used to ship one or two.<\/p>\n The old answer was to keep updating the tour. Add another step. Add another tooltip. Add another hotspot.<\/p>\n That works for a while, then you wake up one day with a 15-step walkthrough that nobody wants to sit through.<\/p>\n I see this problem in Userpilot all the time. The platform has grown to the point where I couldn’t tell you there’s one obvious activation path that applies to every customer. Some customers get value from publishing flows. Others care about session replays, analytics dashboards, resource centers, or feedback collection. The path depends on why they signed up in the first place.<\/p>\n That’s what makes a lot of traditional walkthroughs feel off. They’re built as if every user needs the same tour of the same product. That’s not to mention that most product tours still read like documentation:<\/p>\n Click here for this.<\/p>\n Then here for this.<\/p>\n Then here for this.<\/p>\n The user learns where things live, but never understands why they should care. That’s why the walkthroughs that still work tend to feel less like product tours and more like guided experiences. They’re organized around a job the user is trying to get done, a problem they’re trying to solve, or an outcome they’re trying to reach.<\/p>\n Another pattern I see all the time is companies that outgrow their own onboarding.<\/p>\n The product tour was designed when the company had two products. Back then, introducing both made sense. A new user could take the tour, understand the offering, and walk away with a reasonably accurate picture of what the company does.<\/p>\n Then the company launches a third product. Then a fourth. Then three more. Meanwhile, the walkthrough barely changes.<\/p>\n A prospect finishes onboarding and still leaves with the same mental model they would have had three years ago. In their head, this is still a two-product company that happens to have a few extra things bolted onto the side.<\/p>\n The implication for anyone running a CS or growth team is that activation and expansion are not two separate problems. Your activation experience is your expansion strategy. If the first hour of the product doesn’t introduce the bridges between products, you’re going to spend the next twelve months trying to retroactively convince every account that the bridges exist.<\/p>\n There’s also a much less interesting reason a lot of tours stop working. Nobody can keep them up to date, especially when the product changes.<\/p>\n I’ll admit on the record that some of our own in-product flows are dated, and we ship the platform. If we’re struggling to keep every walkthrough aligned with a product we work on every day, imagine the team trying to maintain dozens of tours across multiple products, multiple user journeys, and a roadmap that changes every sprint.<\/p>\n At some point, the maintenance becomes the job. Even though Userpilot can flag tours that break because of UI changes, I still need someone on my team to monitor those alerts and update the tours when issues come up.<\/p>\n That’s one reason I think long, linear walkthroughs<\/a> are becoming harder to justify. The more steps you add, the more surface area you create for things to break. And products aren’t changing quarterly anymore, they’re changing every week. Static tours were designed for a world where software moved more slowly than it does today.<\/p>\n We’re slowly moving away from a world where the UI teaches the user and toward one where the user teaches the product. Instead of learning the software first and doing the work second, users increasingly expect to describe the work and let the software adapt around it.<\/p>\n Yazan Sehwail, our CEO at Userpilot, frames it more directly than I would. In a recent internal session, he put it like this:<\/p>\n “People don’t wanna do any of this. That’s the truth. What it’s gonna be is that you literally do not need to do anything. It’s gonna look like you just go, you create a project, you tell it what you want, and it should do the rest. You’re no longer operating. The AI is operating. You’re just basically evaluating and monitoring the agent workflow.”<\/p><\/blockquote>\n From the CS seat, I see this playing out as two distinct directions that used to be one. One is the general onboarding for every user on the platform: a short, guided journey toward the first meaningful action, anchored in a checklist<\/a> they can move through at their own pace. Alongside it sits a proactive intervention layer for users whose pattern of behavior says they’re stuck, and that stream is where AI is now doing most of the heavy lifting.<\/p>\n Walkthroughs sit inside the first stream and are shrinking, while the proactive stream is growing into a continuous, conditional, agent-driven experience that the user mostly doesn’t see until the moment they need it.<\/p>\n Most “we’re adding AI to our onboarding” projects fail not because of the AI but because the work AI needs as input was never done. Gia Laudi, co-founder of Forget The Funnel<\/a> and creator of the Customer-Led Growth framework, made this case in a recent piece on AI-led product onboarding: don’t start with the AI, start with the work. You have to make sure to get these four things right before deploying any AI walkthrough.<\/p>\n If you can’t do all four today, do them anyway, even without the AI: they make every other part of your product work better, and you’ll need them within a year regardless of whether you ship the AI walkthrough.<\/p>\n If you accept the inversion thesis, the walkthrough you ship next quarter will look structurally different from the one you shipped two years ago. Here are the five moves I’d make in order.<\/p>\n The first thing I’d do is cut the walkthrough in half. Intercom’s benchmark data found that five-step product tours achieve a median completion rate of just 34%. That doesn’t mean every walkthrough should be exactly four steps long, but it does suggest that every additional step needs to justify its existence.<\/p>\n That’s why I think every step in a walkthrough should correspond to an action that moves the user closer to a meaningful outcome. Not “here’s the dashboard.” Not “here’s where you’ll find your settings.” Not “this is the navigation menu.”<\/p>\n Instead, ask what the user is actually trying to accomplish and build the walkthrough around that.<\/p>\n If they’re evaluating an analytics tool, help them connect a data source. If they’re using a project management platform, help them create their first project. If they’re adopting a collaboration product, help them invite a teammate.<\/p>\n Every step in the walkthrough should map to a sentence the user could finish: “I’m in the middle of trying to ___ for my team, and this step gets me one move closer.” If the step doesn’t pass that test, it’s documentation in disguise.<\/p>\n This is where the JTBD work<\/a> from: prereq one earns its rent. The walkthrough should never introduce a feature for the feature’s sake. It should introduce a feature within a sentence about a job and let the user use the feature to finish that sentence.<\/p>\n Most walkthroughs are designed as if the company only has one product.<\/p>\n The user signs up for Product A, so the onboarding teaches Product A. Every step introduces another feature, another menu, or another workflow inside that same product. By the end, the user may understand the product better, but they still have no idea how the rest of your portfolio fits into the picture.<\/p>\n That’s a missed opportunity.<\/p>\n If you sell multiple products, the most valuable thing your onboarding can teach isn’t another feature. It’s how the products work together to solve a larger problem.<\/p>\n Take a company with analytics, customer feedback, and onboarding products. A feature-focused walkthrough would teach users how to build a dashboard, collect survey responses, or launch a tooltip. A platform-focused walkthrough would show how feedback identifies friction, analytics measures it, and onboarding helps fix it. Suddenly, the user isn’t learning three separate tools. They’re learning one connected workflow.<\/p>\n That distinction matters because customers who adopt multiple products<\/a> tend to stay longer, are more likely to expand, and generate significantly more lifetime value than customers who only use one product. Multi-product adoption is one of the strongest indicators that customers see your company as a platform rather than a point solution.<\/p>\n When I review onboarding for multi-product companies, I like to ask a simple question: if a user finishes the walkthrough, could they explain how your products fit together in their own words?<\/p>\n If they can only describe the product they signed up for, the onboarding is probably teaching features. If they can explain how multiple products connect to help them achieve a broader outcome, the onboarding is teaching the platform.<\/p>\n For years, we’ve treated onboarding as a process of teaching users how to configure a product. But if AI can handle more of that configuration work, why are we still making users do it themselves?<\/p>\n I’d start by asking the user what they’re trying to accomplish, then let the product do as much of the setup as possible based on the context it already has<\/a>. Their role, company size, connected tools, signup responses, existing data, and stated goal are often enough to make a surprisingly good first pass.<\/p>\n We’re already seeing a lot of companies do this.<\/p>\n For example, PostHog’s CLI and AI-assisted development workflows allow users to describe what they’re trying to achieve in natural language and have the system generate implementation steps, configuration, and code from that intent.<\/p>\n Meanwhile, Airtable’s Omni lets users build apps, automations, interfaces, and workflows through conversation rather than manual setup. In both cases, the user starts with a goal, not a feature.<\/p>\n Userpilot’s Lia is what we’re shipping for this on our side. You won’t have to build onboarding flows from scratch or analyze analytics dashboards anymore; all you have to do is ask Lia!<\/p>\n I find this the single highest-leverage habit a PLG team can adopt. Once a month, sign up for your own product as a brand-new user, walk through the full onboarding, and pay for the paid plan. You’ll find bugs, weird UX, confusing blank states, broken help center links, conflicting email sequences, and tours promoting the wrong features.<\/p>\n I’d extend the rule to CS leadership specifically: the people who handle the customers your walkthrough fails should be the people most fluent in what the walkthrough currently looks like. The cost of the habit is 30 minutes a month, while the cost of not doing it is the slow accumulation of tour debt nobody on the team can see anymore.<\/p>\n If I were rebuilding a walkthrough today, I’d start by asking a different question:<\/p>\n What should the product already know about the user before the walkthrough even begins?<\/p>\n The more context you can bring into onboarding, the less teaching users need and the faster they reach value. That’s the direction the industry is moving, whether we call it AI onboarding, agent-led onboarding, or something else entirely.<\/p>\n That’s the direction we’re building toward with Userpilot.<\/p>\n Between in-app flows, analytics, behavioral targeting, and Lia, our AI agent, the goal isn’t to create more onboarding content. It’s to reduce the amount of onboarding users need by helping teams understand intent, identify friction, and guide users toward the next meaningful action. Lia can already analyze product data, surface opportunities, generate onboarding experiences, and help teams move from insight to execution much faster than traditional workflows.<\/p>\n Book a demo<\/a> and see it for yourself! Interactive user guides are a great way to engage your users. Help them understand your product better, and boost retention rates. Here’s how to build them.<\/p>\n","protected":false},"author":105,"featured_media":640125,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","inline_featured_image":false,"footnotes":""},"categories":[7568],"tags":[1085,169,339,365],"class_list":["post-11357","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-in-app-messaging-guides","tag-interactive-user-guides","tag-interactive-walkthroughs","tag-product-tour","tag-product-tours"],"acf":[],"yoast_head":"\n
\n
\n![\"demo](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/06\/CTA-blog-banner-1-1.png\")
<\/a><\/p>\nDo interactive walkthroughs still work?<\/h2>\n
Why the old walkthrough model is breaking down<\/h2>\n
“Click here, then here, then here” stops scaling with product surface area<\/h3>\n
Multi-product companies trap users in a 2-product mental model<\/h3>\n
Teams can’t maintain tours fast enough anymore<\/h3>\n
How are we moving from “UI teaches user” to “user tells product”?<\/h2>\n
What has to be true before AI walkthroughs can work for you<\/h3>\n
\n
How to rebuild your walkthrough today<\/h2>\n
1. Strip down to four or five steps, self-triggered, action-oriented<\/h3>\n
2. Replace “click here” with a story tied to a job-to-be-done<\/h3>\n
3. Connect products to each other, not just features within one product<\/h3>\n
![\"feature-vs-platform](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/06\/image-5-feature-vs-platform.png\")
<\/p>\n4. Use AI to configure the product based on the user’s context<\/h3>\n
![\"Airtable's](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/05\/Airtables-AI-powered-onboarding.webp\")
<\/p>\n![\"Lia](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/05\/Lia-provides-Insights-Recommendations-Userpilot.png\")
5. Sign up for your own product every month<\/h3>\n
Rebuild your walkthrough today!<\/strong><\/h2>\n
\n
\n<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"