I've spent the last fifteen-plus years at the intersection of product and customer success, and that intersection is where adoption lives or dies.
As a product manager, a founder, a consultant across data, analytics, and product strategy, and most recently as a Solution Architect at Mixpanel, I've had a front-row seat to the same pattern playing out across hundreds of B2B SaaS companies: teams build great products, ship meaningful features, and then watch adoption flatline.
The reason is rarely the product itself. It's the gap between what the product can do and what users actually discover, understand, and use.
That gap used to be someone else's problem. But as B2B SaaS matured, and especially as scaled and product-led growth models became the dominant go-to-market motion, adoption became a shared responsibility between product and CS, with neither side fully owning it and both sides frustrated by the results.
I've lived in that frustration. I've built dashboards showing feature adoption rates in the single digits. I've watched CS teams spend more than half their week answering the same onboarding questions. I've helped product teams build tours that 80% of users skipped. And every time, the tools existed. The effort was there. The results weren't.
That's what led me to build Deway. But before I explain what we're building, let me walk through why the existing approach is structurally broken and what's changed to make something better possible.
The Manual Adoption Model Is Breaking
There's a question that product and CS leaders keep asking each other, usually in different meetings, usually about the same problem: Why aren't users finding the features we built for them?
Product teams build sophisticated workflows. CS teams write help docs and run onboarding calls. And yet the pattern repeats: users get stuck, tickets pile up, adoption stalls. Features that took months to build get used by 20% of the user base.
The industry's answer to this problem has been the Digital Adoption Platform. DAPs emerged in the mid-2010s as a way to layer guidance on top of software. Build a tour. Write a tooltip. Set a trigger rule. Hope the user sees it at the right moment.
For a while, this worked. Or at least, it worked well enough that a $760M+ market formed around it. WalkMe went public. SAP bought them. Pendo raised hundreds of millions. Dozens of no-code tour builders launched with variations on the same theme.
But something fundamental has shifted. And the market hasn't caught up yet.
Every legacy DAP, whether it costs $50K/year or $250/month, shares the same core architecture: a human creates adoption content (tours, tooltips, checklists, nudges), then defines rules for when that content appears (user segment, page, trigger event).
This model has three structural problems that compound as products grow:
It scales linearly with product complexity. Every new feature, workflow change, or UI update requires someone to create or update the corresponding adoption content. A product with 50 workflows might need hundreds of tours and tooltips. A product with 500 workflows? The math stops working.
It requires expertise in two domains. The person building the tours needs to understand both the product deeply and the DAP's authoring tools. In practice, this creates a bottleneck. One PM or one CS ops person becomes the adoption owner, and everything queues behind them.
Static content can't respond to individual behavior. A rule-based system shows the same tour to every user who matches a segment. It can't tell the difference between a user who's stuck on step 3 and a user who's already figured out steps 1 through 7 and just needs a pointer to step 8. The content is fixed. The user isn't.
And here's what makes it worse: the failures are silent. Users don't file tickets when they skip a feature they didn't know existed. They don't complain when a misconfigured workflow causes them to abandon a task. They just quietly stop using parts of your product, and the churn signal shows up months later in a renewal conversation that's already lost.
Legacy DAPs were designed to solve visible adoption problems: onboarding flows, feature announcements, guided tours. They have no mechanism for detecting the invisible ones: the broken flows, the skipped steps, the misconfigurations that erode value realization without ever generating a support ticket.
These aren't edge cases. They're the default experience. And they're why the typical DAP deployment sees declining engagement after the initial setup: the tours go stale, the product evolves, and nobody has time to keep up.
The AI Coding Revolution Made This Urgent
Here's what turned a slow-burning problem into an acute one: AI coding tools fundamentally changed the pace of product development.
Claude Code, Cursor, GitHub Copilot, and a growing ecosystem of AI-powered development tools have collapsed the time it takes to go from idea to shipped feature. Engineers who used to spend days building a feature now ship in hours. Product teams that released monthly are releasing weekly. The velocity is genuinely unprecedented.
And that's incredible. For product teams.
For users? It's overwhelming.
Here's what this looks like in practice. A product team using Cursor ships a new reporting dashboard on Monday. By Wednesday, they've added five new filter options and a CSV export flow. The following Monday, the dashboard gets a permissions layer. The DAP admin hasn't started building tours for the original dashboard. Meanwhile, users are filing tickets asking how to filter by date range, a feature that's been live for ten days with zero in-app guidance. Multiply this across every team shipping every week, and you see why the manual model collapses.
This is the crux of the problem: the tools that help teams build faster didn't come with tools that help users keep up. Product velocity has outpaced adoption infrastructure. Legacy DAPs were designed for a world where products changed slowly enough that a human could manually curate every piece of in-app guidance. That world is gone.
The gap between shipping speed and adoption speed is widening every quarter. And it's widening fastest at exactly the companies that are most aggressive about using AI to build, which tend to be the same companies that care most about product-led growth and user adoption.
This is why the shift from DAP to AAP isn't just a nice-to-have upgrade. It's a structural necessity driven by how fast modern products evolve.
What Changed: AI Makes the Admin Optional
The enabling shift is straightforward. Large language models and modern AI systems can now do something that was impossible three years ago: observe a product's interface, understand what a user is trying to accomplish, and deliver contextual guidance in real time, without a human writing the script.
This isn't a feature upgrade to existing DAPs. It's a different architecture entirely.
The core insight: if AI can understand your product and your users, nobody needs to build the tours.
Think about what this eliminates. No author. No authoring tool. No content calendar. No version management when the UI changes. No rules engine to configure. No per-feature maintenance burden. The system learns the product, detects where users struggle, and intervenes, autonomously. It sees the silent churn that legacy tools miss: the misconfigured integration, the skipped onboarding step, the abandoned workflow that never generates a ticket but quietly kills retention.
I call this an Autonomous Adoption Platform. Not because the word "autonomous" is trendy, but because it's descriptively accurate. The platform operates without ongoing human direction. It observes, learns, acts, and evolves on its own.
The distinction from legacy DAPs isn't cosmetic. It changes the deployment model (one line of code vs. weeks of implementation), the operating model (zero maintenance vs. dedicated admin), and the economics (compounds in intelligence over time vs. linear effort scaling). A DAP assumes your team has time to build tours and that segment-level targeting is good enough. An AAP assumes your product is too complex and changes too fast for that to work, and delivers guidance at the individual user level instead.
What This Means If You're Buying Today
If you're a VP of Product or Head of CS evaluating adoption tools right now, the question you should be asking isn't "which DAP has the best tour builder?" It's "do I even want to be in the business of building tours?"
Here's a practical framework for evaluating where the market is headed:
Setup time. Legacy DAPs measure implementation in weeks. An autonomous platform measures it in hours. If you're spending three weeks setting up a tool whose job is to make your product easier to use, something's off.
Ongoing maintenance. Ask the vendor: what happens when we ship a new feature? If the answer involves someone on your team building new tours, you're buying a manual tool with AI marketing. This is the critical question for evaluating legacy DAPs that have bolted on AI features. WalkMe, Pendo, and their peers were architected around human-authored content with rule-based delivery. Adding a GPT layer on top of that architecture doesn't change the fundamental dependency: someone still has to create and maintain the underlying content. The AI makes the authoring slightly faster. It doesn't eliminate the need for an author.
Intelligence over time. Does the platform get smarter the longer it runs? Or does it only know what someone tells it? Autonomous systems improve with every user interaction. Manual systems only improve when someone updates them.
Admin dependency. Who owns this tool internally? If the answer is "we need to hire someone" or "our PM is already overloaded but they'll manage it," that's a signal. The best adoption tool is the one nobody has to administer.
Why Now
Three market signals suggest this shift is already underway.
The buyer is changing. DAPs were historically bought by enterprise training teams for internal tools. Increasingly, the buyer is a product or CS leader at a SaaS company who needs external user adoption, not employee enablement. These buyers have different expectations: faster deployment, lower maintenance, tighter integration with product analytics.
Product complexity is accelerating. AI features, multi-step workflows, and increasing product surface area mean the manual model is reaching its limit faster. The companies that need adoption tools most are precisely the ones that can't afford to manually maintain them.
AI-assisted development is compressing release cycles. As tools like Claude Code and Cursor become standard in engineering workflows, the gap between what gets shipped and what gets adopted will only widen. Any adoption solution that requires manual content creation per feature is fighting against the direction of the entire industry.
The Adoption Layer Your Product Deserves
I started Deway because I lived this problem from every angle. As a PM shipping features that didn't get used. As a consultant helping teams instrument analytics only to watch the data confirm what everyone already suspected. As a Solution Architect at Mixpanel watching company after company invest in measuring adoption without having the tools to actually drive it.
The pattern was always the same. Brilliant products with poor adoption. CS teams spending 60% of their time on repetitive onboarding questions. Feature launches that moved adoption metrics by single digits. And the reason was architectural: asking humans to manually anticipate every user's journey through a complex product is a losing proposition, especially when that product is evolving faster than ever.
The Autonomous Adoption Platform is the answer that technology finally makes possible. One line of code. Live in 72 hours. No admin required. An AI that learns your product, understands your users, and delivers the right guidance at the right moment, getting smarter every day.
Not a better tour builder. A system that makes tour building obsolete.
If you're interested in learning more, let us show you Deway.
Alon Binman is the co-founder of Deway (deway.ai), an AI-native autonomous adoption layer for SaaS products. Before Deway, Alon spent 15+ years at the intersection of product and customer success, including roles as a Product Manager, founder, data and product strategy consultant, and Senior Solution Architect at Mixpanel. You can reach Alon on LinkedIn.