In this episode of the Startup Field Guide podcast, Sandhya Hegde shares her framework for the three modes of product-led growth, and how some iconic companies pursuing PLG found product-market fit: Snyk, Webflow, and Nextdoor. 

‍

Be sure to check out more Startup Field Guide Podcast episodes on Spotify, Apple, and Youtube. Hosted by Unusual Ventures General Partner Sandhya Hegde (former EVP at Amplitude), the SFG podcast uncovers how the top unicorn founders of today really found product-market fit. 

‍

If you are interested in learning more about some of the themes and ideas in this episode, please check out the Unusual Ventures Field Guides on product-led growth, building self-serve products, and choosing the right bottom-up SAAS experience.

‍

TL;DR

• In this masterclass on product-led growth, Sandhya Hegde walks through the three modes of PLG for software companies solving complex user problems with case studies from Snyk, Webflow, and Nextdoor. The modes are based on 2 criteria — the degree of commitment and the number of stakeholders required to adopt the product initially:

• The fast-working mode requires a low number of stakeholders and low commitment to start trying out a product — it shows ROI immediately and convinces the initial few stakeholders that the product deserves to be championed by more people. Snyk is an example of a product that has found success in this mode. 
• The habit-forming mode requires a low commitment to getting started, but the product requires a lot of stakeholders to have real value. Nextdoor is a great example of a habit-forming product since it replaces offline and email-based rituals within neighborhoods. 
• The paradigm-shifting mode requires a low number of stakeholders but the degree of commitment needed is really high — since initial stakeholders will need to spend a lot of time deploying the product, and it is often the only solution for the problem, it is a high commitment product. Webflow is an example of a paradigm-shifting product.

‍

‍

Over the course of this episode, we answer three critical questions on playing PLG in hard mode:

1. How do PLG companies with multiple user/buyer personas figure out who to build for first?
2. How do PLG companies incorporate feedback from design partners and early free users?
3. How do PLG companies go from early brute-force marketing to a scalable GTM motion? 

‍

‍

Episode transcript

‍

Sandhya Hegde:

Welcome to the Startup Field Guide, where we learn from successful founders of unicorn startups, how their companies found product-market fit. I'm your host, Sandhya Hegde, and today we dive into a masterclass on product-led growth or PLG. Specifically with stories and highlights from some of my favorite episodes based on Webflow, Snyk, and Nextdoor. Now, when typically I bring up PLG, most founders I talk to complain that the concepts of PLG that everyone discusses are fairly simple if the product is incredibly easy to implement and use and the end USER is also the BUYER of the software. So in this episode, we are really going to discuss what I think of as PLG on hard mode, where the payoff is incredible if you pull it off. You can build companies with huge moats and great competitive advantage, but the products are not easy to get started with. They require real implementation. or as my framework refers to it, high commitment or involve a large number of stakeholders. This is PLG on hard mode, and it's not really easy to think about how to craft a product experience and how to craft go-to-market strategies around it.

‍

So Webflow, Snyk and Nextdoor are three companies that solve extremely different types of problems that all have built PLG strategies in hard mode. So we are going to dig into that a little bit and really explore how these companies are able to be successful and particularly answer three questions. One, how did they figure out what exact persona to start building for? Because they all had multiple stakeholders in the beginning. Two, how did they incorporate the early adoption and userfeedback they were getting into building something that people were willing to spend money on and start monetizing? And then three, how did they actually scale their go-to market? Did they kind of tap into communities and influencers? And a lot of the really solid bottom-up, product-first marketing tactics that great PLG companies use. And last, but not least, we're also going to dig into the concept of community marketing a little bit because I think it plays a really crucial role in product-led growth concepts, but is fairly misunderstood. 

‍

Now, at the heart of this episode is going to be a framework that we introduce in the introduction to product-led growth in the Unusual Venture Startup Field Guide. Please look it up where I break down the three modes of PLG if you are approaching it from a complex point of view. And these three modes, as you see in this graphic, are based on the degree of commitment and the number of stakeholders needed to adopt the product initially and start getting value from it.

‍

