PLG-focused VC on the sales and marketing strategies of product-led teams

Early on, I think quotas can be somewhat detrimental. In fact, what you're really trying to do early on is learning. When is the right moment for us to come in and turn this account into an enterprise account? What are the triggers that we can use to do this more scalably in the future? Early on, I think it's just a full normal comp package and salary, and the quota doesn't make as much sense.

Later on, it depends on what the model looks like. I think you see some companies that basically eschew most of the self-serve side of the funnel, and instead, they just say, "If it's a really small company or an individual, sure, they can self-serve. But if you are a real company greater than 100 employees, you're talking to a salesperson, and we're going to get you to upgrade to something. Then we're going to track that over time." In those scenarios, maybe it's so sales-led at that point that quotas are a requirement. But I think that there are other companies that rely much more heavily on the self-serve funnel and can probably get away with not doing quotas for a very long time because of that.

Permalink

One thing that I was somewhat surprised to hear in other conversations is that companies that are on Figma's organization plan didn't talk to salespeople, but just self-served into the higher tier. Do you think that's new, or is it just a sign of Figma's being superior as a result of its product and community?

I don't think that that's unusual these days. For best-in-class companies, it used to be the case that security features like SSO or whatever would be reserved for enterprise plans, which salespeople had to be involved with. That would be the tier where there'd be a "contact sales" button and you could get SSO then, and it was really used both as a carrot and a stick to get people to upgrade. It was, "You get this extra feature, but also if you need this feature, you have to talk to us to upgrade." I think that's becoming less common over time because it's becoming more of a standard, people just expect that it'll be available.

I think it's useful to distinguish between "enterprise" plans, which are the most expensive self-serve plan that you're talking about with Figma, and an "invoiced" plan, which is a plan where the sales team needs to be involved because they're negotiating with the procurement team, they're doing a security review, they're putting in a bunch of legwork, they might be negotiating different per-seat pricing or whatever it might be based on the specific needs of the customer. The stuff that is impossible to self-serve and is a requirement once you're at a certain deal size or certain types of organizations. Those conversations are required. There's no way you could self-serve into it. I'd be curious for Figma, presumably, there are some of those types of deals out there and how are they managing those? Is there something unique about that? I think their enterprise plan is best in class, but it's not wholly unique. I think there are a lot of other PLG companies that are doing a similar thing.

Permalink

We spoke with somebody from Canva and what we learned is that, if a company needs more than 500 Canva accounts, it can be more economical to get on a higher-tier plan that provides some discounts as well as better security.

A really common thing you'll see is a bunch of different teams using a product across an organization. Bringing them all together under one roof -- one master services agreement -- will enable the vendor to provide discounts, because now what used to be twenty disparate teams each with twenty users now is 400 users. We can provide a discount for that, as well as negotiate on details, like data security or who owns the data? Does the company own the data? Does the individual own the data? It makes a ton of sense when there are a lot of users to shift the conversation to sales to manage that process.

Permalink

Another thing we've learned that's interesting is right now the decision-maker who will sign off the budget for these tools is still the head of the function rather than the CIOs or head of IT. When do you think the decision-maker will decouple? When will the decision-maker become head of IT instead of the head of the function, who presumably would know their requirements and the features of the product much better?

I haven't had the experience yet where the head of IT was the decision-maker, ever. The experience I've had is that IT might be a blocker, but never the actual decision-maker. The feedback that I've heard from IT is something like, "Why do we need this tool? We already have this other tool that we have approved for security that does the same thing. Prove to me why we need a new tool." Then it's the job of the champion, as well as the sales team at the vendor, to convince the IT team why this is net new and better and ought to be approved. But they're not approving it. They're just trying to throw some wrenches in things.

Also, they very often are given edicts from on high that basically say, "We need to cut 30% of our SaaS contracts because we're overweight on SaaS contracts. There's no way all of these can be useful." 30% is not some scientific number. It's just somebody saying, "Let's cut as much as we can. 30% seems like a good number." The IT department is under pressure to try to consolidate. They're trying to find what tools can solve as many problems as possible, what tools are duplicative and we can get rid of, or what tools have the noisiest champions who are the most politically powerful within the organization that I don't want to get in an argument with them. Talking about Figma, I think this is where one of their superpowers comes from. One, they're used not just by design teams, but by collaborative teams. The product team and the marketing team also have accounts. But also designers will go to the mat to make sure that they can use Figma. That's really powerful for exactly these conversations.

