Episode 36
· 38:31
I think what commonly happens is people try and think like 3 or 4 steps ahead, which is like, well, what part should we open source? And like, should we keep some proprietary? Because are we giving away the secret sauce and all these sort of things?
Jack Bridger:Hi, everyone. You're listening to Scanning Dev Tools, the show that investigates how dev tools go from 0 to 1. I am joined today by Shomit Ghosh who is partner at Bold Start Ventures and focusing on dev tools, investing in companies like Snyk and Superhuman, and also the founder and writer of Software Snack Bites, and an upcoming podcast, which we'll do a little preview for, called Software Snack Bites. Although it's not released yet.
Shomik Ghosh:Yeah. So not released. There'll be software Snack Bites the blog and then software Snack Bites the podcast because I figured why not?
Jack Bridger:If you if it works, you gotta you gotta double down. I like that. Yeah. So, Shomik, we were chatting a lot on Twitter a few weeks ago, and then we've been chatting since about all things dev tools. And I really enjoyed it, and I learned a lot.
Jack Bridger:You see a lot of things in your kind of, like, VC role, and you see many companies, and I know it's something you think a lot about. You write a lot about dev tools. And so what I thought might be interesting was that I'm at the point where I'm, like, trying to figure out what dev tool I'm building. I'm testing ideas, and it might be fun to kind of almost do, like, a kind of office y hours type thing where I can ask you about we could talk about, like, a specific example and how you think about business models, how you think about go to market, open source versus not open source or part partly open source. And all these kind of ideas, these topics that I think a lot of us have questions about.
Shomik Ghosh:That sounds great. I would love to do that. We had a lot of fun, actually. I forget what happened. It was a it was a thread, I think, on dev first go to market or something like that.
Shomik Ghosh:And somebody had commented on, I think, a podcast you had posted or a post that you had posted or something and tagged me in it. And then we just had, like, fun back and forth just asking questions, then we took it to DMs, and then, like, ended up on Zoom. And so one of these fun things where everyone talks about just Twitter is the most amazing place, in my opinion, where you can meet just incredible folks thinking about new things. And I'm just thankful that that interaction happened so we could be here today talking.
Jack Bridger:And I know that actually one of the things that you knew quite a bit about was Stack Overflow where I used to work, and you had a lot of I guess you've spoken a lot a lot with Alex from Stack Overflow about about some of the stuff. That was very interesting to hear as well from my perspective.
Shomik Ghosh:Yeah. Alex Miller, if you're listening, Jack and I are both big fans, and, you know, we love you. It's always down to chat anytime you want.
Jack Bridger:So I I thought I'll set the scene. So here's an idea if so a chat SDK, so a a tool to make it easier to build chats and focused on React Native and very, very simple based on the idea that even though there's many kind of great tools out there, we still see a lot of questions on this topic in in rat native Reddit subreddits. Everyone still asks about chat, and it it doesn't feel like there's kind of a perfect scenario. So one of the first questions that I'd have about this is kind of where to start thinking about a business model. There's a side of it that's like open source maybe on the front end and maybe on the back end, it's kind of more, like, proprietary.
Jack Bridger:But how how would you be thinking about this area?
Shomik Ghosh:So first, one thing I would say is clearly a big pain point and a and a big need. Right? A lot of developers want to build chat natively into applications. Writing your own scripts to do that would be, frankly, not necessarily a waste of time, but you could spend your time in much better ways. And so if you could leverage an SDK or or API or whatever to to spin that up, that would be you know, I think that would save a lot of cycles for a developer to then focus on more of the core application that they're building.
Shomik Ghosh:So I think, 1, that's great. Right? It clearly saves developers time and allows them to focus on on other things that they'd like to build to build the the business value. Then the other thing you mentioned was the focus on the React Native ecosystem. Right?
Shomik Ghosh:And and the great thing about that is you're compressing the scope. Because right now, let's say you were just saying, hey. We're gonna build an SDK for developers to use for chat, and now all of a sudden, it's it's very broad. Anybody in the world. So who's going to use it?
Shomik Ghosh:Is it a back end developer? Is it, you know, a front end developer? Is it a front end developer in any of the modern frameworks that exist? Right. There's so many different ways that you could slice it.
Shomik Ghosh:That's very hard to figure out even how you would start with your go to market. So by narrowing it down to the React community, now, 1, you you already know where they're hanging out. So the React community, it's, you know, I forget the exact conferences, but I think there's React Con and a couple other conferences that happen. Likely, there's a few discords or Slack channels that that everyone is hanging out in. And then the blog posts and the people who are key influencers in those areas are also something that's fairly well known, at least from Twitter.
Shomik Ghosh:Right? And so all of a sudden, you've compressed down what what seemed like this hard problem at first, which is just like, who do I reach out to? How do I figure out how to get into their hands and things like that? And you've narrowed down the set to something much more distinct of this is who I'm going to target. This is who I'm going to focus.
Shomik Ghosh:Right? That's actually a lot easier, even though what's funny is somebody may ask, well, aren't you reducing the TAM, the total addressable market that you might be targeting? And the answer is actually is no, because the broader you start out means you're addressing more competitors. So your product messaging is actually going to be, frankly, a little bit weaker because you're trying to talk to too many different personas, right, about, hey, here's the value that we're bringing. You have to hang out in more communities to try and get it in front of people, all that sort of stuff.
Shomik Ghosh:So by narrowing it down, you can tailor exactly. Here's a documentation. Here's the things you need to know about the React ecosystem that here's where what integrations we have out of the box. Here's how we work with, you know, this type of framework that you're using, whatever. Right.
Shomik Ghosh:Those are all narrowed down. And so you can get to that initial subset of users a lot quicker and a lot faster because you've narrowed that down. And so that's always the funny thing is actually the largest eventual TAMs start out with the smallest, narrowest focus on the most acute pain point because then you don't have other competitors, you don't have other product messaging and things that you need to cover. And so you can really, really tackle that acute problem very closely.
Jack Bridger:One of your blog posts was quite interesting on your newsletter where you talk about the kind of, like, early stage versus the later stage with some humorous examples that you found.
Shomik Ghosh:It's it's funny. Right? Because I would say none of this stuff is static. What we just talked about is you're building for the React ecosystem. But what happens if over time, everybody in the React ecosystem is now using this?
Shomik Ghosh:Well, you're gonna look into what areas would I move into so you could continue to move into other parts. Maybe you're doing chat, and so now you move into something in terms of customer support or automated buying or whatever that would be, right, as another area that you move into. Or you say, hey, you're doing chat, then we'll also handling we'll handle SMS messaging or whatever. Right? And so you're starting to broaden out your suite.
Shomik Ghosh:You could choose to do that within the React ecosystem where you've already scaled your business and you've already got a bunch of users and got a bunch of brand recognition. Or you can now start to be like, well, React is great. We've done a great job. You know, what if we replicate that with Angular? What if we replicate that with Vue?
Shomik Ghosh:Or, you know, I'm forgetting all the all the frameworks out there out there. But basically, you start to then say, okay, could I replicate that and move into an adjacent, community, to then also increase the size of the market that I'm going after? So those are very interesting things. And by the way, like when sneak first started, for example, they started in the Node. Js community.
Shomik Ghosh:So they started flagging vulnerabilities for specifically in the Node. Js community. And then over time, they started expanding to, you know, Python, Java, Ruby, whatever. Right? All the other programming language.
Shomik Ghosh:But at first, they they focused on one narrow community because they knew the pain was deep there. And once they were able to prove it, then they were able to quickly expand the market by moving into adjacent areas. If I'm thinking about, like, okay.
Jack Bridger:I know I'm gonna go after a native developers, and I'm gonna just really focus in on chat and I'm gonna have, like, very clear messaging on that. One of the things that comes into mind is, like, which parts of my project should be open source and which parts shouldn't or should the whole thing be open source because that's one of the ideas that I've thought about is that none of the kind of existing players are open source fully. They're open source on the front end, most of them. And whether you could actually build a business model around that where everything was open source, for instance.
Shomik Ghosh:The interesting part about this is a lot depends on the type of developers that you're targeting. And so let's say the React Native community is, and I believe this may be the case, is fairly open and excited about exploring new open source projects. And so if that's something that regularly is done by developers to test out new products or to contribute to them or look into them, then that's probably means it's a good entry point into that ecosystem because that's already the way that developers discover, use products in that area. That may be different though for other segments. Right?
Shomik Ghosh:So that's, again, understanding your user persona, understanding the pain points where they're coming from, how they adopt products, where they find products, how they want to experiment with products. So all of that is what influences your decision first of do should I open source this or not? The next thing I would say is, you know, does looking under the hood of of the car, right, does looking under the hood help the developers? So in, you know, in this chat SDK, like, does the ability to go in and see, okay, here's how everything's working, does that give them more trust? Does that give them more customizability?
Shomik Ghosh:Does that give them more flexibility in terms of the integrations that they can contribute themselves? Maybe if if, for example, you know, the the hosted version that you're delivering does not have those certain integrations built in, they can actually build into the open source themselves, and contribute that, right, to move that along and further that. And so, again, this is something that you need to really understand that end user and how they like to build to decide, is it the right thing to open source or not? I think what commonly happens is people try and think, like, 3 or 4 steps ahead, which is like, well, what part should we open source? And, like, should we keep some proprietary?
Shomik Ghosh:Because are we giving away the secret sauce? And all these sort of things. And those are, for sure, good questions to ask because maybe, in fact, there is something that you're giving away that's core. Right? In which case, you should assess, like, does it even make sense to open source at all?
Shomik Ghosh:Right? If that's the case. But for the most part, if you can nail something down from a pain point perspective and allow developers to go into the open source project and play around with it, see what it's like, and then say, hey. Here's the managed service that we're delivering to you, which has all the enterprise features, role based asset control, SSO, all of those things that you need. Right?
Shomik Ghosh:Plus, also, we're working on super easy integrations with your build tooling, with your whatever different tooling you use in the ecosystem. That all of a sudden makes it so that they've seen the open source. They trust it. They understand it. They've read the documentation, and now they can start saying, okay.
Shomik Ghosh:Well, wow. I would love to use a managed service because it would just make my life a lot easier. Right? And so that a lot of people think the open source commoditizes the growth, but, actually, it's much more of like think about it much more of like a sandbox or a playground to a certain extent, where developers can go out, test the product, understand what the product would do, and then maybe they build their own, which, by the way, if they do, guess what? They're going to be contributing back to the open source project and improving that experience for everybody else, which will then lead to more leads for you for the managed version.
Shomik Ghosh:So that symbiotic relationship is is pretty cool when when the motion gets working.
Jack Bridger:Mhmm. Let's say, like, I open sourced the whole thing. What kind of license would that be easily?
Shomik Ghosh:Yeah. The licenses you know, I think I think different people would have different answers to this. And, clearly, some founders, especially on the database side, have adjusted their licenses to be a bit more restrictive in terms of not being able to use them for commercial purposes for the likes of the AWS, the GCPs, the Azures of the world to kind of take their open source project and use it. But for the most part, especially in the early days, like, just pick a license that creates the less the least restrictions for developers to use the product. Because the thing is, the the higher the restrictions go, the more friction you're putting into that process of allowing developers to explore and to use the product, which, like, is exactly the opposite of what you're trying to do by open sourcing in the beginning.
Shomik Ghosh:Right? So if you have a restrictive license, that's that's very challenging because now all of a sudden, a developer needs to worry about, well, I don't know if I'm using this the right way or not. What if I get sued in the future and I put my company at risk or I'm gonna have legal on my my butt, like, trying to tell me, hey, why don't you understand this before you start using it? Or the most permissive ones are the MIT, the Apache licenses. Those sort of things is usually what I would recommend for an open source project.
Shomik Ghosh:And then as the business evolves, you know, if you see, like, what Elastic, Mongo, Confluent, and others did, they they shifted at that point. It hasn't affected their business, and they had good reasons to shift. But you can evaluate that once you've reached a certain scale, that decision makes sense.
Speaker 3:Mhmm.
Jack Bridger:Yeah. That makes sense. So don't don't worry about it for now. Like,
Shomik Ghosh:there's a lot more things you have to worry about, which is, like, just how do you get users to use the product versus trying to figure out, like, is AWS gonna steal my chat SDK? Yeah. It's like to be honest, like, AWS would only do that when it's the project is so huge that they were just like, oh, wow. Okay. We could just fork this code and make it ourselves.
Shomik Ghosh:Right? But that's the only reason they would do it. If it's even got, like, you know, a 100,000 downloads, which, you know, pretty good. That's that's pretty solid, right, for an early company. It's still not enough for AWS to care, to be honest.
Shomik Ghosh:So
Jack Bridger:I've got a very permissive license. I've got MIT license, and I it's, you know, fully open source front end, back end. And I managed to get some users, let's say, like, I don't know. I'm in I'm in the UK, so let's say, like, BP. We want to build chat with this with us.
Jack Bridger:In fact, there's some already some devs that used it in one of their hackathons. And now, like, I'm I'm in a conversation with someone. What and they say, like, you know, what's the pricing? What's the business model like? Or I'm sending them an email.
Jack Bridger:What are you kind of advising me to?
Shomik Ghosh:Well, first off, I would say, hey. Congrats. That's pretty cool. BP is a pretty big company. Like, that's pretty cool that they're using your your product.
Shomik Ghosh:But then I would start to ask a couple more questions. Right? Which is oh, great. BP, large enterprise. Right?
Shomik Ghosh:As you can imagine, they probably have a pretty detailed process in terms of how tooling gets into their org. So, 1, that sales cycle to get in, in terms of the security that they're gonna need, the enterprise features that they're gonna need, the procurement process, and the sign off that you'll have to get is probably going to be a pretty lengthy cycle. So is that something that you want the team at this point in in the stage of the company to be focused on? And this is the really hard thing for early stage founders because what happens is the BPs of the world come in, and they float this thing in front of your eyes. And it's like a 100 ks, maybe even some cases 250 ks, 500 ks contract.
Shomik Ghosh:And you're just like, this is crazy. Like, this company just came out of nowhere and is going to give me this money. Right? Like, how could they how could they do that? But the flip side is the cost of having a company that is that large of an enterprise this early is gonna completely skew the road map to going enterprise almost too quickly.
Shomik Ghosh:And that doesn't give you enough time to actually discover, is your hypothesis correct of, do the majority of developers actually have this pain point that I'm solving? So you solved it for BP. Great. But what about the I forget what the count is right now, but let's say 30,000,000 developers that are in the world. What about the other, you know, 29,900,000 that exist outside of BP?
Shomik Ghosh:Right? So that's something that I think early stage founders always need to think about is, yes, the allure of getting that contract and getting that logo is incredible, but the amount of things that they're going to request and the amount of support they're going to need and the amount of time they're going to suck from the team may actually detract from the business long term because what you need to do instead is focus on validating your hypotheses that you have in the early days, that you're on to something that solves a core developer pain point and will be something that they will use as a part of their daily workflow. So that's gotta be the north star. That's gotta be the thing that you're trying to prove out. And, you know, what's funny is, I think Auth0's first customer was actually an insurance company that came in inbound for a 200 k contract.
Shomik Ghosh:I mean, amazing. Right? That that was the first customer. But it was actually, I believe, an on prem customer that they then need to maintain for the rest of the company's life cycle. And as you can imagine, that was something that they had to balance of how do we make sure we're shipping the updates?
Shomik Ghosh:How do we make sure we have the support and all those sort of stuff? Versus meanwhile, they had a bunch of customers on the the host of the cloud version. Right? And those were all getting updated at the same time and and on the same release case and everything. And then you've got these on prem customers that are big customers paying you lots of dollars that you still need to support, and you almost need to have a dedicated team that's sitting on that and taking away from your, you know, your time and focus on the majority of the road map.
Shomik Ghosh:So that's a very important thing for people to figure out is when to say no to early customers.
Jack Bridger:You'd be advising me heavily, like, Jack, just this is not the right time for your, you know, this is your 1st customer, build a hosted version. It's like our 1st if like our open source project is doing pretty well. People are using it. We're getting some interest from BP for some reason. But what I should be doing is making sure that the hosted version is is really good and and seamless and much easier than self hosting.
Shomik Ghosh:Even if it's not necessarily the hosted version, but more so you should be figuring out, is your open source project resonating with BP? Because they just happen to have hired the ex Facebook lead of React Native open source, who understands everything about React Native and is and so, therefore, their team just knows what's going on. It's just like, oh, okay. This works really well. But what about the developer that, you know, hasn't even heard of React before or maybe just heard about it and just implemented it?
Shomik Ghosh:Is the documentation the right way for them to understand how the open source is going? Do you have the right integrations put in place for them to understand how to deploy this? Do you even know how they would deploy it? Right? Have you learned that yet?
Shomik Ghosh:And so you may have this problem where you actually go into an area where either the customer is too advanced and not actually your core persona, and then you'll they're going to give you product feedback. Right? Like, that's what every customer does. Once they get in, they're going to be like, oh, yeah, this is amazing. What if you build this and what if you build that?
Shomik Ghosh:But if they're too advanced or if they're or if they're not advanced enough or if they're if you don't choose that sweet spot, you're going to start getting feedback that's going to skew your roadmap away from what your initial idea is. So this is not a question of, like, hosted or not or whatever. It's it's just even before that, it's how are you thinking about the core pieces of just your open source product, the readme file, the documentation, how you work with contributors, how you work with issue requests. Right? What's your SLA is gonna be about issue requests.
Shomik Ghosh:Right? Like all those sort of things. How are you going to build the community? You've spun up a Discord channel and now it's all BP React Native engineers, right? Like, I mean, maybe that's a good thing.
Shomik Ghosh:Maybe not. Maybe it scares away a bunch of other people who would love to be in that thing, but they're just like, oh, wow, we got this major enterprise folks that like are talking about something that I don't even understand or I've never looked at before.
Jack Bridger:And so almost like just focus on the open source project at the beginning.
Shomik Ghosh:In the beginning, like if you're open sourcing it, like you've clearly thought about the reason to open source it. Right? Like, open sourcing is not easy. Like, it takes a lot of effort. Right?
Shomik Ghosh:Because done well, you need to go out and you're putting a product into the world. You're getting real time feedback. Like, it's I could go into any open source project right now and see the issue request and see if they're responding to them. Right? And I could then start to formulate as a developer, do I think they're responding fast enough?
Shomik Ghosh:Do I think they're, do they care about their users? Right? All that sort of stuff. And guess
Speaker 3:guess what? If the answer to that
Shomik Ghosh:is no, well, I'm just gonna go move on to the next product. Right? So it's less so, like, less so about thinking about the future state and more so trying to think about how do I solve pain points now? How do I deliver stuff to end users that they are going to just be like, oh my god, thank you so much for solving this problem? A lot of times, we may start to think too much about the future when we just need to deal with the present.
Shomik Ghosh:And the present is just like, we made this we decide to open source. We need to go build this product. Let's make sure that we build it in a thoughtful manner because, otherwise, our effort put into open sourcing, this is gonna go to waste.
Jack Bridger:Yeah. It's a this is actually, like, really interesting because I think, like, I think maybe this is this is my inexperience showing, but I think I was kind of as a VC, I was kind of almost expecting that you would be in the camp of, like, you know, we need to I don't know. Just think big and think about, like, you know, exact business models, exact all that plan all this stuff out super strategically. And I think everything you're saying is really just just focus, get rid of all the kind of obstacles to just focus on on that experience and making sure that what you're building is really good and, like, you're actually solving the pain points.
Shomik Ghosh:Yeah. When we back a founder like, frankly, the business model, the pricing plans, the even who you hire when, there's sort of playbooks for that for various different companies, right, and at different stage and stuff. We've just seen the reps through different companies so many times. There's tons of advisers out there, things like that, that you can figure it out. And by the way, I can a 100% say whatever pricing you put will be wrong, and it'll be wrong, like, till, I mean, forever, pretty much.
Shomik Ghosh:Like, you will just be constantly iterating and changing. Right? So spending too much time focusing on those things is not worth it when the first thing you need to do is you need to get one user in the world who says, wow, you helped me do something that I was never able to do before. And then you need that 1 user to tell 5 other friends so that now you've got 6 users. And so you go from 1 to 10 to a 100 to a 1000.
Shomik Ghosh:Right? That's how you actually grow the adoption of the product, the usage of the product. Right? And meanwhile, you're getting, issue requests. You're getting feedback.
Shomik Ghosh:You're getting product roadmap ideas, all these sort of things that allows you to start to take shape of what this product will look like. Right? That's then when the business model starts to come in because now you're starting to see, wow, okay, what I originally thought was they were going to use us for chat in mobile applications. Right? Well, now maybe all of a sudden you're seeing, you know, no.
Shomik Ghosh:They actually love using it for browser use cases. So I don't need to actually staff up in iOS and Android team. I can just focus on writing JavaScript or something like that. Right? And then just be able to deploy it really quickly and easily into browser based applications.
Shomik Ghosh:Right? That's just one example. Right? But but those are the sort of things that you can learn that then influence your pricing, influence the product delivery, influence, is it going to be a self serve product that they can just go to the website and start playing with immediately? Or do do they need to get a demo before they use it?
Shomik Ghosh:That's all gonna happen from seeing real life users. So then you can start to make those decisions that actually help build the business in the long term.
Jack Bridger:Start kind of learning and just getting down the road and as getting as much information as you can.
Shomik Ghosh:Optimize for learning early is what I would say. That's the number one thing. So the first sales hire at Snyk, his name's Ethan Schechter, and he has a a great, saying, which is I think it's it's trade dollars for speed. And what that means is we were talking about that BP example. Right?
Shomik Ghosh:They're coming in with the 200 k contract. Is it worth it to have the 200 k contract or the 5 k contract? The user feedback and the usage is going to be 10 x faster. Right? Because we just talked about how long it will take to deploy into BP and all the things that we'll need to do in order to validate that your product is actually being used and working.
Shomik Ghosh:Right? Versus the 5 ks contract where you're right in the hands of the customer from day 0. They're using you. They understand that the product's early, so they're giving you quite feedback. The feedback cycles are very tight.
Shomik Ghosh:And so now all of a sudden, the compounding and the learning that you've done is, again, 10x faster than the person who went with BP and is still trying to wait for them to even deploy it in the org.
Jack Bridger:It's very valid point. It's very hard to say no to that. Yeah. As you said. Okay.
Jack Bridger:Let's say, like, things started going really well for this fledgling company. We said no to BP. We focused on our open source project became really great. Everyone started loving us. And then we launched a hosted version and we we start, getting quite a lot of business from, like, really easily at the beginning from that people coming into us and stuff.
Jack Bridger:But then we things start to maybe slow down a little bit, and we have to think about, like, okay, how are we actually gonna get people to use us? How are we gonna get more customers in, like, a kind of predictable way? I know you've written quite a bit about kind of go to market strategies. I wonder if you could share a little bit on how you'd be thinking about this.
Shomik Ghosh:So much of it starts from the early days, which is why we're talking so much about these decisions that you make from day 0, right, that affect the long term outcomes of the business. For example, if you were seeing a slowdown, the question would be, okay, well, given the open source success to date, right, and now the hosted version is getting adopted and stuff, what's causing that slowdown? And it could be that not enough time was spent, for example, on the community to build up a host or a group of avid users that could help each other out. And so what's happening is, you know, the product's grown so quickly, but the onboarding because of the of the product growth, the onboarding was never able to get absolutely dialed in. And so what was happening before was the users were helping each other along, and they were saying, hey.
Shomik Ghosh:We get it. You know, this part is hard, but, like, once you get through that step, like, trust me, it'll it'll solve all your problems. Right? But at a certain point, either, 1, you don't have enough of those users that are still doing it, or 2, you have to adjust the fundamental problem that's happening within the product. Those are different things that you all have to diagnose at different stages.
Shomik Ghosh:And the other thing I would say is also it ties into your go to market. Right? So let's say that the way that you scaled the chat SDK was you reached out through all of your VC friends and all of your founder friends, and we're just like, hey, listen. This is what, you know, I'm building. Put me in touch with some people.
Shomik Ghosh:Okay? And they put you in touch with people, and those people love the product, and they started using it, and, you know, that's great. But what never happened was you because that was successful, you never actually had to build up the the content, the documentation, the community, the all these aspects that power the growth in the future of the business. Right? And so because of that, now all of a sudden, you're sitting there and you're looking at this like, hey.
Shomik Ghosh:I have a great customer base. This is awesome. Right? And I I have meaningful ARR, but, like, what's what's gonna happen now? And so you took a top down approach to something that maybe necessitate much more of an end user bottoms up first approach.
Shomik Ghosh:Right? Which would be much more focused on dev adoption, focused on, again, documentation, ease of use, community, content. Right? All of those sort of things. So these are the things to balance.
Shomik Ghosh:Right? Because if you go too quickly, and it's very easy, for example, like, on on sometimes in the top down motion, especially if you have a big community, to just get your initial users. But if you haven't figured out how you're going to continue to do that top down lead sourcing, you're gonna basically, it's gonna all dry up, and then you're gonna be sitting there with, let's say, you're a million AR business. Congrats. That's amazing.
Shomik Ghosh:How many people reach that, right? But now how do you grow from 1 to 5 to 10? You have no method of doing that unless like, okay, well, now I've got to go hire a bunch of sales reps and go and build that out. And so that goes again to the product. Is it solving an individual use case, right?
Shomik Ghosh:In this case, the chat SDK would be right. Any individual developer can go up and play with it versus if you have like I like to call it, like, lighter and heavier products, but it's kind of like in in some cases, it may also be, like, single or multiplayer. But but basically, if you have, like, sort of a weightier product that requires larger implementation or something like that, that will actually not work bottom stuff. Right? Because an individual developer can't bring that into their org.
Shomik Ghosh:You need a top down person to say, hey. We're going to commit to doing this because it will transform the organization forward. Right? And so knowing that, understanding that from the early days is what's gonna help you guide your GTM so that you don't hit those air pockets as as it's growing. Right?
Shomik Ghosh:Because you understand what the best way to interact with your with your end customer and user is.
Jack Bridger:Yeah. I think that's a really, really important point. This is a lot of what we were kind of talking about on Twitter in that, like, your go to market strategy is, like, largely dictated specifically on how you, how people use you and whether, as you said, it's like like a kind of individual, like, team player type thing. And I think it's very interesting because they're kind of classic, like, dev tools is like, okay. It's got gotta be bottoms up because it's dev tool.
Jack Bridger:But actually, like, there are cases I think the one that you spoke about in your article was like CrowdStrike and the an individual developer wouldn't necessarily see the benefits, but so it has to kind of come from that top down approach versus sneak where people developers would see it so they could go bottoms up. I think it's a really good post that you did. We'll link to it.
Shomik Ghosh:I think in general, just thinking through your product. Right? So if you're doing endpoint security, like, if you only have one endpoint, like, what what is there to secure? The whole point of endpoint security is that you have a mass of endpoints that need to be secured. So what does that mean?
Shomik Ghosh:That means that one individual player cannot make the decision for the whole group. Right? Versus if you're trying to find vulnerabilities in an open source library and understand those and remediate those, well, any one person can be importing libraries or using whatever and understand, okay. Wow. There's an open source vulnerability in this area.
Shomik Ghosh:I'd like to make my code secure. Even if you're making the smallest little you know, all these apps, right, that are coming out. If they get hacked, that's still kinda bad. Right? Because it's a lot of users are using it.
Shomik Ghosh:They put in some sort of data. They put in their Gmail addresses probably or something like that. Right? And so, obviously, they don't wanna be hacked. So that's something that is a single player use case, right, that everyone can get value from versus the more like the endpoint security use case where that's a multiplayer use case.
Shomik Ghosh:Right? So it just wouldn't make sense for CrowdStrike to go and say, hey, security engineer, like, use our product. This is great. Right? You need to go to the CSO, to the head of security, to the VP of engineering and say, I know this is a problem for you.
Shomik Ghosh:We're gonna solve it in a much better way, and here's how we do that. Right? And doing that early and understanding that helps you not fall into traps. Right? Not try and do something bottoms up when it should be top down, not try and do something where, you know, you're spending a bunch of time on end user adoption when, like, the payoff is that's not actually gonna help, right, at all.
Shomik Ghosh:So I think understanding those early is very important.
Jack Bridger:I think it's really important one. I think that's all we've got time for, Show Mick. One new suggestion to the podcast from a listener, Joe, is that we should do, like, a TLDR at the end, and I'd love to hear what you're taking away from yourself. Is that we should really not get too caught up in some of this, like, business model stuff at the beginning, and we should really just double down on focusing on doing something useful and really solving a problem.
Shomik Ghosh:Yeah. I think for most dev tools, start with deeply understanding your end user and the pain of that developer. And so make sure you're going as deep as you can into who that user profile would be. And that's why I loved you said the React Native example. Right?
Shomik Ghosh:So then we kind of know, okay, React Native means most likely front end engineers, right, that are experimenting or or using this framework. Right? And so you're starting to narrow down that focus. You're starting to understand who your end user is, what tooling that they use, how they interact with their tools, all that sort of stuff. Getting that right matters a lot more than saying, well, hey.
Shomik Ghosh:My business model will be I'll deliver a hosted solution at scale, and we're gonna, you know, we're gonna move from chat into SMS, and then from SMS, we're gonna move into that. Because, like, if you don't even get there, you can't do that next step. Right? You first have to get there along the journey. And so that that's what I would say.
Shomik Ghosh:Focus on the pain point that you're solving. Get developers to use the product and understand and embed it in their workflows, and then you can figure out the pricing. You can figure out the delivery model as that goes forward.
Jack Bridger:Thanks, Shomik, and thanks for joining. And thanks, everyone, for listening. And I think we're gonna be closing out with a little clip from, Shomik's new podcast called Software Snack Bites. So if you like the clip, go and, have a listen. It should be available on all good platforms.
Shomik Ghosh:You've had thousands of companies pitch you their security products to to buy as a customer. Right? So how have security companies been able to break through the noise and get through to you as as and say, hey. You should purchase my product.
Speaker 3:Yeah. I get this question a lot because we're also very vocal about how many of these sales emails we get and how we don't respond to any of them. And and, you know, and and very valid so I have sales leaders or or founders ask me, then how do I sell to you? Usually, my answer is is not trying to be snarky, but my answer is don't sell to me, sell to my team. Primarily because I've always yeah, I'm connected to technology.
Speaker 3:I talk to a lot of founders. I I I like to stay close to what's coming out there. You know, I talk to you. I talk to, you know, VCs who are invested in early stage companies because I wanna learn and see what else is what else is being worked on. And maybe there's a new trend that I haven't thought of and things like that or a new approach.
Speaker 3:But I've always been the type of leader who I let my I I hire people because I trust them. Right? And and if if I'm the one making all the decisions, then I then I I'm failing. But also, then I'm not sleeping at night. Right?
Speaker 3:And then I don't have weekends and I don't have time off because if all the decisions come to me, then then the system is bound for failure. So I you know, so to my team. And then I I think what attracts us are new what attracts me in particular, I can't speak for all my team, but what attracts me are how do you take you know, in security, we always say this notion of, like, oh, we've been working with the for the with on the same problems for 20 years. And I think the follow the snarky follow-up that I have with that is, like, yeah, but we've been trying to solve them the same way for 20 years, and we're failed. Right?
Speaker 3:So it's the problems are always gonna be there. Right? If you don't try new ways of solving them, then you're never gonna solve them. Like, you can have a leak in your house for 20 years, but if you never actually fully patch it, then you're always gonna have water coming in. It doesn't matter how much paper you put on it.
Speaker 3:So to me, it's like how you're taking a a an existential or what I call boring problems and solve it in a more exciting way. And by me, more exciting is how do you actually get the people who have to deal or lift the outcome of that action or decision? How do you get them to fall in love with your product? And And and that's something that I think of security. Security, when it comes to technology, has the easiest job ever because we can we can a, security spend still grows even with this down market, And most of the security teams that I know are like, I would rather buy a 100 things just to make sure that we're protected rather than, like, let's actually build an ecosystem that makes sense and and buy things that just connect to each other.
Speaker 3:So I can buy a 100 pieces of technology, put in 30 of them might be running operationally. The other 70 are are, you know, shelfware. And then these 30 things are just spitting out things that other people have to respond to and take action on. That's the easiest job ever. I'm here to just tell you what the problem is, and it's your job to fix it.
Speaker 3:Otherwise, I'm gonna slap you with a policy document and and and and complain. That's, in a nutshell, what security is right now. It might be a very pessimistic way, but I think if you if you get some data, you'll find out that's exactly what it is. So I like products that actually involve the other persona that actually has to respond to the problem. Right?
Speaker 3:And and I think one of the things that I wrote, I talk about how it might be an interesting KPI for security products to start measuring, which is, like, the time to decision. How fast you enable teams or your customers to make a decision? But more importantly, how do you enable the team that has to take the action, enable you know, take get to that decision. So those are the products that I'm interested in that that get my attention. But at the end of the day, you know, how you sell to me, you sell to my team.
Listen to Scaling DevTools using one of many popular podcasting apps or directories.