So in the simplest situation, you have low number of stakeholders and low commitment needed to start trying out a product, and that's what I call the Fast-Working mode. Where you need to immediately show ROI out of the gate, convince the few stakeholders who are getting started that this is a product that deserves more commitment and deserves more time and deserves the kind of championing required for the product to be able to achieve a higher degree of stakeholders to get involved in this solution. So that's Fast-Working. 

‍

Then on the right is what I call Habit-Forming, which is pretty low commitment to get started, but the product doesn't really have value unless a lot of stakeholders are already involved in it. And a great example of a Fast-Working product we are going to dig into is Snyk, which immediately gives automated value out of the gate to developers who are interested in securing their software. A great example of a Habit-Forming product is Nextdoor, which replaces a lot of offline and email-based rituals in a neighborhood and creates a social network for a neighborhood to build their community around. 

‍

And then last but not the least, there's what I call Paradigm-Shifting mode. And this is where the number of stakeholders might be low, but the degree of commitment needed is really high. Which means that you have to spend a lot of time to deploy this product and you only really have one solution for the problem. So you can't explore four or five low-commitment solutions at the same time. You really have to pick one and stick with it, which makes it a high-commitment product. And that's what we call Paradigm-Shifting, because these products have to immediately unlock a lot of time and ROI for a specific executive to be adopted within a company.

‍

So these are the three hard mode PLG strategies and the three companies and the clips from the interviews I have done with the founders of these companies tell great stories of how they were able to tackle the problem in each of their industries. For the next few minutes, you're going to hear some clips from our original interview with the CEO of Snyk, Guy Podjarny, where he talks about how Snyk found product-market fit. However, some context on Snyk before we get started. So, Snyk is a cybersecurity company. It is valued at $8.5 billion, has over 2,000 customers, and probably has 2-to-3 million developers worldwide who have used it at some point. And even though here in this graphic I'm showing them as a fast-working PLG mode company, the reality is they were not that at all. Because they were a security company that wanted to focus on developers and developer adoption.

‍

However, security has always been traditionally purchased by the head of security or the CISO in a company. And the original vision of Guy Podjarny when he started Snyk was always to really challenge that and see if there is a way that they could really break that pattern. So they started with this really barebones product that was completely focused on automatically telling developers based on all the open-source packages that they're using and their software, what could be potential vulnerabilities in that software.

‍

That's it. That was their original solution that they went to market with, all the way up to getting maybe 4,000, 5,000 developers to sign up and try their product out. And even though it was a product-led company in terms of its vision, the original days of finding that right developer persona was brute force. They would go to meetups and conferences and every place that they could talk to open-source developers to see where to start and eventually picked kind of this Node.js, open-source community, this tiny, tiny niche, to really focus on.

‍

And in the clip that you'll hear next, you'll see how Guy Podjarny thought about that focus and serving a certain developer community with a lot of depth versus what they were sacrificing, which is the breadth of solutions that a CISO or a head of security would have wanted to be even vaguely interested in trying Snyk out as a solution. 

Guy Podjarny:

The focus very much was, how do we get developers to embrace the product? And we adopted role models that were from the developer world. We really wanted to look like the New Relics of the world, the GitHubs of the world, the Herokus of the world as opposed to the cyber companies of the world. And we had all these idioms. Be a builder, not a breaker. We adopted their go-to-market approaches, we did usability testing with the developers, and we pretty much ignored security people during that time. So much so that I remember a good year plus into the company, this advisor that I had a conversation with for marketing said, "If a security person comes to your site and they want to log in, do they have a way to log in?" And I was like, "That's a good question. No, they do not."

‍

And we fixed it. We added like a login with Google at the time, but up until then you had to have a GitHub account to register to the site. So very, very focused on this need. Developers embrace it. The other thing that we've done that I can phrase better now than I did back then, which is we went depth-first. So when you think about it, developers like depth, while security needs breadth. So for developers, if I'm a JavaScript developer, I couldn't care less if you support PHP or not. It's not a cynical comment, it's not a critical comment, it's just reality. It doesn't matter. I write in JavaScript and it doesn't matter if you support PHP or you don't. And if I write in JavaScript and I deploy with whatever it is, CircleCI on Lambda, on AWS, that's what I care about. And it better be amazing in it.

