Jan-Erik Asplund
Background
Daniel Zarick is the co-founder and CEO of Arrows. We talked to Daniel to learn more about the "PLG CRM" and how traditional CRMs are adjusting to help bottoms-up teams better sell their products, Gainsight and why standard customer success platforms have trouble getting adoption with startups, and building inside the HubSpot ecosystem.
Questions
- Could you tell us a bit about Arrows? What made you feel like the customer onboarding space was worth devoting years of your life to?
- Why has customer success been underserved as a function?
- Can you give us a “before and after” on how teams run this onboarding process before and after Arrows?
- How much are you able to automate through software and how much is human labor at the Arrows end?
- What’s your take on PLG as a motion and as a tailwind for you?
- Can you talk a bit about building for the HubSpot app store and how that helps with distribution?
- How are the traditional CRMs doing at helping teams execute on this PLG playbook?
- How do you see the data warehouse and the CRM co-existing?
- What’s your take on the emergence of the PLG CRM with companies like Calixa and Endgame that are looking to systematize the PLG playbook?
- What’s your take on Gainsight, which is the biggest public incumbent in the customer success space?
Interview
Could you tell us a bit about Arrows? What made you feel like the customer onboarding space was worth devoting years of your life to?
I was the second Product Manager at Twilio, and one of my big focuses was internal tools and other internal teams. I've always been very interested in supporting those sorts of users. I’d think a lot about “Who are the teams, internally, that just do not get enough resources or attention from their own product and engineering teams? Who are the ones grossly underserved yet high-impact to the success of a business?”
Early on, when we were building and testing different ideas which ultimately—through multiple iterations—became Arrows and the onboarding customer enablement tool it is now, we found that we really clicked with customer success teams. They tended to have similar worldviews, and they were very relationship- and customer outcome-driven.
It also seemed like a key, underappreciated function of software companies. If you look around at success and onboarding as functions for any subscription company, a lot of the revenue is very back-weighted. These are the teams that decrease churn and increase expansion revenue, which actually helps customers get to the outcomes that they bought the product for.
We saw that there were interesting business cases here and the sorts of problems that we liked solving.
Why has customer success been underserved as a function?
People are still learning how to bring success and onboarding into the customer journey. With things like the current transition to product-led growth (PLG), we are constantly changing how we build and offer software products.
Customer success is still figuring out where it fits in within the organization. A lot of companies look at the front-end of the funnel as the place to create growth, and then the post-initial sale takes a backseat.
However, a lot more companies are beginning to understand that a customer might start paying for 50 seats today, which feels like a small sale, but in three years they can grow to be paying for 1,000 seats. That, in part, comes from sales conversations, but mostly it’s driven by successful onboarding, enablement, and customer success functions.
Can you give us a “before and after” on how teams run this onboarding process before and after Arrows?
What we saw was that teams would send these very long emails with a bunch of bullet lists that said, "Hey! Here's what you need to do next." Sometimes there would be a Trello board or Asana project, Google Sheet, Google Doc, Notion page, or something of that sort they’d also share with the customer.
Some people believe that’s a failure of the product, but the reality is that for any complicated product, actually clicking around the UI is maybe 20 or 30% of the adoption process. It's much more about managing organizational change and messy humans.
Here’s an example: if I go and buy us a new healthcare reimbursement product, how would I navigate away from the current solution we have to the new one? What changes does our organization need to make? How do I communicate that to our team? On which dates do I need to take which steps to stay compliant? Building that task coordination tooling is rarely core to someone’s product, but it is critical in helping any team navigate towards the goals they want that product to help them achieve.
What we've found is all of those long emails and Google Docs and project management tools do not help me as the customer feel confident about the service I'm using. They don’t assure me that I'm actually going to get to the outcome that I'm trying to buy.
Arrows is focused on giving your customers a roadmap to help them go from where they are today to where they want to go. And because every customer is different, you can personalize that plan for each customer so they actually take the steps that they need to at the right time. Often that's not just steps that one person's taking, it's a whole team of people who are involved in that process, which is what makes it different.
How much are you able to automate through software and how much is human labor at the Arrows end?
Our core design philosophy is that it's not about taking humans out of the loop but about using software, automation, and systems to enable humans to do what they are able to do, better. Humans in the right part of the loop.
We have a lot of companies who sign up because they want us to help them automate task reminders and things that fall into the “customer homework” category or manual nagging workflows. Whereas strategizing what the actual roadmap should be for a customer, the steps they need to take, and helping communicate why it's important and valuable to them is where a human should be in the loop.
The other thing that we believe strongly is that no single tool will actually work for every end-user or customer. It's really about giving customers the option to onboard or learn the product in a way that works best for them. Shareil, from the Arrows team, calls this “giving 100% of users the option for onboarding” without expecting that 100% of users will be onboarded. Some people want to watch a lot of videos while others want to self-serve. Some want a human to hand-hold them through each step. The teams in the companies that are scaled for this or do this best will offer a choice between multiple routes.
At Arrows, we help navigate. You want to self-serve? You want to talk to a human? We can enable that.
What’s your take on PLG as a motion and as a tailwind for you?
We think of PLG as one ingredient in the mix. No company is purely a PLG process. All the classic example companies that people think of—Twilio, Figma, Asana, Zapier—have sales and sales-assist functions, account management, and customer success.
PLG is a trend of sorts, but the lessons in it are here to stay. The strategy aligns with how many customers actually would prefer to buy. Understanding and supporting that route is likely to be beneficial for most companies. However, it does not give you permission to abdicate the role of actually helping customers figure out what they need to do, inside and outside of your product, to get to their desired outcome.
If you think about any complex goal you have, for example, “we want to increase X“, a lot of the work actually happens in the decision-making process of, “What is X? Is X a reasonable goal and how will we get there?”
You’d need to know which teams have to be involved, the decisions you need to make along the way, how you need to roll it out and communicate it. Only so much of that process can be done within the walls of any product you’re using to achieve those goals. So, product-led growth is great in allowing customers and users to enable and discover how they might serve themselves, but rarely does it stop there. Every customer is different, and has unique problems, so they often need guidance as well.
That's why you hear Twilio, Zapier, Asana, and all these companies that are focused on self-serve and product-led playbooks actually work directly with their biggest and best customers. They have a human in the loop to help strategize and consult with the customer how to get from point A to point B.
Can you talk a bit about building for the HubSpot app store and how that helps with distribution?
Earlier this year we deleted the Arrows dashboard and replaced it with a deep HubSpot integration.
Their app marketplace and ecosystem strategy are still very, very early and leave a lot to be desired. But we are excited for where it’s going and the enthusiasm for HubSpot in their community is extremely high.
We use HubSpot ourselves and have seen really exciting progress in the product and ecosystem in the last few years. We noticed a lot of high growth startups start on HubSpot and actually scale on it longer than they would have a few years ago, especially as HubSpot's become more robust.
Generally, startups buy HubSpot for marketing automation. Now that the CRM product has matured, startups are scaling their sales and CRM usage on HubSpot longer, where they would've normally switched to Salesforce sooner. We believe that trend will continue.
We also see that customers and users on HubSpot are generally able to take action, make changes in the system, buy, and adopt faster. There's rarely an admin blocker like on most Salesforce installs. While we consider Salesforce a platform we want to work with eventually, we decided to focus first on the HubSpot ecosystem.
How are the traditional CRMs doing at helping teams execute on this PLG playbook?
Salesforce, HubSpot, and other CRMs are doing a pretty good job of enabling the PLG playbook. No tool is going to be perfect or solve everything. However, the benefits of being in one place generally outweighs the drawbacks of being across multiple and somewhat more purpose-built tools.
By deleting the Arrows dashboard and leaning into being attached directly to the CRM, we actually made our product and HubSpot both way better.
For us, we looked around at the changes in how companies manage data, like reverse ETL products and a lot of focus around having a clean warehouse and CRM. We noticed that people were building tools that splintered teams. Now we're seeing a consolidation back to less tools or less UIs.
There's more software inside companies than ever before, but it doesn't necessarily need to create more “inboxes” for those teams to check. So having Snowflake as your warehouse, Salesforce as your CRM, and a bunch of tools that hook into that may actually help create cleaned-up data across those platforms and end up being more valuable than splitting across a bunch of products with their own dashboards, because you're unlikely to actually solve many problems. In fact, you'll create new ones.
That's what we've tapped into ourselves. We want to be a singular, familiar UI for the customer across different stages of the customer journey. No matter what tool a team is using on the backend to serve that customer, it shouldn’t affect the customer experience.
How do you see the data warehouse and the CRM co-existing?
They sit adjacent to each other. The CRMs have built a very powerful set of UIs, reporting infrastructure, workflow automations, and all sorts of useful things that are helpful when consolidated in one platform. However, that doesn't mean that they can and should solve everything for every team out of the box.
On the flip side, I struggle to see many GTM teams enjoying having 10 different products, or 10 different inboxes, that all live on top of something like Snowflake. There will of course be purpose-built tools that you go to directly on occasion. But in your day-to-day work, you will prefer having a single tool that handles automations, workflows, reports, visualizing a pipeline of where customers are, etc.
That's where we see reverse ETL and the new crop of data tooling being very powerful. You have a lot of tools, but you want less inboxes for your team to have to visit to do their job to support customers.
What’s your take on the emergence of the PLG CRM with companies like Calixa and Endgame that are looking to systematize the PLG playbook?
The PLG stuff is interesting, and I’ll continue keeping an eye on it, but don't give me a new UI. That is literally why we deleted the Arrows dashboard. We didn't want to make a great HubSpot or Salesforce integration and have our dashboard.
We are signaling to our customers and prospects that we are not making a new source of truth or another inbox for their teams to check. We are incentivizing ourselves to deliver the best experience to you in the places where your team already is everyday. These teams open up the CRM every day, check for reports, and look at the pipeline. How do we then generate our own proprietary data that is valuable and useful to them? We don’t need to deliver that data solely on our domain, we just need to be the generators. Then we can push that to where teams can take action on it.
Sometimes I wonder if smaller teams prematurely buy customer success platforms because they're mostly rejecting a poorly configured or messy CRM their company already has. By doing so, they're not buying it for its true benefits, but because they hope it's going to magically solve those problems. Instead they’re splintering their data and teams across multiple tools.
All that effort would likely better serve their needs if they redirected it towards improving the processes, data, and workflows in the CRM itself. Then you’d maintain visibility with the existing teams, and be on a much better foundation when it’s time to adopt more purpose-specific tooling.
What’s your take on Gainsight, which is the biggest public incumbent in the customer success space?
When we started out, we thought a lot about success platforms. We felt early on that Arrows was going to grow from a customer-facing action plan into a new customer data platform and build all these workflows around the customer journey on that data. It was going to try to become a new customer success platform.
But if you look at the size of the customer success category, the number of customers is in the order of a few thousands across all those companies. It is likely 10,000 or so. When you look at the number of companies that buy a CRM like HubSpot and Salesforce, they are each in the hundreds of thousands. The total category has millions of customers.
On the one hand, the amount of work and time it takes to set up, configure, and buy a platform like Gainsight is very challenging. When you talk to companies that set these up, it takes months at best, and there's a lot of failed roll-outs for these sorts of products. That’s not a statement on the products, but more a reality of the complexity of the proble.
When we designed Arrows, we built it to be something that you could demo in the morning and send to a customer in the afternoon. Getting started is very quick, and you can progressively layer-on deeper integrations, workflows, and automations over time once you see what’s working.
From a market category standpoint, we deleted the Arrows dashboard and leaned into the CRM to try to better tap into the larger market of anybody who uses a CRM to manage their internal process. We wondered, “How do you give your customers visibility into what they should do that drives the internal object through stages of the pipeline versus being a wholly managed onboarding or customer journey platform that your team has to go adopt?” If we look around at the success platforms, the size of market opportunity there is provably limited.
By removing a big chunk of our product and more clearly expressing ourselves as an extension to your CRM or customer data platforms, we saw the opportunity became much, much bigger.
Disclaimers
This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.
