Someone on your team gives notice. Good for them, it's a great next role.
Then it lands. They were the person who ran the digital adoption platform. They built the tours. They wrote the segment rules. They knew which checklist fired for which user and why, and which three flows you absolutely do not touch before a release.
And none of that is written down anywhere that helps.
You didn't just lose a teammate. You lost the only working model of how your adoption tooling actually behaves. The tool is still there. The person who made it make sense is not.
A DAP isn't a tool you bought. It's a job you hired.
This is the part the purchase decision hides.
When you buy a digital adoption platform, it feels like buying software, a license, a line item, a thing you own. But the tool does almost nothing on its own. It works because a human feeds it continuously: building each tour, defining each rule, and rebuilding all of it every time the product ships.
Bret Taylor draws the line exactly where the cost lives: "Making these things is not hard. Maintaining them is hard." Lenny Rachitsky's read on hand-built flows is the same warning in operational terms, that someone has to "maintain these flows forever," and "even tiny changes can take weeks."
Forever is a long time to depend on one person. And most teams have exactly one. The DAP model runs on a single, overloaded admin, and the day that admin leaves, "forever" becomes "until last Tuesday."
The black box nobody wants to touch
Here's why a quick handoff doesn't save you.
The logic of a mature DAP setup isn't really in the tool. It's in the admin's head. Mike Taylor puts it well: "most of the important things in your organization are tacit, not explicit, knowledge, and not written down anywhere." Shaun Clowes describes what configured B2B workflows become over time, "a black box," even to the people who built them.
So the next person inherits a console full of tours and rules with no map of why any of it is the way it is. Touch the wrong segment and you might break onboarding for a customer tier you didn't know existed. So the rational move is to touch nothing.
And nothing is exactly what rots.
Stale guidance is worse than no guidance
While the seat is empty, the product keeps shipping. It always does.
Every release nudges a button, renames a tab, moves a setting. The tours that pointed at those things now point at empty space, or worse, at the wrong thing. Your in-app guidance quietly turns from help into misdirection. A new user follows the tour, the tour is wrong, and now they trust the product a little less than if you'd offered no guidance at all.
The admin used to catch this. They'd see the release notes, find the broken flows, and patch them before users hit them. With no one in the seat, the breakage just accumulates, invisible to you and very visible to the users living it.
And there are no spare hands to absorb the job. Tal Raviv calls it the great flattening, fewer people owning larger and larger swaths of the product. Nobody is sitting around hoping to inherit a black box of tour logic on top of their real work.
Run the bus-factor test this week
You don't need a vendor to find out how exposed you are. You need one honest question at your next team meeting.
If the person who owns your adoption tooling gave notice tomorrow, how many days until the first tour breaks in front of a user, and whose name is on fixing it?
Write the name down. If you can't, that is the finding. You have built a piece of your customer experience on a single point of failure, and you're paying for the privilege, because a dedicated DAP admin runs roughly 80 to 160 thousand dollars a year fully loaded, on top of the license.
The deeper question is why guidance depends on a person at all. The reason we built Deway the way we did is to remove that dependency, a system that learns the product itself and keeps its guidance current as you ship, so there's no admin to lose and no black box for anyone to inherit. But you don't need us to run the test above.
Ask it out loud at your next standup.
What would happen to your product adoption if your DAP admin quit tomorrow?
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.