‍

And so the whole ecosystem builds for depth, builds for specific communities that thrive and love components. And you see Heroku and New Relic, they stayed in Ruby land for years before they expanded. That's the playbook. And so that's what we did. We adopted that. We picked node.js, which we felt was the Ruby of the time. It had enough adoption to care, but not so much adoption that you can't disrupt. It was sufficiently consistent in use cases. And so we went all in on Node.js. We successfully won over that community and nobody bought. And only then we learned to realize that security is already a fragmented space and has many, many different risks that need to be addressed. They're constantly moving. It's kind of a cat-and-mouse game. And so security needs security solutions that support some large... Like the lion share of their applications.

‍

They can't go off and multiply the number of risks with the number of applications or directors of engineering that they have in their companies. It's not feasible. And so security needs breadth to be able to actually buy a product. And we needed to later grow to provide that breadth to actually be something that is viable for them to purchase. But at the beginning, these blinders... Sometimes I get asked if that was... Like which mistakes I've made.

‍

And this was a mistake in the sense that it was ignorance, but it probably wasn't a mistake in terms of how we handled it. You have to pick what matters most. And what mattered most was demonstrating that if you build the right tools that actually tune themselves to developers and actually aim to delight developers, actually make it easy, make it fun to build secure software, that developers will actually embrace it. And so we were fully focused on that. And it's important to ensure that your investors are aligned on it. We needed that. It took us two years to get to a $100,000 ARR. That's not awesome. Generally not a great metric to sort of be in two years in and several millions of dollars down. But the investors were sort of aligned on it, and so that helped us persevere.

Sandhya Hegde:

Next we'll be hearing from the founder of Nextdoor, Sarah Leary. And some context on Nextdoor first. So the reason why I picked Nextdoor as a case study for this PLG Masterclass is because people assume that being product-led is trivially easy when it comes to consumer products, and Nextdoor is very much a consumer product. However, it's a very complex consumer product in terms of its go-to-market motion. Just think about it, right? Nextdoor, first of all, is a network-based, social-network-based company, which means it only works if most people in a neighborhood adopt Nextdoor together. And then it only works as multiple neighborhoods do that, which means some neighborhoods need to recommend this product to other neighborhoods. So there's a lot of parallels in terms of things that enterprise software that requires team collaboration struggles with and the challenges that a company like Nextdoor has to solve.

‍

Now, it doesn't stop there. At Nextdoor, the USER is not the BUYER, right? Nextdoor monetizes its marketplace, not by charging neighbors to subscribe to it, but by charging the small businesses in these neighborhoods to advertise and promote their services to the neighborhood. So again, the USER is not the BUYER, similar to what we saw in Snyk where the end USER is a developer, but the BUYER is the CISO. So how do you actually build a product-led mission and who do you start developing for? Who is the first person you talk to and understand their problem? How small do you go?

‍

So in the following clip, Sarah does a great job of laying that out and pointing out how small they started and what was the minimum viable product they built that gave them some sign that, yes, there is a clear pain here that an online social network can solve better than the existing solution that this community is using. 

Sarah Leary:

And it was very clear when we showed people the map, they lit up, they got it. They understood the whole thing. And so that proceeded for another month and a half. And then once we were starting to hear the same things again and again, we started to say, "Okay, we think we have something here. But again, we're just talking about it theoretically, let's build a very simple prototype." And I think one of the important things is that a lot of times as product builders, we want to build the whole thing. We're so excited about all the things that are possible. And I think one of the things that we got very right at this point is that we tried to reduce the prototype to isolate a variable and test the simple hypothesis. Which was: If we could get a group of neighbors together on a platform, would they have anything to talk about?

‍

And if the answer to that was no, nothing else mattered. It didn't matter if we could draw the neighborhood boundaries, that we could verify people's addresses, that we could figure out how you could invite more people to the platform, all the notifications, the mobile app, all those things that were going to be really a lot of work to build would not matter if it turned out that neighbors didn't have anything to talk about. And so we built the simplest prototype just to test that one question. Would our members have anything to talk about with their neighbors? We launched that in one neighborhood in Menlo Park, and God bless those people for allowing us to work with them and to test it in their community. We happened to launch... This is where we got a little lucky. We launched three weeks before Halloween, which is the most neighborly of all holidays.