You've talked about funnel ownership for customer success and how -- because now maybe the boundary between product-led growth and sales-led growth is more blurred as you cultivate your user base -- customer success as a function is shared across different teams. Everyone is motivated to help customers to succeed, but the ownership is more diluted across different teams. How do you see the ownership of customer success shared across different functional units, and what are the implications?

It really depends on the product. I think the role of customer success is a function of the product, more so than a distinct role. As an example, say your product is a relatively simple utility product, like Dropbox. We're talking about product-led growth here -- Dropbox is one of the original product-led growth companies. In that world, customer success is a quasi-support function. The deal is signed and then the customer success team is there to make sure that everybody answers questions quickly and that people are getting the most out of the product. They're probably tracking things like presumed NPS across the accounts. Maybe they're onboarding some new users every once in a while. I'm not exactly sure -- I haven't been in the bowels of Dropbox's customer success department. But it's relatively simple. It's probably exclusively post-sales. They're probably also focused on helping with expansion and renegotiating deals year after year.

Then there are products out there that are much more complex and open-ended, that aren't just like pure utilities. In those cases, I think customer success ends up playing a much more expansive role because they often have to do a lot of work: everything from onboarding to product education, to services like actual product services, implementation services, and so on.

The other thing I'll note is how much this can change over time. Early on, when a company is just starting, it might be the case that it's not even a successful team at this point, but it's the first go to market person, a generalist type person, maybe it's a salesperson, maybe it's a success person, whatever the title is. They're going to end up doing all the above: they'll end up being the educator, implementer, and maybe they also design the first contract in Word and send it over and get it signed. They're going to do it all. The trick is, how do you figure out what the right structure is for your company based on your product, the way that people adopt your product, and the way that people deepen their usage with your product?

Will that deepening of usage mainly be driven by product education or implementation help? Or will it happen as a direct reaction to a sales deal being closed? Dropbox might be an example here: once you sign a deal with Dropbox and people have Dropbox on their computers, that's the end of it. There isn't anything else to do. Whereas with a company like Figma, you care a lot about how people are engaging with the product, and you might want to do education sessions where you show off things that other people have built with the product and invite people to a community. There's all this other stuff that you might do to deepen people's usage of the product.

I don't know how much that answers your question. I think, ultimately, the reality is that success is a reflection of the needs of the product in a way that sales is not. There are always going to be some deals that just need somebody who can help usher something through security review and procurement and close a deal. That's always going to be the case for a software company. Success leads us in between worlds, where, depending on the product, they have to figure out the right leverage point for them to provide the most value.

Permalink

What are the challenges and transitions that a company will need to go through to see customer success get a seat at the executive level?

I could absolutely imagine companies where sales is the starting gun, not the finish line, and everything that happens after the starting gun is owned by success, and that the success team -- maybe it should be called something different than success in this case -- becomes incredibly central to how accounts grow and how they expand over time.

I think that highlights a tension in product-led growth companies right now, about who actually owns expansion. Is it the product team who's building expansion-related growth features? Is it the sales team who might own a quota number related to what the ideal size looks like? Or is it the success team who is actually talking to users every day and trying to help onboard them to the product and help them be successful?

If you are an investor and you're looking at companies, e.g. Figma, with these attributes of tension between different teams on expansion, what are the signposts that you look for to give you confidence that expansion will happen?

I think the thesis for a company like Figma is that it's a tool for designers, but because it's fundamentally collaborative, it's built with collaboration in mind. The bet that you're making with that design is that users other than designers will also be active in Figma. Once I realized as an investor that this is the downstream effect of the way that they've decided to design this product and the focus they've given to certain features and usability, what I would want to see is a lot of accounts where it's not just designers using the product.

Something that I've done in past jobs and would do is try to map out expansion over time: Who is the first user? Who did they invite? Then who did those people invite? Literally, map it on an org chart over time and try to see, "Are we actually seeing cross-team expansion? Not just within the design team, but am I seeing a designer invite a marketer and then the marketer to invite other marketers?" That would be incredibly powerful.

Another thing I would add to that is that this is something that you, as a founder, can fake a little bit. You can, behind the scenes, be talking to people and suggest to the designer that they invite the marketer. You can create this map or this data trail if you wanted to.

