The below is a full (unedited), machine-generated transcript of a Youtube session / podcasting episode I recorded with Vivek Saraswat in Q4 2020. You can view the video/listen to the podcast on Youtube, Apple Podcast, Stitcher or wherever you get your podcasts.
Erasmus Elsner 0:06
Welcome, everybody to another episode of Sand Hill Road. I’m super excited to have with me, my guest today be Vivek Saraswat, who is a venture partner at Mayfield, one of the most venerable Silicon Valley venture firms. Vivek, are you ready to take us to the top?
Vivek Saraswat 0:23
Yeah, thank you Erasmus, really happy to be here.
Erasmus Elsner 0:26
We actually planned for this episode a while ago, pre-COVID in another time, and I’m really excited that we can finally make this happen. I want to hit it off talking about your background, you started out on the engineering side, then moved over to product, working with companies such as AWS, VMware, and Docker. And then in 2018, you joined Mayfield to invest in enterprise software, the primary focus on next generation infrastructure and product development tooling, why don’t you walk us through these different phases in your life.
Vivek Saraswat 0:56
You know, one of the sort of guiding mantras of my career has been, I really like helping other people build the things that other people use to build even bigger things. And that’s really what has driven a lot of what I do started my career in engineering, you know, actually started as a material science engineer, building both hardware and code, you know, working at a big companies and startups, but really creating the fundamental building blocks of society, in general in terms of solar power, and energy and semiconductor chips. And then I made that transition over to the wonderful world of software in enterprise products. And for me, it’s the digital building blocks that people use to go and create applications that really appeal to me strongly. I started my products, my career at AWS, working on elastic block store snapshots. And Amazon taught me the value of customer centricity being laser focused on the customer is this looking backwards framework where you see the Envision of what you want to build, at scale, work backwards to what the MVP looks like. And then you actually write a press release a fake press release, that shows the value proposition to that particular customer. So that was a really strong thing for me. And it’s also a company that teaches you how to ship quickly, which I think is important in products. Like you mentioned, I went to VMware on the product side where I was working on storage features for hyper converged storage, like v San and vSphere. And really quickly saw that the world of cloud native was going to change absolutely everything I helped form VMware, cloud native storage applications move on the product side, building open source integrations for things like containers, and OpenStack. And VMware really taught me about enterprise process and priorities. And you know how to ship within a complex interlocking application stack. Then at Docker, I launched and ran multiple iterations of the primary enterprise product based on orchestration and integrations and security and analytics and other areas. And really, what I learned from Docker was how to build this bottoms up adoption on top of a community of really, really passionate community developers and create enterprise for open core product on top of that, so really getting bottoms up and product like go to market, right. And honestly, just being at a hyper scaling startup, you just you learn a lot of things, you learn how to adapt and shift quickly. So ultimately, really amazing and fundamental experiences in engineering and product before I made my way to VC.
Erasmus Elsner 3:12
Now let’s talk a little bit about your current role. Mayfield early this yearraised its 16th flagship fund already, which was a $475 million early stage Seed and Series A fund along with a later stage Select fund. Talk to us a little bit about Mayfield and your role at Mayfield.
Vivek Saraswat 3:30
Yeah, so I’m a venture partner at Mayfield, helping invest in enterprise infrastructure and product development tooling companies primarily based on you know, my background, and also working really closely with a lot of our portfolio companies on product strategy and go to market particularly around enterprise side, open source commercialization and bottoms up adoption. And you know, why I chose Mayfield in the first place, I mentioned sort of my desire to help other people build things. Product Management done right is really about how you help other people in the company, build, get the product, out the door, build the product, market and sell sell the product. To me venture and particularly at early stage, john Wright is the same thing for companies. It’s helping other people really build companies. And yeah, I had build relationships with several VCs during my time in product, helping with things like due diligence and perspectives on cloud native. When it came time to transition, I just really loved Mayfield’s approach and culture. It’s all former operators and founders, you know, people help build companies before and we make a few targeted, deep investments. We work closely with founders on every part of company building, product strategy, go to market hiring Ops, you know, whatever the founders want help with. And and so it’s that mentality and, you know, service oriented methodology which really appealed to me and also just the history of investing in enterprise infrastructure, companies like hasha Corp branch or influx etc. So, really excited to be there and you know, to get them in leadership of folks like navy and shadow managing partner of the firm. So it’s been a it’s been awesome. Last two and a half years now actually, it’s been great.
Erasmus Elsner 5:06
On the website, it says that you’ve been involved in companies such as Dev.to, goLinks and Alchemy, maybe talk about one or two examples of where you really got back into the trenches helping founders build and scale.
Vivek Saraswat 5:19
Yeah, absolutely. I’ll talk about Dev.to and so for those who don’t know, Dev.to is a community, the fastest growing online community for developers in particular, it has a belief that if you call yourself a developer, it doesn’t matter what your background is, what degrees you have, or what you’re working on. If you’re somebody who builds applications, that builds code. Dev.to is resonating very heavily with the community, they have 5 million users and growing very fast. But debt to is in the midst of a really exciting and revolutionary transformation, they released a open source project called forum fo REM, which is open source tooling for building and managing communities. So whether you’re an individual creator, or you’re an enterprise, you know, managing community, this the tooling that they provide for that, and it’s a very exciting area, there’s kind of a gap right now, there’s people who manage communities on Slack. You know, there’s people who use old school web based interfaces, but there’s really this big gap in the market for managing communities. And I have been working pretty closely with that team on, you know, how to go about creating and releasing project and how to commercialize it with since given my background at the places I’ve worked at. So that’s been something that’s really been in the trenches. And you know, that the founders are amazing. Ben, Ben, Justin, Peter, our trio of highly energetic founders, were really in tune with our community and users, which is just so important. When you’re doing a bottoms up adoption model, you need to be true to the community, true to your values, and a lot of working with them on on, you know how to go about building it to the next stage. So So that’s been a great time. And, and I’m really happy with the way things are going there.
Erasmus Elsner 6:56
Yes, I remember I set up my Dev.to profile, I think one and a half years ago, when Joseph Jacks was on the show, and he was a pre seed investor in that company. I would be remissed to ask. We’re now almost one year into the Corona and COVID-19 area, there have obviously been a number of companies that have been hit quite hard. And there’s really this divide to spectrum COVID-19 tailwind COVID-19 headwinds, if we look at the open source side of things, is a long standing member of the open source community. How have you experienced this year? And what was it like for the community at large?
Vivek Saraswat 7:34
Yeah, that’s a great question. You know, COVID-19 has been a terrible tragedy, right on a personal and business level. For a lot of folks, the infrastructure world as a whole has done pretty well. As you said, I’m reminded of Satya Nadella his quote earlier this year that they’ve seen two years of digital transformation in two months, right. And it’s because in this world where people are more work from home, there’s more remote in distributed offices, there is a huge movement from on prem to the cloud, and enterprise infrastructure powers, everything we do with the video streaming services we use, I have too many of those. Now, e commerce services, SaaS applications. So overall infrastructure as a whole has done very well this year. And open source has done really well as a part of that too. And I think it’s because it’s a really good time. Right now for bottoms up users like developers to test out software people have more time and are more flexible with their doing. And particularly if it’s free, you know, a model where you can test and use something that’s free like open source is and where you can go and build a community that by itself is online and distributed by nature, that has really helped open source to take off even further. And businesses have been able to use an inside sales based approach was to top down field sales, which coupled with commercial SaaS as a lot of open core models do that’s worked really efficiently and effectively during COVID-19. So open source is doing well prime, you know, from this community led adoption model and infrastructure is doing well. The sales process and go to market process, which is typically used in open commercial open source just fits really well in the current environment. You know, it also helps that several companies have just demonstrated success of commercial open source at scale. Public companies like Elastic, Twilio, and now JFrog most recently and large private companies like HashiCorp in our portfolio and compliment outside. And, you know, fundraising has been pretty hectic in this space as well. You’ve seen some pretty large rounds, like cost to run the graph, qL space or postman and dev tools. And there’s also been a ton of smaller ones, many of which hadn’t really been announced yet. So it’s not a great time in general in the world, but it’s not a bad time to be a founder in the world of open source today.
Erasmus Elsner 9:38
That whole movement I think has been in many ways accelerated the open source community has benefited from being remote only remember having sets of ranji from the Git lab on who was really pioneered this remote only company model for for a couple of years prior to the crisis.
Vivek Saraswat 9:56
You know, on that note, I think there’s there’s two companies that I think of Gitlab and Hashi are both really figured out distributed team building and Deb Dotto is actually doing the same thing. But those two companies really showed that it could be done. And it fits very well with the open source ethos as well. So that’s been one of the more interesting things to see in the past couple years.
Erasmus Elsner 10:17
But let me maybe dive now a little bit into something that you already alluded to, which is this community led go to market in open source. And I want to start here really, from first principles, because a lot of the listeners out there might not be familiar with with go to market in the first place. And I’m going to blend in some of the slides of one of your recent talks. Let’s start at the basics. What is go to market?
Vivek Saraswat 10:40
Yeah, yeah, go to market is a very favorite topic of mine. As mentioned, I talked about it at the open core summit pretty recently. In particular, in relation to bottoms up, which we’ll get into, to me, I mean, there’s some complicated definitions of go to market out there. Honestly, my TLDR is it’s it’s three things, it’s getting customers to understand the product and the value proposition, which is typically done in marketing, it’s getting customers to actually use the product, which is a form of distribution. And then it’s getting customers to pay for the product, which is sales. And if you’re doing a product lead approach, it’s part of the product as well. That to me is the sort of simple definition of what go to market really is. And you know, when I think of the models that are typically done, there’s there’s three sort of strategies that are well known. There’s the traditional top down strategy, where you know, insertion, and sales of the product is done to executives in the organization, VPS, and C level, folks, and then the youth to just push down from those executives, to managers and tours icees within the organization. And importantly, the upsell for the product and is done at the executive level. And these are typically six figure deals, often done using a field sales model. Then on the other side, there’s bottoms up, which I’ve talked about at length, and this is where your insertion and usage of the product is done among individual users. So in open source is very commonly developers or data scientists, for example. And then upsell is done up the chain to managers in the organization, whether in the same org, like you know, Director of Engineering, or whether in a different work like it, and then eventually up into executives. And this is often done first with a self serve layer than an inside sales layer, and then maybe at scale with a top down layer. And then the third GTM strategy commonly considered is middle out, which is sort of in between the two, it’s where your insertion is done at the managerial level and middle management level directors and managers. And usage is typically among those managers, and then I see is below them. And then upsell can be done at that level or at the executive level. So those are the sort of the three basic GTM strategies. You know why this actually matters that I think is important to talk about, because I think a lot of folks, if you look at a lot of b2b startups, folks build the product first, then figure out how to sell it. And then if that sales process and marketing process doesn’t match what was built in the first place, then they have to iterate, pivot or or start over in many ways. If you look at the smartest startups out there, what they do is understand their target market users and buyers very effectively, and choose the best fit GTM for that market, then they build the product to match the go to market strategy, then they market and sell the product using the go to market strategy. It’s the sort of Measure twice cut once phenomenon. And it’s something that’s I think the best companies have used. I remember David Jana gave a talk, because he’s a CEO of hashey Corp, where he said, the number one thing he’d want founders to consider is deeply considering go to market as a part of the product building process. And it’s something they’ve used effectively something a lot of bottoms of companies and top down companies have used effectively. So you know, that to me is the kind of the basics of go to market and why go to market actually matters.
Erasmus Elsner 13:51
I think it’s quite an interesting and novel perspective that we haven’t discussed on this podcast at length. It reminds me of Peter Levine from Andreessen Horowitz talking about open source as a developer driven sales funnel. And having this go to market perspective on open source is a perspective that some of the pure engineers might not have. From a product manager perspective, it seems to me quite challenging. If you’re doing bottoms up, you always have to manage these two product roadmaps. On the one hand, you have the commercial product, which might be a SaaS layer, it might be a services layer. And on the other hand, you have the open source product roadmap, how do you think about that?
Vivek Saraswat 14:30
Yeah, it’s honestly, it’s very tough. It takes a lot of work. It takes a lot of thinking. And I think there’s sort of two points that I would make for how you think through it. I think it’s important to know what the dividing line is going to be between community and commercial as you build out a long term vision. And this is important for product managers. It’s important for founders, even if you haven’t built your enterprise or commercial product yet, you got to know where that dividing line is going to be in what what you plan to go into what and be transparent about it with your users. I think users should know that you’re building commercial Just know that this is where that line is going to be. So there’s two sort of tactics I think about when you’re putting when you’re thinking about product and how to do this, right. The first is like not putting a firewall between your committee and commercial teams, you need to have one team that’s really making the decision about open source and commercial features. We’re freemium and commercial, free and commercial features when you have those two roadmaps. This ensures that those roadmaps don’t really stray off course, the other reason it’s really important is you want to make sure the people who are developing and building the product, have empathy for both users and buyers, and users on both sides of the company and commercial side of the fence. For me, empathy is the single most important skill or trait that a product person can have and should have, you really need to deeply put yourself in the shoes of the people who are using and buying your product and what really matters to them. And doing so requires that the team that’s making those decisions, understands both sides of the fence very, very deeply and is talking to both kinds of users. So that’s the number one piece of advice that I give teams have one team that’s making those decisions, you know, maybe segment your team vertically by use case not horizontally by tech stack or by licensing, like for your for your pain. The other point that I often think about is you can’t just bolt on a commercial team on top of a community team. This is what does happen at a lot of startups, they start with a team that’s built an open source product, let’s build a strong community. And then as it gets popular, build a company go and sort of bolt on, you know, this enterprise card carrying team on top of that, but that leads to a lot of problems, it leads to culture wars, you know, you have two different very different cultures that need to intermix it leads to lack of product fit, or the similar problem we talked about with a firewall. Now, you know, you’re trying to take two teams with sort of different thinking and different aspects. And we’re going to waste a lot of time arguing about decision making envision, what you need to do is early on, you need to understand that communion commercial will coexist. You need to have people who are spending time with both sides of the fence together and then grow that team organically with knowledge of both sides. It’s not easy. It’s much it’s much easier said than done. But this is how the successful companies have done it.
Erasmus Elsner 17:10
Yeah, that makes a lot of sense. And I remember that, that Martin Mickos. I think he is Finnish, he was one of the early CEOs of MySQL. And he collected this memory that in the beginning, they had a lot of customers calling them up and asking them to basically spend five days at their offices to figure out what’s the perfect database structure that would work for them. And they would actually turn them away, because they said, “Well, we want to be a self-service operation, we want to be a self-service product, a open source company”
Excerpt Martin Mickos 17:39
We focus so much on removing friction, making sure there was no friction in selling and no friction in buying, and then refusing to do certain things like customers would come to us and say, Oh, we are interested in your database, could you come in and spend five days with us figuring out what database we need? And we said, No, we won’t. Because that would have cost us too much. Given the low low price we charged.
Vivek Saraswat 18:07
It’s a great example, because it shows that you really need to be dedicated to the type of go to market that you’re going after. And that go to market does evolve over time. So the way I think about the user buyer pipeline, let’s start with how it applies to open source. And that that’s kind of the best example here is, you know, you typically have an individual developer, who is their primary concern is they’re looking to solve a problem, they’re looking to solve a problem. And the greater the experience in quickly, efficiently and effectively solving that problem, the better. So developer, you know, downloads typically some open source or if it’s not open source, it might be like, like an API like stripe or something that solves a problem that an immediate problem that they have, usually, and this is the important point through the example you made. Usually you’re not going to get any revenue out of this. And you should it’s focused on really building a strong community, you may be in some cases might get a self serve use case where you might get 1k, or something like that equivalent, with developer swiping their credit card, that’s possible. But usually that’s not the case. This is really about building that groundswell of adoption, then sort of the next step of that pipeline is, as you mentioned, sort of the managerial level engineering manager or DevOps manager. And these folks have different concerns. They’re looking for something that’s supported. often they’re thinking about things like team efficiency, how do I make my team better at what I do. And then this is often where a SaaS product makes a lot of sense. And if you look at a lot of the open source companies now, there are a lot of them are doing SaaS open core models. And that’s because it makes the adoption easier for this level of customer. And this is often an inside sales process. Typically, you know, five figure deals are certainly possible and doable here. And then maybe as you get to a larger scale, you get more and more adoption, whether it’s free committee adoption or paid adoption within organizations. This is when you start looking at the C suite. And these folks have even different concerns. Right. It’s about building a central service across your organisation. It’s about Capex and Opex reduction. And this can often be six figure deals, and maybe still an inside sales, maybe this is where you start layering on Field Sales. But a really, really good product person and or founder in the bottom of space has to understand the concerns of each of these different groups. And that’s the think way back when, you know, when building community product, where do I want to leave for each of these folks, right? What do I want to put in for each of these folks. And you may not get there for a while, you may not even get to Field Sales, a lot of companies don’t even get to direct sales until post IPO. But you need to be thinking about each of the process each of the personas and how that affects the product build throughout the way,
Erasmus Elsner 20:42
This brings me to the next point on how to create this vendor lock-in that you refer to in a recent slide set of yours, there was also the point of hooks and upsells. Maybe let’s talk a little bit about that.
Vivek Saraswat 20:54
The way I think about it is it’s less about a technological lock-in and and more about getting people to love your product so much and make it such a key part of their workflow. And I’ll talk about that, that the buyer can’t afford not to pay for it. And so the framework that I discussed with this is the hooks in upsell framework, and it’s really about building that flywheel of adoption, usage and monetization. And to me, I think about it in sort of two distinct pieces. One is first focus on really growing user adoption, really focused on user adoption, and not really on on monetization. And that doesn’t mean you’re not thinking about what happens when you monetize, you have to be thinking about where that dividing line is going to be. But you’re really focusing on building that foundational community base. And to me, this is really done through three things it’s done through solving a clear burning pain point. And you know, what I mean by that is really making your product critical path. And this this in some ways it goes back to Lochner talking about it is making your product either solving a key frequent painful workflow, or creating some sort of fundamental utility within the customer’s architecture that that’s so important to the user on it on a regular basis, that when it gets time for the buyer to buy, that they can’t afford not to pay for, it’s not important. And I think one of the key points here is that it doesn’t necessarily mean solving a technically complex recruiting a technically complex solution, it just means you need to solve a burning pain point that the user really cares about. And then, you know, targeting a massive user base, whether it’s developers, whether it’s DevOps folks, whether it’s data scientists, that you can really grow and build that adoption. And then finally, using a lightweight viral insertion mechanism, open sources part of this. And the reason for that sort of lightweight assertion is that you need a frictionless experience, as we talked about earlier, your developers looking to solve a problem, and they will pick the most convenient way to solve that problem. And so you need to make sure that you’re doing everything you can to make the process of insertion lightweight, to build organic virality through either a long term sandbox or these collaborative experiences, and continue to build up community champions, targeting known influencers doing sort of a train the trainer model with the with the folks who are most passionate your community. Once you’ve gone and built up that strong user adoption with these hooks, that’s when you can start thinking about monetizing by an upsell. And to me, again, this is sort of three part it’s understanding what buyers really care about, as we discussed in that previous slide, you know, what a DevOps manager VPN for cares about is may or be substantially different than what a developer cares about. So you need to have empathy for the buyer. And it’s getting out of sort of table stakes, enterprise features, support, single sign on access control, everybody has them, but you’re not going to win deals just because of them. And getting into what drives real buyer value, you know, peace of mind collaboration, analytics and insights. And it’s different for every business. Once you sort of understand buyers, I think you mentioned that my sequel had you know, folks coming to them, this is part of it, how do you influence buyers to come to you. And that’s really a combination of product. There’s the things you can do with the product to make inbound upsell happen. It’s also marketing and this is why go to market matters. You need to market to buyers in the channels that they understand so that they can come to you and do an inside sales. I don’t believe really that those sort of if you build it, they will come mentality will always work. You need to you need to supplement that with with judicious use in targeted marketing and weld on sales. And then the last piece is just making the product easy to buy. This is making the upsell as easy as humanly possible reducing friction in the in the way that the sale is done. Making the product the paid product similar basically the paid product as a commercial version, the free product, it’s similar enough that you don’t need buyer reeducation for what you’re doing. And then using an inside sales based process when you can or seltzer process when you can. So that to me is what works and bottoms up. That’s the sort of hooks are not so and there’s different pieces to do each bit. There’s different examples that you can use, depending on the company.
Erasmus Elsner 24:52
Drawing the optimal lines between the free version and the commercial. If you don’t find the right balance once you upsell You will upset some people in the community, maybe talk about finding these optimal lines between free and commercial and how you think about this in this hooksand upsell model.
Vivek Saraswat 25:12
Yeah, I think I can’t emphasize how important it is to be really in tune with their community, what drives a community and to empathize with their needs. And then again, this sort of dividing line between and having a clear and transparent dividing line between the two, I think what might help is giving in a concrete example of how this works. And maybe I think one of the best examples today is hashey. Corp within you know, within Mayfield’s portfolio. You know, hasha Corp was founded in 2012. But Mitchell Hashimoto arminda Gar, they’re doing quite well, and it built a strong community and business. And so there’s a couple thoughts that I’ll give that that they’ve done effectively. One is being very, very transparent and clear with the community where this sort of open source focus is where the commercial focuses, if you look at, one of the things they’ve done really effectively is the website. And they’ve been transparent about this, the website is focused on the commercial buyer. And GitHub is really the source of truth for the open source project. So you have a very clear marketing line between where the two areas are going to be for the company, and very clear product lines as well. And so let’s let’s dive into an example. Or if you’re familiar with HashiCorp vault, it’s a platform that’s used as a key management service for storing things like secrets, it has a pretty complicated flooding, I talked about it in one of my slides in a previous presentation and around the different users involved. And this is just in the open source side of the equation around how policies are created. For example, taking a secret, generates, you got it, and then a user who then goes and fetches that secret when they’re configuring or building an application. I think one of the things that’s important here, I mean, we talked about critical path, right. And so this is this is critical documentation, you’re storing key secrets. And if you’re a VP of Engineering, you can be pretty panicked if this went down. So that already creates the basis for a paid support product. But what’s important then is is looking at how the features were designed. So I think I put a slide on this one as well around what’s in the open source version, versus what’s in the enterprise platform. One of the key things for me here is that there’s HashiCorp never compromises on the performance features for open source users. The open source of Vault is usable, is used across a ton of different organizations, where the enterprise features are, are features that typically are more important to enterprise use cases. And not as important, if any, yes, there are some overlaps, but they’re typically designed for enterprise features. And so I’ve often bucketed features in three categories, I think I mentioned peace of mind, which is around security. And typically, you know, security and access control. And often things like high availability as well. But basically, helping enterprises know that this isn’t going to go down, and it’s not going to be compromised. The other thing is enterprises really care about our collaboration, you know how to different teams at scale, start to use this product and work together. And then performance. And now this is where it could get controversial if you make the product less performant, the open source that’s not going to play well with the community. But what you can instead do if you’re good at it, you know, you’re thinking through the product is what are the performance pieces that enterprises care the most about. So a good example for this in vault is read replicas, which is basically read only replicas, which are used in different for example, availability zones, that’s something that’s more common in in a multi scale, multi cloud, multi architecture, enterprise environment that’s not necessarily as common and with open source communities. So that’s how you can think through what are features that enhance performance that are really important to that enterprise buyer? Primarily. There’s a fourth use case I often think about I didn’t have in the slides, which is insights and analytics. If you look at a VP level person, they want to understand the effectiveness of their solution. How do you build the right dashboards, analytics that really help that VP understand or that executive understand that the solution is being used effectively, that is had the right you know, digital transformation effects within the organization? So that’s another piece I think about. So in depth, you can look at this and see, okay, this, this is what your community really cares about, you know, don’t compromise on what’s built there. What then does the enterprise buyer actually care about? And how do you build the right features for that?
Erasmus Elsner 29:23
And we talked about this divide between the open source project and the company. Now let’s get a layer deeper and look at the company perspective. You had this great slide on potential firewalls, between the community team and the commercial team. You mentioned there, that it is difficult to find the right boundaries. How do you think about optimizing that from a company perspective.
Vivek Saraswat 29:46
You have one team that really makes a decision on a product side between open source commercial features, as you’re thinking of segmenting your product. You know, if you have one person who’s looking at both the community and commercial aspects, that’s great. If at least As a team of people, as you get bigger, and at scale where there’s some committee and some commercial coming from product, I think it’s more challenging and better exercise to have a product person thinking about both aspects of the business. One way to think about it is, you know, can you segment by use case, when you’re building out your product team, you have different use cases in your company like orchestration, analytics, or whatever it might be the use case for the user, and then have product folks assigned to that use case, having product folks assigned a tech stack, like piece to stack is difficult, because you’re thinking more technically, anyway, you’re not thinking about what the user end buyer actually wants. That’s why I think segmenting by use case works. And then if you’re using open source and commercial, you can sort of divide one person to take up both of those duties. If you have multiple people, make sure you just have a ton of, you know, roadmap thinking and those types of meetings, in order to ensure that everybody’s on the same page, make sure that your community people, this is actually one of the biggest pieces of advice I was given early on in my product career was get to know the go to market people you want. If you want to level up in product, you really need to deeply understand go to market, and to spend time with sales on marketing. And I think enterprise people in the enterprise and commercial to house know this, people on the community side were a bit on the me side may not know it as much. And so it’s actually deeply important for community people to spend time with with GTM folks to understand what happens there, and and what buyers care about, even if that’s not day to day what they do, because that’s a part of the business. And so part of what you’re building, and if you can get this right from your culture early on, then the culture grows in a way that emphasizes both community and commercial. By the way, you have to do the reverse. You need to make sure that your go to market people and you’re commercially going to product people really understand the community as well. So make sure you’re doing those visits, those meetings, you know, if you start doing conferences, then that’s a good way for people to get in touch with those users. You need to get that culture inculcated very early in the organization.
Erasmus Elsner 31:51
I think it’s interesting what you mentioned that this should be really instilled in the organization at the earliest inflection point. Mapping it to funding rounds. Is it already after the Seed, is it only after the Series A.
Vivek Saraswat 32:03
Thinking about commercial is discussed right at the beginning, from Seed onwards. And the reason why it’s discussed early on in the organization is that you need to know what the commercial is going to start to look like. Obviously, it takes iteration and at the seed stage, there’s a lot of you know, there’s a lot of things that are still going on and being figured out. But you need to start building that long term vision so that you can work your way backwards into what stays out of the Community Edition, so to speak, the good folks are thinking about this right from the beginning. Now they might be really focused on community adoption at seed and even at series a, a lot of the companies we invested in series, they don’t have any monetization yet when they’re doing bottoms up community based approaches. But they’re thinking about what will happen they’re thinking about who that buyer could be. They’re having need finding conversations early on in the game early on in the company c threes a there are sort of three hires, I think, that are extremely important to a early stage company in the bottom sub community world product strategy, really understanding what is going to be that difference between company and commercial? How do you build free versus paid products? How do you think through virality, there’s Product Marketing, which is one, I think that is like the most under hired role in early stage companies. And this isn’t just about building sales collateral, it’s about understanding user buyer personas, it’s about getting the value prop across, it’s about creating the content that you can use in the community for community adoption. And then the final sort of talent is Community Relations or dev REL. And that’s about outreach, engagement, growth, building, that flywheel of activation and adoption and advocacy. And sometimes you get these in one unicorn, but person usually not usually takes a couple. But these are key early hires that we’re talking about a lot. And a lot of companies at the early stages from seed and onwards, how you then go build the rest of the GTM organization that often happens a little later. And I think it’s important that founders understand what the sales process will look like before they go and hire you know, a VP of sales are a high level sales leader, once you go build out the sales organization, you can’t you can’t stop you don’t want to you don’t want if you have to reverse course and go from Field Sales inside sales. That’s a different group of people. And you know, you might have to make some unfortunate cause an organization that’s that’s hard to recover from the process of actually building up those teams often happens a little bit later. Whether it’s maybe starting a series A often Series B onwards, depending on the company, but the thinking around how is this all going to look, the good founders and the good team members are thinking about this from the earliest stages of the business.
Erasmus Elsner 34:24
With this, I want to really wrap up this session. And for anyone who’s interested in learning more about your writing and what you’re up to, where can people find out more about you.
Vivek Saraswat 34:33
People can follow me on twitter at @theVSaraswat. What I also love writing about these topics and I you know, I write on my blog that they starts with.com where I talk a lot about product and go to market strategy and investing and particularly as it relates to sort of bottoms up and product like businesses. So that those are two different ways. You can sort of find out what I do just love talking about this in general. So, Erasmus, you know, thank you so much for having me. It’s been a blast, talking to you.