Table of Contents
What is B2B SaaS onboarding?
For all the talk about how PMs at every company are different, a lot of the problems we solve are the same. One of the most common and critical projects a PM will work on over their career is product onboarding, either because they join a team owning the new user experience, or because they’re launching a new product and need to figure out how customers will actually learn and adopt the new functionality. But what exactly is onboarding?
Onboarding isn't about being led around an office, rather it's about diving into that first bit of work
Onboarding is not a software-term. It happens every time we join a new company or team: we get introduced, acclimated, and then we start doing the work to develop our sea legs. Onboarding, for most roles, isn’t so much about being led around an office (back when we had those) and told where the bathrooms are or where to find spare paperclips. Rather, onboarding is about diving into that first bit of work: that initial project where we start to do something, and through doing so, become embedded within a team and set up for success.
Within software products, onboarding means many things. It is well-crafted empty states that hint at what you’ll see once you take some action. It could also be curated flows that guide the user to take actions that show product value, before they’re exposed to the full UI. But more often than not, it is a set of in-product messages, or tool-tips that explain what features live where. Yet the goal of onboarding in software is the same as onboarding at work: how do we help a new user get going to use the product in a way that shows them value?
In my own experiences, both as a part of a dedicated Growth team at Intercom, and as the head of product at atSpoke, I’ve found that onboarding is incredibly hard to get right and even harder to iterate and maintain.
SaaS onboarding: Why it's so hard to get right
- Multiple personas need to be onboarded: the first user (often an admin) has a different path to “value” than the nth user, like an employee, or business user. And realistically, new people are joining and leaving your product all the time as part of natural business turnover.
- Onboarding experiences are designed without human-interaction in mind. In B2B SaaS, humans in the form of Sales, Success, or Support, play critical roles in selling and activating the customer. Today, there aren’t easy ways to incorporate those human-iterations and decisions into the in-product onboarding experience, so they’re sometimes ignored.
- It’s often unclear who owns onboarding, or different teams own onboarding for different customer segments, making it challenging to create a cohesive, scalable experience.
1. Onboarding different personas
The first piece of complexity is that onboarding is not one-size-fits-all. Unlike consumer products, B2B SaaS products usually have multiple types of users, not to mention different configurations within each customer.
There’s the individual who’s in charge of “setting up” the product. That individual (often an admin) bears the brunt of configuring integrations, inviting the rest of the team, and educating other colleagues on why they should use the product (and how). At first blush, it would make sense to focus onboarding efforts on that single individual. And yet single individuals are easier for someone like a Customer Success Manager to identify and train, in contrast to the dozens, or hundreds of other additional users who are added to the product who lack context. So, on second thought, perhaps it'd make most sense for a product team to concentrate on onboarding experiences for the nth user.
The single admin is the most critical person to onboard well, yet is also the easiest person to identify and hand-hold
To design an onboarding system that can effectively onboard both (or more) types of users, you need good targeting. One way is to look at the roles/permissions a user has and trigger different flows based on that. Another is to ask the user directly what their role or goal in using the product is. Finally, one can make an assumption that if the product is sufficiently “set up” that all subsequent new users joining are in fact, the nth user.
Regardless, the biggest mistake would be to treat all users of a product the same way, and guide them through the same flow (unless of course, all users truly engage with the product in pretty much the same way).
2. Combining the human-elements with in-app support
For the vast majority of paying customers, onboarding happens through a mix of human and in-product interactions. That means there’s much more to onboarding than what happens in the UI or via emails. A common mistake is to design for the in-product experience in isolation from what’s happening around it, and this can lead to account managers turning off the in-product experience for larger accounts.
There are many reasons this human component is necessary. For example, CSMs use kickoff calls to prioritize goals of the tool with the customer — that consultative discussion leads to different paths of onboarding and can’t be simply replaced by a modal that asks the user what role they’re in. But a simpler reason is that people are busy, and when a CSM can book a 1 hour meeting with the customer, that’s 1 hour of the customer’s time and attention that can be used to make progress, build momentum, and tailor next steps.
Design in-product onboarding with a plan for how customer success might modify or adapt the content for specific accounts
If your product team is going to invest in building onboarding, consider how you might design a system that allows a CSM to easily customize the steps or language for a specific customer account (and type of user). Ideally, this system would also give each CSM visibility into which actions have already been taken, or when progress has stalled, so the CS team can spend less time chasing after each customer, and more time in targeted consultations. The goal isn’t to bifurcate the two worlds, but rather give each side insight (and influence) into the other.
3. Aligning the org around a unified onboarding experience
Whenever the target customer segment changes, when the core use case changes, or when there are significant modifications to the product, onboarding should also adapt. The trouble is that most organizations don’t have a dedicated team that owns onboarding. It can be challenging for Product teams to own onboarding metrics when many actions are driven by CS interactions (see above). It can be equally challenging for CS teams to exclusively own onboarding metrics when the success of using a product has a lot to do with how easy that product is to use!
Onboarding takes a cross-functional team to implement well
Most commonly, I see CS teams owning onboarding metrics for larger accounts (often “time-to-implement” plus some level of NPS), and Product teams owning onboarding metrics for SMB or freemium users (% of users taking a key action). But the real prize is to figure out how to collaborate across the two, perhaps with Product designing a base set of flows and again, giving CS tools to modify and scale those flows for larger accounts.
-------------------
It’s all tradeoffs in SaaS onboarding
Knowing about these common mistakes doesn’t mean it’s easy to address them. Especially in resource-constrained startups, everything is a tradeoff of resources, time and attention. As we’ve been growing and onboarding new users to Bento, it’s been painful to notice all the ways we could improve customer activation but realize there’s a long set of competing priorities to build core product and fix bugs.
I’m excited to see how others have tackled or addressed these challenges and tradeoffs and keep the conversation going! Activation doesn’t stop with the first user, it picks up with every new user at a customer, and with every new product release and building a strong model of “everboarding” will be an important part of growth and retention.