‍

And sure enough, on the platform, we gave no limitations on what you could talk about. Very simple prototype. People asked for recommendations, they wanted to list an item for sale. Someone was looking for a tutor. Someone was looking for a piece of felt for a child's costume. Someone else was trying to organize a parade of all the kids in the neighborhood before they went trick-or-treating. And it was amazing. The dominant types of use cases that we later saw on Nextdoor over the course of 10 years revealed themselves in the first two weeks that people were using Nextdoor in this one community.

‍

And on the basis of that, we started to say, "We have something here. And let's start building it out." Now I have to be clear, I can look back and say, "Wow, the light bulb went on." We still weren't a 100% sure that we had found it. And so then we wanted to test it in multiple different locations around the country. Just to make sure that we weren't just finding something that would work in the Bay Area.

Sandhya Hegde:

Our third case study for this PLG masterclass is going to revolve around Webflow. And you'll soon hear from the CTO and Co-Founder of Webflow, Bryant Chou how Webflow thought about their initial minimum viable product and the initial customer persona that they really focused on while they were in the early days of development. Webflow is a very clear Paradigm-Shifting product in the sense that it requires a very high degree of commitment from the BUYER.

‍

There's only one tool you're going to use to manage your website. The core hosting CMS, the core design, that's going to be only one product. And the website is the face of your company. Everyone is going to see it. If it's not good, everyone is going to be pissed off — which means that you need to be solving a tremendous amount of pain for an executive to choose this high-commitment product as the solution, especially in the early days of the company when you are a startup with very little to show for yourself. So how did Webflow get started? What was the initial beachhead? Please hear Bryant in his own words.

Bryant Chou:

The market that we were going to enter was the professional website market. So not the website builder, cookie-cutter template like something my mom can use. But a professionally designed and professionally built website that typically requires a professional freelance web designer and a professional web developer to go and put together. And that's a big market actually. So that's essentially most of the WordPress market is the mid-market CMS was big at the time.

‍

A lot of these products were big at the time. And the use case that we were solving for was very specific. It was actually the use case of specifically a freelance web designer, which is someone that at the time we were brainstorming what this person would look like. This would be a freelance web designer making $40,000 a year working out of a coffee shop, building websites for businesses of all kinds, and really struggling with the fact that they have to fork over 50% of the entire project to a web developer so that they can implement those designs. So that use case grounded us for the first, let's say five or six years of the company where our entire go-to-market motion as well as our community building and most definitely our product roadmap was very centered around that particular persona. We gave that person a name, we had a poster of this person in our office, and that's how we rooted all of our priorities in the very beginning.

Sandhya Hegde:

Now here are the big lessons that I want you to take away from listening to those three clips. Let's start with Snyk. The big takeaway for Snyk is that the entire company's core innovation was about making security product-led. Because historically, the way cybersecurity was designed and sold was just impossible to be product-led. It was software that was sold to the head of security and eventually was pushed down the company to be implemented and used by developers. And the biggest problem in this whole system was always that there would be a huge lag in implementation and the software was never produced to be developer-friendly. So the whole point of Snyk when it started was to make cybersecurity software PLG. So they broke down this problem that had too many stakeholders, and needed too much commitment and really built out the MVP that would be single stakeholder, low commitment so that they could build a Fast-Working PLG strategy.

‍

Now that didn't last them forever, and what we'll hear in this next clip is the issue, which is that the security BUYERs had never heard of Snyk, even though they now have thousands of developers starting to use them. And the developers wouldn't necessarily start paying for Snyk themselves because it only solved a problem for them, and they didn't perceive this as something that they could own and start paying for. They didn't perceive it as something that they could own in the company.. They had solved one problem, which is they've had developers become aware of a security software, adopt it on their own.They had figured out step one. But they still needed to figure out step two, which is now how do you bring in this other stakeholder that does care about developer experience but does not live in the developer community. So now hear Guy talking about how they added a sales layer very, very early on to their product-led, bottom-up component, so that they could bring these stakeholders together in their complex customer journey.

