Dopt vs all the other product adoption tools
Alon Bartur- January 26, 2023
- 9 min read
Trying to improve your product’s onboarding? Evaluating product onboarding tools that will help you do it faster? The goal of this post is to help you understand the major pitfalls you’ll face with the existing tools and how Dopt makes building better flows easier.
At the end of the post you’ll understand:
- How the current product onboarding tools work
- Why their approach fails
- How Dopt helps you avoid those pitfalls and ship better onboarding
The existing product adoption tools don’t work
I’m often asked how Dopt differs from the existing products aimed at helping people add onboarding into their SaaS products. You’ve likely encountered them (or at the very least seen the experiences they power): Pendo, Intercom, Userflow, Appcues, Chameleon, WalkMe; there are tens of others.
While they differ in small details, they’ve all taken the same approach to solve the problem: cut developers out of the loop and arm product, marketing, and customer success teams with tools to create in-product flows themselves. They’re used to overlay modals, tooltip tours, and banners onto a product to explain what things are and where users should click. Because of how they integrate, they’re inflexible, brittle, and lack connection to the product which leads to low quality experiences that ultimately aren’t effective at helping users adopt.
Our position, and one of the big reasons we started Dopt, is that the whole class of existing tools is fundamentally approaching the problem incorrectly.
We’re not alone in this belief, we’ve had hundreds of conversations with product managers, engineers, founders, and other growth, product, and engineering leaders at leading B2B SaaS companies since starting Dopt. Many teams have outright disqualified them, going the route of building in-house. Those still using them do so only begrudgingly due to the complexity that building entails or because they sit on teams like marketing with no developers.
We started Dopt to give teams a new and better way to approach building onboarding and education flows. Dopt is building for developers (along with their PM and UX partners). A single front end developer can build better flows with their own UI and components in a fraction of the time it currently takes. PM and UX partners can self-serve on targeting, logic, and content without having to push code. More on Dopt below, but first…
Why teams are dumping the existing tools
The root of the issue is their approach to integration: you drop a JavaScript snippet into your product, and they load their code and UI into your application at run time. That means they’re a layer above your product, with imperfect and imprecise integration points. This leads to a consistent and inescapable set of problems that have left teams abandoning the whole class of tools:
- They offer limited modalities that don’t fit your product and look bad. You’re stuck using tooltips, modals, and banners to point out what users should click on instead of creating contextual, deeply integrated experiences that onboard and educate your users. To add insult to injury, they don’t ever look quite like your product, no matter how much time you sink into futzing with their limited UI builders (and you’ll be futzing with it a lot, every single time your UI or design system changes).
- They’re brittle and hard to troubleshoot. Non-developers regularly attach components to the wrong UI element in the tree (either too shallow or too deep) and aren’t aware of side effects that may change the element they’re working with. Developers have zero visibility into these dependencies, and benign product changes regularly break onboarding and education flows — breakages that aren’t caught until product metrics start flagging. And those are just the self-inflicted issues, ad blockers block third-party JavaScript and silently suppress flows for users that have them enabled, muddying the data and making it hard to know if flows are actually driving improvement.
- They don’t fit into the modern product development process and don’t work well with other tools. From requirements to designs all the way through CI/CD, testing, rollout, and post-launch analysis: every part of the workflow differs from the team’s standard process. Experimentation and data tooling are hard to integrate leading to multiple silos that make analysis costlier.
Let’s break each of these down.
The existing tools offer limited modalities that don’t fit your product and look bad
As the old saying goes, if you give someone a hammer, every problem looks like a nail — or in this case, a tooltip tour.
We’ve found a lot of success with interactive onboarding that breaks the mold (like using our product itself to onboard users with interactive videos). The existing product adoption tools are too limiting for our needs, they want to treat everything as a pop up or modal.
-
The existing tools force you to use their UI, limiting the experiences you can build and making it obvious that they’re not part of your product. There are a pre-canned set of components, primarily overlaid, that you’re forced to use. They’re not the same components used in your product, don’t fully match your brand, and end up living in an uncanny valley — similar to but obviously distinct from your product. Every time your UI or design system changes, you’re forced to sink time into updating styles in their limited UI and theme builders. Because the experiences are clearly not part of the product users, trained by years of bad tours and walkthroughs, quickly dismiss them knowing that they’re safe to ignore.
If you use the existing tools you’ll need to update styles any time they change in your product. Differences in shape, layout, and type make it obvious they’re not part of your product. -
Their modalities don’t let users do anything leading to convoluted flows and poor UX. Do > Show > Tell. Need to set up an integration, change a setting, or invite a coworker? Instead of letting you do, you’re stuck telling users where they should go and what they should do. Instead of embedding a key setup action in an empty state at exactly the right moment in your user’s journey, you’d interrupt them with a modal, navigate them to a completely different place in your product, and take them on a tooltip scavenger hunt to find the action amongst a sea of others. Extra steps, a disjoint experience, and many more users lost along the way.
With existing tools, you’re stuck with a limited set of actions like navigating to another page, moving between tooltips, or launching another bolted on flow. You can’t create experiences where the user uses your product to learn. -
You can’t build them into your product’s interaction model making them feel bolted on. The tools rely on events to trigger flows. That lets you trigger them when users take an action in your product, but events can’t be counted on for true interactivity so progressing state across each step of the flow is driven by interactions with the experiences themselves. That means you’re clicking ‘next’ ten times on an obtrusive tooltip tour instead of simply using your product and having the experiences react to what you’re doing. You lose the opportunity for creative, contextual experiences that don’t get in the way and fit your product’s interaction model. You erode your users’ trust and goodwill.
Not many people are making it all the way through this
The existing tools are brittle and hard to troubleshoot
-
Non-developers have to attach their modalities to your UI with no understanding of the underlying structure which leads to brittle integration points. In order to attach their components to a product, the existing tools have confusing visual builders that overlay your product and allow non-developers to attach their modalities to DOM elements using brittle CSS selectors. That leads to frequent issues where a modality gets attached to the wrong UI element in the tree (either too shallow or too deep) or where side effects that may change the element aren’t considered. That means that seemingly unrelated changes, like updating product copy or a component in the design system, can silently take down crucial onboarding and education flows.
Existing tools force non-devs to use confusing builders to attach experiences to front end code they don’t understand. Even tiny copy changes can break the integration. -
Modern frontend development abstracts the DOM and makes accidental breakages common. In modern frontend development developers don’t work directly with the DOM, manipulating it indirectly and abstractly through frameworks/libraries instead. Additionally, there are compilation steps between what a developer writes in their editor and what ends up in the DOM. That means that developers are now far more likely to inadvertently violate assumptions non-developers make about where to attach elements to the DOM. The existing tools’ approach to integrating made sense in the 2010s, but it’s simply no longer viable.
It’s been really tough when I’ve had to use tools like Chameleon and Appcues. The source of truth doesn’t live in code, but rather in a 3rd party tool that relies on hooking onto ever-changing HTML elements. That’s made it hard for me to fix issues and led to frustrating experiences for customers — nobody wants to use a product where onboarding experiences spam you.
-
Ad blockers silently suppress the experiences for some users. Because of their approach to integration, the tools load third-party JavaScript code directly into your users’ clients. That means your users’ ad blockers regularly block the experiences they power. This suppression happens silently, and it’s hard to know who this is impacting making any analysis of the effectiveness of the experiences challenging. Worse, your users are also left in a product with none of the help, education, or guidance you intended them to have.
You can rest easy knowing that only ~40% of people run “Ad Blocking” software -
Breakages aren’t caught until they’ve done real damage. These frequent breakages are hard to troubleshoot, requiring long loops across PMs and developers. Because they’re often introduced due to unrelated changes and the flows aren’t tested in CI/CD, breakages go undetected until someone comes across unexpectedly flagging product metrics, long after the damage is already done.
The existing tools don’t fit into the modern product development process
- The tools don’t exist as part of the existing product development process. They introduce another parallel branch to stay on top of in the already complex world of shipping product. The lack of visibility leads to breakages, but it also means that every feature release or product change requires a whole bunch of extra coordination overhead. None of the investments teams make across deployment, testing, and other processes aimed at helping the organization ship quality product pay dividends here. Manual, tedious reconciliation abounds.
- They don’t work well with other tools in the product and data stack. While the tools do consume product data to target and trigger their experiences, getting data about how users interact with them into customer data platforms, warehouses, or product analytics tools is far more fraught. Many of the tools have purpose-built integrations to send events downstream, but because they own the UI and need to build one size fits all integrations, they’re forced to be prescriptive about event taxonomies and introduce inconsistencies in the team’s data that create drag and make analyzing the experiences alongside core product usage more difficult. Similarly, feature flagging and experimentation tools and workflows have to contend with experiences that don’t exist in code.
After evaluating a number of product adoption tools, we felt most confident about starting with an in-house solution. The existing products on the market don’t offer enough flexibility to be most compatible with our front end branding and technologies.
Your onboarding and education flows can’t be an afterthought
The consequences of having low-quality, brittle, poorly integrated experiences have grown as companies increasingly compete on their ability to effectively shepherd users through their journeys to value using just their products. To do this successfully, product onboarding and education must be treated as product work no different than the core product capabilities that create that value. The two must be thought of and built together. Treating it as an afterthought and bolting experiences onto a product not designed with them in mind is a fast path to failure.
But don’t just listen to us. The existing tools have galleries of examples of great onboarding experiences that mostly point to products that have built their own onboarding. My favorite example? Intercom’s own onboarding is excellent. Best in class even. And yet you can’t build it with Intercom!
Why Dopt’s approach is better
We’re approaching the problem in a fundamentally different way from the existing tools, building for developers (and their PM and UX partners). We pair a visual flow builder with SDKs/APIs to make building onboarding and education flows natively into your product fast and easy. Dopt’s builder lets you define the targeting, business logic, and content of your flows and our SDKs & APIs provide simple abstractions for leveraging those flows in code.
We deliberately don’t provide UI. We think that’s the part you need full control over in order to build great experiences (and we’re happy to point you toward some great open-source design systems if you need a tooltip, modal, or banner).
Dopt’s approach means you can:
- Design the right onboarding for your product and users
- Build higher quality experiences (that also perform better)
- Dramatically reduce both developer and non-developer time spent
How does Dopt differ from the existing tools?
- You get to use your own components and avoid wasting hours trying to make their limited set of components look passable. Dopt meets you where you are, letting you use your current FE components and technologies. You get the full flexibility of code to build relevant, contextual flows that fit your interaction model, meet your quality bar, and don’t get in the way.
- We’re building for developers, they aren’t afterthoughts for us like they are with the existing tools. We sweat the details on the small but important stuff that makes developing with Dopt a joy: versions, environments, tools for local development, and excellent documentation to name a few.
- We still give non-developers the tools they need to self-serve on targeting using customer data, defining business logic, and updating content and other assets. The team gets a shared backdrop to make collaborating simple, and everyone gets visibility into key flows and user activity.
- We fit into your product development process and work right alongside all of your other tools. Product analytics, feature flagging, experimentation, CI/CD, and testing will all work right alongside Dopt, no inflexible integrations or hacky workarounds needed.
With Dopt, the sky is the limit to what you build. Gone are the cookie-cutter tooltip tours that make people’s eyes glaze over.
Instead, you can build help and education directly into your product’s core interaction model to help users learn by doing or build a getting started checklist tied directly into the actions your users take in your product. You can even build tooltip tours. That’s right, sometimes they are the right component to use! But they will be your tooltips, and they’ll be part of a much greater whole.
We’d love to help you level up your product’s onboarding
Look, if you’re happy with the existing onboarding tools you’re probably not a great fit for Dopt. But, if like many others, you’ve disqualified them or are only begrudgingly using them because you were (rightfully) scared away by the complexity of building and scaling these critical flows yourselves, we’d love to show you how Dopt can give you a third, better option.
Sign up for a free account to start building with Dopt today or check out a four-minute demo or our documentation to learn more about Dopt.
Some more helpful resources
- If you’re working on improving onboarding in your product, read our playbook for building tailored onboarding
- If you’re looking for inspiration in how others have built thoughtful onboarding and education flows natively into their products check out Pageflows (it’s paid, unaffiliated with Dopt, and well worth the money)