Scaling Your B2B Product? Be Sure to Consider These Areas First.
With growth comes challenges. When your B2B startup begins entertaining larger deals, your customers’ needs grow in complexity. And when you scale to meet those needs, it’s easy for your product to fall short. The good news is that you can learn from the experiences of other B2B SaaS companies to predict where many of these shortfalls will occur.
In working with product leaders at B2B SaaS companies, we’ve seen similar patterns and themes as these companies scale. Every company is different, and not all of this is exclusive to B2B SaaS, but we find these to be the most common areas that need attention when scaling:
- Roles and Permissions
- Onboarding Experience
- In-Product Communication
You won’t be able to anticipate every problem, but you can shore up these known troublemakers. Knowing what to anticipate as you scale enables your team to better prepare and to reduce future headaches.
Roles and Permissions
Large enterprises have greater expectations and requirements around workflow and accountability within any product. This means that as you scale your product, you may need to create additional, differentiated layers of permissions to accommodate for different types of users and to meet the workflow needs of your customer’s organization.
These workflow requirements in a product reflect the complexity of growing organizations and they exist for the same reason—accountability. Large organizations need these processes in place to ensure quality and fit their existing workflows. If your product doesn’t provide the levels of control needed, your ability to sell to larger enterprise customers may be limited.
As an example, Octiv is a document generation platform that was recently acquired by Conga. When we worked with them to design the initial version of their product (they began as a Studio Science Labs company), permissions levels were simple. Organizations had standard users, managers, and admins—with each tier assigned a default set of permissions. However, as Octiv grew to pursue deals with larger enterprise clients, the requirements around roles and permissions became exponentially more complex. Collaboration within documents also became a higher priority, which has its own implications on permissions. In addition to different user types, large organizations required granular controls over which users could view, edit, comment, and manage documents. Through several iterations, we designed features within Octiv that allowed their customers to assign granular permissions to different user types, invite outside collaborators, and build specific approval workflows.
We often seek to minimize complexity whenever possible to create a more seamless experience. However, in this case, the added complexity was necessary. Adding this new level of control enabled Octiv to appeal to a new tier of customer, pursue increasingly larger deals, and continue to scale.
The importance of the customer onboarding process shouldn’t be a surprise. In just minutes—or perhaps even seconds—a potential lifetime user can either start building loyalty toward your product or can turn away for good. The onboarding experience is critical from the start, but as you scale, even seemingly minor improvements to your retention rate can have significant long-term effects on your ARR.
If your onboarding experience starts with a series of popovers showing customers where all the different features are, that’s a clear sign that it’s time to reevaluate. These kinds of popover-based tours can be useful, but they are too often used to introduce customers to a product during onboarding. This results in a lackluster first-time experience. Your onboarding process should be informative, but don’t think of it as a ”hit list” of features that you have to explain. Instead, think of it primarily as creating an amazing first impression. It’s a selling opportunity.
Rather than requiring users to chase popovers around the screen for those first critical moments within your product, spend some time thinking about how you can make your users’ first experience with your product as engaging as possible.
Before designing your onboarding experience, consider the following:
- What do customers need to know to get the most out of your product?
This informs the educational portion of your onboarding experience, which can vary in importance and scope depending on the complexity of your product. This doesn’t need to be a deep dive into the full feature set, but instead should focus on the most critical fundamentals to get customers started. Remember that onboarding goes well beyond the first time experience and you can always progressively introduce deeper functionality to them when the time is right.
- What is the moment within your product that customers realize value?
Based on your understanding of your existing customers, what milestone do they have to hit in your product before they realize the value your product provides them? The first form they build? Once they’ve added 5 team members? If you don’t know, then ask them.
- What is the fastest way to get them to that moment?
Once you know the moment of value that you’re trying to get to, figure out how to prioritize this. It doesn’t necessarily need to be the normal flow within your product, as long as you get them there in a way that feels seamless and makes your product’s value obvious to them.
The sooner you can get a user to see the value they get from the product, the better your chances of retaining them. This not only solidifies the value you provide them, but also helps users understand how to navigate the product. With some worthwhile thought and effort, your onboarding process can serve to welcome, educate, and even inspire your customers.
As you scale, somewhere along the way, you’ll reach a point where your customers are using other products to communicate about the work happening in your product. This is the time to consider providing in-product communication.
Let’s say customers are using your product to manage and edit documents, but their communication and collaboration is happening in email (or Slack, depending on the industry). When your customers consistently use a platform outside your product to talk about work that’s being done within your product, bringing this communication into your product can improve engagement, create a more seamless experience, and provide greater value for your customers.
The decision to add messaging should not be taken lightly. As anyone who has implemented communication into their product will tell you, it’s no small task, and adds significant overhead. With these steep costs in mind, the question to consider is whether adding this feature will drive engagement, retention, and/or revenue to the point where the benefits outweigh the costs.
There are also different kinds of collaboration, so take the time to understand exactly how your users need to work together and communicate. For example, are they collaborating with specific tactical input on documents, events, or projects? Or are they using more free-form communication and discussion? The answer should help you decide how to move forward. A strong appreciation for how your customers are using your product will be key in designing the right type of communication features.
Permissions, onboarding, and in-product communication are three of the most common areas to anticipate growing pains when scaling your B2B product. To be clear, this is no substitute for genuine customer research. In fact, customer insight is the only way you will know when exactly to focus on these aspects. Be proactive and keep your finger on the pulse of your customers’ needs so that you’ll know when it’s appropriate to add these to your roadmap.
Don’t wait until these three areas become a pain point for your customers—or a dealbreaker for prospects. Growing pains are unavoidable, but anticipating how your roadmap will need to shift as you scale will ease the burden.
Miro’s Kate Syuma shares how the company’s growth team iterated smart to improve the user onboarding journey for their popular collaborative platform.