Guy Podjarny:

So up until the year in, we were still kind of under that sort of optimistic approach of, "Hey look, it's awesome. We got to developers, the money will come." It was only that year in when we saw we are allowing people to pay now and yet they are not, that we found out about the problem. And we got more serious about talking to security people about what's holding them up. We would generally get positive feedback about it, but we uncovered two primary gaps. One around the breadth that I mentioned, the need to support more languages. And the other is specific capabilities that security teams need, that the BUYER needs, to be successful at rolling this out in the organization. Around reporting, around some USER administrations, and others. So I think the conviction of the developer-first approach was still very strong throughout. Because we from the beginning said, we will crash and burn before we pivot out of this dev approach.

‍

The conviction about whether we can successfully do that and also get the security people to pay was a bit lower. Climbing out of that was a step-by-step process. There's no single point. Every time you work through the process... I found that there's sort of three types of features you can build in the product when you're talking about selling it. There are the features you need to get into a POC, there are the features you need to get through a POC successfully. And then there are the features that you need to make a customer successful post acquisitions. And there is overlap between them, but they're not the same. And so we went through that process. At the beginning, we lacked the first type and we had to get into POC. Just check the right boxes. Subsequently, we had to demonstrate true success. And then once we have acquired customers, we built those out.

‍

We got the first cloud-native company to buy the product, I think it was in March of 2017. So this would be a year and a half after launch, give or take. We had a few a $100, $200 a month type companies before, but this was like a $30,000, $40,000 deal. We got another one in May. We got a bigger one in August. And really that was the tipping point. So that was an acquisition. A cloud-native company that was acquired by a larger company that purchased it. Actually the one in May was also of a similar profile, and that was about two years in, we were at a 100,000 ARR. And from there on something clicked. So that was in hindsight, very much the sort of product-market fit point in terms of commercialization.

Sandhya Hegde:

A really, really important thing that Sarah Leary, the founder of Nextdoor talks about in this upcoming clip is how to roll out a new neighborhood. And one of the most important things about a new neighborhood that Nextdoor discovered was when they were rolling out a new neighborhood, it had to be championed by the right people. It had to be championed by the people in that particular neighborhood who were very active in their community. If they didn't get involved, that neighborhood would never take off.

‍

And so there are two big lessons here. One, the degree of brute force, non-scalable work needed to actually go from zero to one, no matter what field you are in, no matter what kind of software problem you're solving... Now, this is something that every founder should take to heart. Number two, this idea actually translates really well to collaboration-based enterprise software, that it's not just important to attract a USER from a company, but which USER you attract. Is this USER someone who is an evangelist of software within their company? Is this someone who has a lot of social influence that is followed by other people, is actually incredibly important. And the early days of your evolution as a company, you need to be able to identify these evangelists and actually reach out to them and brute force your way into building awareness with the right people because otherwise your product will never take off in those micro communities. So I think that, for me, is the really important lesson here from Nextdoor. 

Sarah Leary:

In the beginning it was very hands-on. It was us being directly involved in recruiting those founding members and then listening to what were the tools that they needed to be successful. One of the things that we did, for example, in the beginning, is that I would regularly be on the phone with someone in those first 25 neighborhoods, be like, okay, you need to grow the size of the neighborhood. Just two or three people. There's not enough people for a conversation. And that was great. We'd help them get to 10, 15, 20 and we would learn they need to have flyers. Maybe we need postcards, they need email. They needed tools to be able to get the word out. But obviously as you start to scale, I can't be on the phone with everyone. And instead, we built something that we referred to as the pilot program. Where the first founding member would come in and they had 21 days to recruit nine other people to join.

‍

And that founding member gave the neighborhood a name and drew the neighborhood boundary. And you can imagine not everyone could do that. And therefore they weren't a good founding member for us. If they couldn't grow the neighborhood to a certain size, that also was another sign. Now we would give them an extension, a little bit more time if they were getting close and try and help them get over it. But we had to build all of those pieces of the platform such that it was a scalable way to not only find the founding member, but also to get those initial seeds of the community right from the beginning.

‍

