My chat with Alexa Grabell, Cofounder & CEO of Pocus
Demystifying product led sales in a sea of similar labels that techies love to come up with
I pick people to talk to based on what I'm curious about and feel dumb about. I heard about product-led sales on a podcast. I recalled seeing a thread on Twitter about that idea a while ago. That thread happened to be Alexa’s! I thought I would reach out and ask her some basic questions about what she is up to at Pocus. I specifically liked learning the engineering specifics of what is happening behind the scenes. Her commitment to what she is doing shines through how she talks and the investments she’s made in content and community to evangelize what she considers a new category.
Sar: I pick people to talk to based on what I'm curious about and feel dumb about. I recently heard about product-led sales on a podcast. I recalled seeing a thread on Twitter about that idea a while ago. That thread happened to be yours! I thought I would reach out and ask you some basic questions about what you are up to. I talked to the CEO of RevenueCat a few weeks ago. They help consumer apps understand and manage their subscription business. There are some similar ideas here. I asked him if he uses RevenueCat to run RevenueCat. I’ll ask you the same question. Do you use Pocus to grow Pocus?
Alexa: Yeah. It's funny. We have insight into many PLG companies using Pocus to figure out their pool of users. Many VCs have joked they would love to use us to find growing companies. So we could become a VC tool!
Sar: If you ever get tired of building a SaaS company, this is your pivot. You could just become a software-driven venture firm yourself!
Alexa: Exactly.
Sar: I want to talk about the big picture first. We used to have free trials. Then came freemium. Then we got the self-serve model, which led the path to bottom-up growth. Later, product-led growth became all the rage. And, now, we have product-led sales, which is where you come in! What is going on?
Alexa: I think the word PLG is a buzzword right now. Everyone has a different definition. Some people are very precious about the definition, saying, ”you're not PLG unless you're Atlassian or Slack, or you need to get to 10 million in ARR before adding a sales team, and it's a viral product.”
Product-led growth, to me, means the product gets the user in the door, and the user can get value out of the product before talking to a salesperson. That's where I get very passionate about product-led sales, which is much simpler. I don't care if you call that interaction a free trial, freemium, or PLG. What matters is someone interacting with the product gets value from it without talking to a salesperson. Buyers want to try the product before they buy it. Sellers would rather sell to the people that already know and love the product.
Sar: My rough understanding of what you just described was what people called bottom-up growth. Or was that something else? Didn't we have five years of SaaS people talking about bottom-up growth?
Alexa: Totally. I think the difference is there's no defined playbook for salespeople. There are best practices around managing SDRs, setting up a commission-based comp structure, creating sales quotas, etc. I have talked to so many CROs of PLG companies, and no one has a defined playbook because PLS is different. You are prospecting from users already on your product, which is different from cold outbound. Bottom-up growth has been around forever, but thinking hard about how sales work on top of that is newer.
Sar: So you are not talking about top-of-the-funnel growth? You are one step lower in the funnel. It’s like we have a bunch of people using us; how do we drive sales?” versus “how do I find more people to use us.”
Alexa: Yes, a user can be on the product without paying. From there, there are a couple of paths or playbooks you could run. One path is how you convert free users to paid customers. Another is how do you roll up fragmented usage of a product (let’s say Calendly) by employees across teams at a company into a consolidated enterprise contract?
Sar: I’m a free Calendly user, so maybe they should start using Pocus! You have been evangelizing this category and trying to align the industry on shared language around how to think about product-led sales. You do a lot of great content. Would it be fair to say that Pocus is trying to operationalize your specific definition of how you think about this with an opinionated product to drive sales?
Alexa: Sort of; I’d say we're building a Product-Led Sales platform that takes all product usage insights and turns them into revenue. We don’t want to be prescriptive in telling you exactly how you have to run your business because a Product-Led Sales motion can look very different for each company. For example, the PLS playbooks for a productivity tool versus a dev tool versus a B2C tool are different because they all have different types of users and conversion goals — but they all need to know how their users engage with the product. We give go-to-market teams the keys to accessing product usage data and building playbooks. We suggest the frameworks and templates that make sense and enable them to build out their motion in Pocus. We are taking a different approach from most companies, especially in our space, that have an opinionated take on how Product-Led ales should work. You can’t have an opinionated take when you work with every type of product-led company.
Sar: Ah, I got that wrong. Leaders at those companies might have different perspectives on how they think about this. So you believe your job is to give them just a workflow product where they can customize things. That brings me to my next question. Real customization requires engineering lift. Your product doesn’t require the engineering resources of your customers. How do you deal with that tension? I associate customization with engineering work.
Alexa: Oh, I love this, okay, so there are a couple of things we did. Our broader vision is unlocking the power of data for everyone, especially the non-technical teams. The modern data stack has made data powerful for data teams, product teams, and engineering teams. Go-to-market teams like sales, marketing, customer success, and ops have been left in the dust because they don't know how to work them and don't have access. So that's where our long-term vision comes into play. How do you do that? How do you build something flexible and customizable without requiring code? There are three key ingredients:
1. We built a flexible data model. You bring the data to us from your data warehouse and CRM; you don't need to re-engineer your data warehouse. We can do all the transformations in Pocus. We have an in-app SQL editor so that data onboarding can be done by BizOps (rather than a data engineer).
2. We created custom objects. Let’s take Salesforce as an example. It’s very structured in that there are accounts and leads, but most people don’t think about their business in that way. Companies may have accounts, workspaces, domains, teams, users, etc. You can define all of this in Pocus without writing any code.
3. We have drag-and-drop dashboards so you can visualize the data you want. You can create playbooks and automation with dropdown features. We'll give you the starting point with templates and basic features, but you can go in and edit it however you want.
Sar: So the heavy lifting of taking the unstructured mess and associating user profiles from the data warehouse to the CRM systems that the sales team uses is done by you, and it magically just shows up on the dashboard?
Alexa: Exactly, dashboard magic. We spent six months building the data infrastructure to make this happen. We have integrations with Salesforce, HubSpot, Redshift, BigQuery, and Snowflake.
How do we map these two data sets? You write the SQL query to pull a table from Snowflake, then you hit the run query, and then it'll spit out example database rows in Pocus. And then, within Pocus, you can decode each table column to tell Pocus if it’s a field to bring in, a field you’d like to join with another table in Salesforce, or an association to another table.
Sar: So you have two data structures to work with, one on the warehouse side and the other on the CRM side. You're breaking down the data sets to their parts, and then you're enabling your users to connect parameters in one set to parameters in the other set. And that's how the magic happens when you look at the dashboard. You're bypassing the entire ecosystem of product analytics tools. You are going straight into warehouses. So no integrations are required? Or, do you believe those tools are not relevant to what you are doing in the first place?
Alexa: Oh, no. I'd say we're very different from a product analytics tool. It's a different buyer. They see things from a top-level view. Sales reps don't care about aggregated numbers. They want to see what specific users are doing with the product.
Sar: Salespeople would need a micro view of things. They want to know who they should talk to today versus a PM who wants to know how many users we have today and what usage patterns we are seeing.
Alexa: They want to know who signed up for the product. Is that a decision-maker at this company? What did they do? Should I reach out with a customized message or take this action in my pipeline?
Sar: Yeah. Who sets up the events to capture product engagement touchpoints?
Alexa: We are learning it depends on the company size. We work with bigger companies that have clear goals for playbooks, like converting customers from free to paid. Every time a senior decision maker signs up, they would send a particular message. Or, they would create this deck every time there's a usage spike. They can program that into Pocus. It's usually sales ops people. And then we spit everything out from there. Some of the smaller companies want to know how the bigger companies do it. We give them the templates to start with, and then they can configure them.
Sar: Do the actions necessarily have to be outbound communications?
Alexa: It can be any action you want, including user communication, like sending an email through a Hubspot sequence. You can take action by opening up another tool. Many people link to their internal admin database—some open LinkedIn or Salesforce. You can push data elsewhere. You can send it to a Google sheet; you can create a Google slide deck where it'll pre-populate all your usage data.
Sar: I have seen salespeople do that manually. And it's an insane thing to be doing. Talk about what you used to do before Pocus and your perspective on Business Intelligence tools.
Alexa: Yeah. I was in sales ops before starting Pocus, and this is stuff I was manually doing. I'd log into my internal admin dashboard. I would see user IDs. I would copy those IDs to Salesforce to try to connect users’ IDs to profiles in Salesforce. I would pull up a Looker to make sure I was making the correct associations. It’s a lot of cross-referencing between multiple tools.
Sar: I've seen people do that; I’m like, yeah, I'm glad I don't do that. In terms of the product surface, over time, you start replacing many tools that people use internally, right?
Alexa: Exactly. We're replacing tools that sales reps are using that were never built for sales reps to be used. BI tools like Looker are in that category; companies try to get sales reps to use them. Sales representatives don't adopt them for various reasons. Looker was not built for a salesperson. It doesn't allow you to go from insight to action.
Sar: BI tools are great for a top-down view of things. Looker’s very annoying! What would be the downstream effects on a company using Pocus? Would companies have to rethink how the teams are structured? Would business metrics need some re-imagination? What technical or cultural changes would be required? What are second-order effects on a company that successfully uses you that you might consider as a fully onboarded user?
Alexa: So I'll talk about the benefits of Pocus first and then touch on the downstream effects. Pocus’s benefits are twofold: First is increased revenue and finding new revenue opportunities. The second is reducing the time it takes for sales reps to flip between various tools to find the data they need (eg.. Looker, Mode, Airtable, Zapier, etc.)
Product-Led Sales, in general, requires a behavioral shift. For example, you need new compensation plans to create the right incentives. You don't want a sales rep running after every self-serve user. You want to create the right org structure. Account Executives are now in charge of both new business and upsell.
Sar: In a world where you guys become extremely successful, do you think companies would lean less and less into charging up front, which means there's a greater need for more top-of-the-funnel growth, which means you're pushing your revenue milestones further out? No one accuses any Silicon Valley company of being made too much revenue.
Alexa: It's a good point. You can still be generating revenue. There are many self-serve products out there that you sign up for online, but you're still paying for them without talking to anyone. There is this concept of the optimal time to wait before engaging with the user and pulling forward that revenue. If I wait until a customer is fully activated into the product and sees value, they’ll spend more on it. So, you wait three months for them to get onboarded onto the product before having that conversation, rather than wasting a sales rep’s time trying to sell them on the value. So I agree - in some instances, it could look like revenue is being pulled out, but it’s a more cost-effective way to do it in the longer term.
Sar: What concerns do you have regarding this category?
Alexa: I am concerned about the defining piece we discussed. Many say, “there is no Product -Led Sales without a viral product that layers sales on top.” That is not the case. That’s the perception. But the reality is that every company with product usage metrics and a sales team can do Product-Led Sales.
Sar: So your take is you can methodically do this without having your product go viral. But the virality of the product school of thought, which I believe comes from the social networking school, is that you have to have a lot of users first and then monetize a tiny fraction of them.
Alexa: Yeah, exactly. A few generational companies, like Figma, Notion, Airtable, Slack, and Atlassian, have social virality every year. But that doesn’t mean Product-Led Sales can’t apply to most companies that don’t have that virality.
Sar: So you disagree with the conventional wisdom founded on survivorship bias, which is the story of startup advising in general.
Alexa: Yes, Exactly.
Sar: What big bets or hypotheses have proven true so far?
Alexa: We had always believed we would need a flexible data model and custom objects and that we shouldn’t be prescriptive or opinionated. And that has proven to be true. Another big bet was sales reps need to be in control, which is where the no-code piece comes in.
Sar: What have been significant early learnings shaping your go-to-market and product roadmap?
Alexa: As we started going more and more upmarket to bigger companies, you get further away from building CRMs. Smaller companies are more open to adopting a new CRM system, and it's been interesting learning. Smaller companies are looking for more traditional CRMs for pipeline management, forecasting, etc., so we’d be working towards feature parity. Whereas larger companies are looking for a purpose-built Product-Led Sales tool.
We’re finding success with upmarket customers because they’ve understood that their CRMs are glorified databases, so we’re connecting that data with the data warehouse. With larger companies, there is a larger volume of data to sort through,t, making the value of Pocus much clearer.
Another learning is that scoring should be transparent because GTM teams distrust black box models. Even if you’re doing data science in the backend, it needs to be transparent and editable by go-to-market teams. That’s been big learning that shaped our roadmap. We want non-technical teams to be able to go in and make adjustments to their scoring model.
Lastly, we learned just how new Product-Led Sales is and how the best frameworks and best practices don't exist yet. Our GTM efforts focus so heavily on education and community that our community becomes a flywheel for how-to guides, learnings, and playbook templates.
Sar: What key risks or challenges do you think about often or mitigate actively?
The learning curve for PLS. We’re creating a new category, so we need to educate on PLS for folks to adopt the product. That’s where most of our marketing efforts go and why we put so much emphasis on category creation, community, and content
Sar: What are your plans for the future of Pocus?
Alexa: There is so much in store for the future of Pocus - for our product, community, and customers. We’re building a ton to drive towards our vision to bring the power of data to non-technical teams. You can expect a ton of new features, more community activities, and more use cases across various types of customers!
Previous chat :