But what I would say as a founder is, you also want to make sure that that's happening in reality. Do that with a few accounts to understand, "If I suggest to the designer to invite a marketer, do they want to do that? Now do the designer and marketer work together in the product after I've made that recommendation? Great, good." I'm glad that I've de-risked that, but then I would want to de-risk this account that I haven't spoken to at all. "Let's just see what happens, are they going to invite folks outside of their function without me recommending it?" That's how I would think about that.

Sales and customer success are headcount heavy compared to product-led growth roles of engineering and product & design. What elements need to be in place for a company's product-led growth culture to be more tolerant towards headcount growth in these other areas as it scales?

Something that's true of a lot of product-led growth companies is a true obsession around the product itself, loving the way the product is built and what the onboarding experience is like. All of this stuff, just being obsessed with it. I think the longer you can hold onto that, the better. Because as you hire more and more people, they get further and further away from being obsessed with the product, because they're not joining because they love the product anymore. They're joining because you're a rocket ship and they want to get on board, or they're joining because they are an incredible sales rep and they want to sell the shit out of your product to make a lot of money. They might not have that product obsession. I would think about how to keep that as much as you can because, for a lot of these companies, that is a core part of the DNA.

The role of community with respect to UGC is well-known. Can you talk about how that supports the enterprise use case and sales motion?

I think it's fundamental because for most enterprise customers the way the first user was acquired was self-serve. And the way that that self-serve user probably initially got convinced that Figma or whatever was the tool for them was through word of mouth from the community or through being inspired by some template that made them realize what they could do with the product or whatever else it might be. This is why the marrying of the self-serve funnel and the enterprise funnel is so powerful if you can get it right because the low-touch top of funnel/word of mouth template-driven top of funnel -- that self-serve stuff -- can end up supporting enterprise expansion over time.

How does the community get integrated into the PLG company organization?

I don't have a playbook for anybody to follow or something like that. What I would say is, I think the two companies that are doing this better than anybody else right now are Notion and Figma. They have incredibly vibrant communities online, who -- it's not just that they love the product and evangelize the product, but I think, critically, they also build on top of the product.

Folks build Notion templates and sell those Notion templates. You can buy a Notion template for $80. That's amazing. One, it's amazing that somebody built that. Two, it's amazing that people are buying it. And three, it's amazing that Notion is enabling this. These are often third-party sites where you can do it, but they aren't shutting it down. They're clearly accelerating this a little bit. The same with Figma. Figma has plug-ins, and they have templates. Lots of amazing stuff that people have built on top of it.

The thing that I would say is I'm not 100% sure how you integrate it into the company. I just think that, if you have a product that is built like this, where it creates these evangelists, you need to be so aware of what they're doing and augment, accelerate, and amplify the things that they're doing are beneficial to you. In the cases when it makes sense to aggregate their efforts and put them on your own platform, do that as soon as you can.

Figma has done a really good job of that with their -- I don't know if it's called a marketplace or what it's called -- where they house all the plug-ins and templates. They've done a great job of centralizing that, giving their community a place to show off what they've built. They're really just building a platform, but what's powerful about the platform is that you don't need to be a super technical person to benefit from the platform. You can build some templates. Same with Notion. You can just build a Notion template. You don't need to be technical to do that. Once you've built that, you can now sell that to the world.

I look at Notion and think, "When are they going to expand their template gallery?" They have a few right now that you can buy. But if I were them, I'd be thinking about, "How do you blow this out and turn this into a massive marketplace?" That is a way to superpower the community. Now each of those users who has some template they want to sell, they're all going to be out there evangelizing Notion for you, and some of the people they convince are going to become the next enterprise customer for you.

It sounds like a very important driver to deepen engagement with the product.

I 100% think so. And as much as the community is hyped today, I still think it might be underhyped. I think it's actually that important. I would say it's underhyped in particular for enterprise software companies that are going super enterprise. Those types of companies very often give up on community, or they don't think it matters.

If anything, I would look to Salesforce as a great example of a company that has really focused on building a community with Trailhead. It's really amazing what they've done. You see the results of it, which is people love Salesforce and build businesses on top of Salesforce from a technical point of view. And also there are people who are Salesforce admins -- who define themselves as people who are experts in that tool. What could be stickier than that? You have tens of thousands of people worldwide who define themselves as being an expert in your tool. They do that because Salesforce created a community around it. More people should be learning from some of the old school enterprise players out there like Salesforce.

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.