And so it absolutely became more digital, but we have always had an element of the, in the real world versus the online world, because I think that's part of the magic of Nextdoor, and it's part of what makes these communities special is that when you walk outside your front door, you're going to run into the folks in your neighborhood. And so you want to be able to take advantage of that. So encouraging people to host in-person events, going to in-person events, and telling them about Nextdoor. Because it turns out that if people are talking online, they're more likely to show up to the local events. And then when they go to the local events, they're more likely to continue the conversation in between events on Nextdoor.

Sandhya Hegde:

So at this point, I want to go off on a bit of a tangent on how to listen to your early customers. And Webflow is a great example of this. If you look at their early customers, they were a lot of freelance designers who were really, really happy to have this product and were starting to use it. Most of them are still not paying for it in the early days because the product was very barebones and Webflow knew this. However, they had massive backlogs of customer requests for more functionality that would allow them to stop paying for other software that they were using and channel their wallet share to Webflow.

‍

And Webflow was very, very smart about really listening to the feedback in the sense that they didn't just ship features that people asked for. They thought about the reason behind the ask and carefully selected what it is that they would listen to and ship immediately, versus what it is that they would listen to and analyze, to ship something that solved the underlying problem, but in a way that allowed Webflow to start monetizing their product, moving upmarket into enterprise and so on.

‍

So please hear Bryant explain in his own words how they thought about accepting customer feedback and turning that into product strategy.

Bryant Chou:

The only feedback in the first two years of the company was, "We want more. We want more functionality. We want more support for widgets and elements. We want maps, we want social widgets, we want light boxes, carousels." And essentially the first year, two years, was a sprint. We designed and built features in days. We shipped them sometimes in hours. Like everything from some hosting feature to handle 404 redirects or some new widget that a customer asked for or forms.

‍

Now, these things were like lightning fast delivery because at the time, shipping product was our only way to grow. We didn't have money to spend on marketing. So we viewed our product development velocity as the best option for organic growth. And I think that's true for a lot of early-stage companies out there looking for product-market fit. But in particular, Webflow needed to essentially unlock more of these capabilities. Because it just unlocked more and more visual use cases for Webflow.

‍

And by that I mean, it just gave people that didn't have that ability to code this custom light box, the ability to now create a light box. So that was a constant sprint. And it was fun because we were just shipping product nonstop. The one thing that was also a surprise... Not really a surprise, but one thing that we heard all the time was everyone was asking for a WordPress integration. And they wanted dynamic content, they wanted a blog. And at the time, Webflow didn't have a CMS. So this is an instance where we deliberately ignored our customers. We ignored the feedback. We're like, "Yeah, we could go and integrate with the WordPress CMS, but we actually have ambitions for something even greater." So this is an instance where, Karen Peacock at Intercom has talked about this, where customer feedback is almost superficial. You have to really engage and understand exactly what the customer needs and really go down to their root pain points before you go into action. Because there are millions of data points for customer feedback.

‍

Just like, "I want this, I want that." But it's often that if you really spend the time learning about your customer, you'll actually extract these themes. And these themes will lead you to create innovative products. So to go back to this WordPress integration example, the theme that we saw in all this feedback about customers asking for a WordPress plugin is that they wanted to render dynamic content on a Webflow page.. And we could have gone out and built it, but what we did was we really tried to understand A, what does the overall market look like for this CMS? What is Webflow's right to win in the overall CMS market? And what we did was we took bold steps forward and we created essentially the world's first visual CMS back in 2015. And this was a CMS that was completely revolutionary at the time.

‍

You had the ability to create custom fields, describe relationships to data. But then most importantly, you had the ability to bind dynamic content to the UI on your Webflow site. None of this existed at the time and we're still the market leaders in that space. So effectively we took that piece of customer feedback and we saw how loud it was and how fervent it was, and we've essentially birthed an entirely new CMS category out of it. Which is the visual CMS category that now Webflow owns. So that was a really interesting takeaway, just seeing all that customer sentiment and feedback pop up over the years.

Sandhya Hegde:

So let's stick with Webflow as we answer our third question. It's just how do you scale go to market? And here Bryant explains very eloquently how in the first five-to-six years they had very, very little funding and they were very constrained by the amount of revenue they had, in terms of what they could experiment with and where they could really invest in growth. And so their priority was always organic growth. What would drive organic growth? What would make it effective? And he walks through some of the really cool experiments they ran and took an extremely product-first approach to marketing.

‍

And I think this is really important, broad kind of point to understand about product-led growth is when you're building a product-led company, your marketing has to be product-led, your sales has to be product-led. It's not just about the product, it's about every aspect of the company. And how Bryant describes how he was not just the CTO, but effectively, the head of marketing and growth and thought about how to put the product in front of more of the audience. Whether that's through influencer marketing or really simple games that end USERs could interact with that would help them understand the power of the product. Very, very powerful ideas that I encourage everybody to really learn from and try in their own companies.

Bryant Chou:

So essentially for six years of the company, we were just growing the company off of revenue. So what that meant was when I was the head of growth at the time, it was all about being extremely scrappy with where to find that top of funnel. Where to find the retention and where to optimize monetization. So the natural decision for us at the time when I started to focus on growth was, hey, we know at a certain point organic is going to trail off. No companies just grow completely off of organic unless you're like a pure B2C product, something like a Notion or something like that, with a massive TAM. So that's when I started to think about growth engineering. So specifically what are some of the products that we can release that can help with top-of-funnel and awareness? That's when we started to think about how marketing could be an extension of product.

‍

So, we created things like flexboxgame.com which was essentially a game of Froggy, but it was implemented in the Webflow designer that people used and you have to use Webflow Flexbox in order to progress through the game. So we had to just be extremely creative. We had to think about how to use organics and virality to help drive the company. And that's also when we also started to experiment with performance marketing as well. Content marketing, affiliates, influencers. So fun fact: There is an influencer out there and he's responsible for probably tens of thousands of Webflow customers. And not only that, he's probably also responsible for really help solidifying Webflow's brand in the design world, as well.

‍

So all of these things were started as experiments. And essentially when I was running growth at the time, I would think of it as an engineering pod. I would think of it as, all right, what is the impact, confidence, and effort out of all this backlog of growth ideas? We'd meet weekly, we'd score them. We'd throw new ideas on there and we would just find really scrappy ways of working through that backlog. And some of them hit, some of them didn't. But for the ones that hit, they became extremely impactful.

Sandhya Hegde:

Another question that I often get when it comes to product strategy is around how to leverage communities. And I think this clip from Sarah where she talks more broadly, not just about Nextdoor, but about working with communities in general I think is really, really well articulated. And the TL;DR here is that you cannot force communities to happen. And community can't be something that you just kind of call the Slack channel where you have a 1,000 disengaged people lurking. A community assumes that these people would have wanted to do the activities they're doing, even if you as a company did not exist. And your role is that of a facilitator who brings them together and gives them resources as opposed to, the only source of communication in the community. 

Sarah Leary:

I think that the most successful communities have been ones who have tapped into a group of people for whom it's part of their identity. I'm a data scientist. That is part of who I am. And I'm looking for other data scientists to share best practices and how do I get myself out of a jam because I've found a problem and I don't have anyone else in my workplace that has expertise to reach out to the community. And so if it's not a group that identifies as a part of that, that's a problem. You look at what Salesforce did with Dreamforce, and they created a sense of identity. If you are someone who knows how to operate Salesforce and you're an administrator, they created that sense of community. So kudos to them. That was extraordinary. They spent a lot of time and a lot of money to make that happen.

‍

And I think most of the time they're not really even talking about Salesforce software, but they created this thing that people wanted to be a part of and they wanted to show up to on a regular basis. Both in person and online. And that's special when you do that. And I think some of the best brands out there have that really strong sense of identity, that then you can build community around. But it has to have a real sense of togetherness, people wanting to come together. There has to be real content, and this is really important. It cannot just be the company communicating with the customers or the members of the community. The community has to start communicating with each other to the point where the company could step away and the community is still going. That's a real community. And it's not something that you can just build in a month or a quarter and then walk away from it.

‍

You have to cultivate it time and time again over years. And you have to keep cultivating it. And that's something that I think fewer companies actually want to make that investment. And typically it's helpful that you have, hopefully a team, but at least a person who is the internal voice of that community at every turn. It's nice if it's one of the founders, but it can also be an early employee that really carries the torch for the community inside of the company. Can champion resources and information and communication on a regular basis such that the community is almost like an extension of the company.

Sandhya Hegde:

Last but not least, we are going to talk about how to scale your organization around a product-led growth strategy. And I think this last clip from Snyk where Guy talks about how they grew their team is just as important as when he talked about how they grew their business. And really the heart of it comes down to this. In a true product-led growth mission, the whole company is focused on growth.

‍

There isn't one team that is standalone, that is titled, The Growth Team. In a true product-led company, every function is product-led. So there's obviously the PD team, but there's also a very product-led marketing org, a very product-led sales org. Everyone is organized around the main kind of growth strategy in the company. And in the case of Snyk, that was always developer adoption. It was enterprise and kind of the security BUYER experience that they actually layered on, on top of the company as a standalone team that would focus on monetization and focus on the enterprise experience, as opposed to the other way around. So let Guy share in his own words what that strategy was, why they did it, how long did it last, and eventually when they did bring on a dedicated growth leader, how did they think about that?

Guy Podjarny:

At the beginning, the company was all oriented indeed around growth. And so there was no need for a separate function. There was some competencies and they ended up being built into the product. Things like viral discovery through open-source projects using Snyk and GitHub. There were sort of core tenets of how the product worked, and we continued to do those. As we grew, two primary things happened. One, as revenue grew, the backlog would get filled with a lot of requirements. Some dev-oriented and some security-oriented, but just a very, very long list of customer-oriented. And it became very hard to, within that backlog, prioritize the needs of an online free USER, developer, as compared to an enterprise USER. And that became a recurring thing. And so we had all these great things that we wanted to do that everybody was aligned on one thing to do and they would just not get done because they never managed to bubble up to the top.

‍

The second thing that has happened was discrepancy between the products. And so because we had the different products and the products were fairly independent. They started building all sorts of shared componentry that wasn't shared. They would repeat to them and they might not have... Some of them were more different. The container product was built originally actually as a premium product and only later we added freemium. And we saw that we're going to need a bunch of these types of componentry. And I think by the time we properly built the growth team, we even had infrastructure as code already well underway as a product in the works. And so that was the other driver, which was not just the growth, but the experience for the developer. And thinking about that developer experience platform across products. And so both of those drove us probably in order, was a lot of it was on the dedication.

‍

And then the last thing that really drove it is an anticipation of potential. And so we really saw, Snyk lives between developer and security. And we feel like there's still as broad of a reach as we have today, when we look at the developer tools that we most admire, we feel like there's still substantial upside in terms of how many developers that we can reach. And so there was a lot of agreement that there's just so much potential here, but we need dedicated leadership, we need dedicated focus and people that are not distracted by the commercials.

‍

They care about those, they care about the business, but their primary focus is very sharply, "How do we get more of those developers on the platform?" And so it took a while to find Ben. That was another gap there, because hard to find those type of people and that type of talent. But eventually we did that and we established that group. And around the same time, we similarly established a group on the marketing side that was also focused more on the online free USER and that sort of self-serve funnel and things like that. Although we weren't doing self-serve yet at the time.

Sandhya Hegde:

So hopefully you enjoyed that PLG Masterclass as much as I enjoyed putting it together. And I think if you take away one lesson from all this, it's that you can build great product-led companies around complex products with multiple stakeholders or a high degree of commitment needed. It's difficult if both are true for basic adoption.

‍

However, you need to be extremely mindful and intentional about your strategy as you go about this. And most importantly, you need to decide and articulate exactly what is that strategy. Are you going to become a habit? Are you going to change an executive's ROI and buying experience by an order of magnitude? Or do you have a product that can automatically deliver value out of the gate and be fast working for one end USER to get quick adoption, and get the credibility needed to bring other stakeholders in. So you have to be really intentional. And if you don't have that clear strategy, just being a product-led company with a self-serve experience is not going to get you very far. Hopefully this was very instructional. Thank you so much for joining us. Until next time.

‍