Shomik Ghosh - office hours with a DevTools investor

Shomik: I think what commonly happens is, people trying to think. Three or four steps ahead, which is like, well, what part should we open source and like, should we keep some proprietary?

Cuz are we giving away the secret sauce and all these sort of things.

Jack: . Hi everyone. You're listening to Scaling DevTools, this show that investigates how dev tools go from zero to one.

I am joined today by Shomik Ghosh, who is partner at boldstart Ventures and focusing on dev tools, investing in companies like Sneak and Superhuman, and also the founder and writer of Software Snack Bite. and an upcoming podcast, which we'll do a little preview for, , called Software Snack Bites, although it's not released yet.

Shomik: 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: If you, if it works, you gotta, you gotta double down. I like it. Yeah. So Schick, we were chatting a lot on Twitter, I a few weeks ago, and then we've been chatting since about all things devils and I really enjoyed it and I learned a lot. , 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 officey 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: , 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. And somebody had commented on, 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 , a fun back and forth, just asking questions. Then we took it to dms and then like ended up , on Zoom. And so it, one of these fun things where everyone talks about just Twitter's 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.

Jack: And I know that actually one of the things that you knew quite a bit about was stack Overflow where I, 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: 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: 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.

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, but how, how would you be thinking about this, area?

Shomik: 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 not necessarily a waste of time, but you could spend your time in much better ways.

And so if you could leverage, uh, 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. So I think one. great. Right? It clearly saves developers' time, and allows 'em 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? 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 gonna use it? Is it, a backend developer? Is it, you know, a, 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. 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 one, 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, commu, 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. 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, their hands and things like that. And you've, 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. 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 adjustable market that you might be targeting? the answer is actually is, , is no because the broader you start, means you're addressing more competitors. So your product messaging is actually going to be, Frankly a little bit weaker cuz you're, 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. 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. 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.

Jack: One of your blog posts was quite interesting, or your newsletter, where you talk about the kind of like early stage versus the later stage, with some humorous, examples that you found.

Shomik: 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. 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, uh, Customer support or automated buying or what, 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. You could choose to do that within the React ecosystem where you've already scaled your business and you've already gone 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 viewer? 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, uh, 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 SNE first started, for example, they started in the no JS community. So they started flagging vulnerabilities, for specifically in the No JS community. And then over time they started expanding to, you know, Python, Java, Ruby, whatever, right?

All the other, programming language. 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 AJ adjacent.

Jack: If I'm thinking about like, okay, I know I'm gonna go after, 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?

In which parts, shouldn't or should the whole thing be open source? Cuz that's one of the. 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: 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. So that's, 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? 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, uh, 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. 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 trying to think. Three or four steps ahead, which is like, well, what part should we open source and like, should we keep some proprietary?

Cuz 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, that's core, right? In which case you should assess. Like does it even make sense to open source at all? 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?

Plus also, we are 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, well wow, I would love to use the 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 gonna 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. So that symbiotic relationship is, is pretty cool when, when the motion gets working.

Jack: Let's say like, I open source the whole thing. What kind of license would that be? Usually on,

Shomik: Yeah, the licenses You know, I think different people would have. Answers to this. And clearly some founders, especially on the database side, have adjusted their licenses to be a bit more restrictive in terms

Not being able to use 'em 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, just pick a license that creates the less, the least restrictions for developers to use the product. Because the

Jack: Hmm.

Shomik: 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 opensourcing in the beginning.

Right? So if you have a restrictive license, that's, that's very challenging because now all of a sudden a dev, a developer needs to worry. Well, I don't know if I'm using this the right way or not. What if I get sued in the future and then 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?

Whatever the most permissive ones are the m i t, the Apache licenses, those sort of things is usually what I would recommend for an open source project. 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.

Jack: Mm. Yeah, that makes sense. So don't, don't worry about it for now. Like worry about it later.

Shomik: you have to worry about, which is like, just

Jack: getting useless.

Shomik: to use the product

Jack: Yeah. Yeah.

Shomik: figure out like, is AWS gonna steal my chat sdk?

Jack: Yeah.

Shomik: like, to be honest, AWS would only do that when it's, project is so huge that they were just like, oh wow, okay. We could just fork this code and make it ourselves.

Right? But that's the only reason they would do it. If it's even got like, you know, a hundred thousand 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, be honest. So.

Jack: I've got a very permissive license. I've got m i t license, and I, it's, you know, fully open source, front and backend, and I managed to, get some users, let's say it like, I don't know. I'm in, I'm in the uk so let's say like, Bp, want to build chat with, , this, with us.

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.

What are you kind of advising me to?

Shomik: Well, first off, I would say, Hey, congrats. That's pretty cool. a pretty big company. Like that's pretty cool that they're using your, your product. But then I would start to ask a couple more questions, right? Which is, so great bp, large enterprise, right? As you can imagine, they probably have a pretty detailed process in terms of how tooling gets into their org. So one 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, uh, procurement process and the sign off that you'll have to get is probably going to be a pretty lengthy. 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 hundred K, maybe even some cases 250 K, 500 K contract, and you're just. is crazy. Like this company just came outta nowhere and is gonna 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 roadmap to going enterprise almost too quickly. 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. So you solved it for bp. Great. But what about the, I forget what the count is right now, but let's say 30 million developers that are in the world. What about the other, you know, 29.9 million that exist outside of bp? 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. Things that they're going to request and the amount of support they're going to need and the amount of time they're gonna suck from the team may actually detract from the business long term. Because what you need to do instead is focus on, vowing 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 off Zero's first customer was actually an insurance company that came in inbound for a 200 K contract. 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 lifecycle.

And as you can imagine, that was something that they had to balance of how do we make sure we're shipping the updates? How do we make sure we have the support and all of 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 cadence 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. You know, your time and focus on the majority of the roadmap. So that's a very important thing for people to, figure out is when to say no to early customers.

Jack: You'd be advising me heavily, like Jack, just this is not the right time, for your, you know, this is your first customer. Build a hosted version. As like our first, if like our open source project's 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: E, 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. And 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. 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? And so you may have this problem where you. Go into an area where either the customer's too advanced and not actually your, core persona. And then you'll, they're gonna give you product feedback, right? Like, that's what every customer does. Once they get in, they're gonna be like, oh yeah, this is amazing. What if you build this? And what if you build that? 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 gonna start getting feedback that's gonna 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, right? Like all those sort of things. How are you gonna build the community, if you spun up a discord, and now it's all BP React Native engineers, Right? Like, mean, maybe that's a good thing, 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: And so almost like just focus on the open source project at the beginning.

Shomik: In the beginning, like if you're open sourcing it, like. You've clearly thought about the reason to open source it, right? Like it, open sourcing is not easy. Like it takes a lot of effort, right? 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 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 develop. do I think they're responding fast enough? Do I think they're, do they care about their users? Right?

All that sort of stuff. And guess what, if the answer to that is no, well, I'm just gonna go move on to the next, product, right? So it's less so about, 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.

Lot of times we may start to think too much about the future when we just need to deal with the present. 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: Yeah, it is a, this is actually like really interesting cuz 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 and exact all the 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:

Yeah, when we back a founder. 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 stages and stuff. We've just seen the reps through different companies so many times.

There's tons of advisors out there, things like that, that you can figure it out. And by the. I can a hundred percent say whatever pricing you put will be wrong, wrong. Like I mean forever, pretty much. Like you'll 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, you helped me do something I was never able to do before. then you need that one user to tell five other. So that now you've got, so six users, and so you go from one to 10 to a hundred to a thousand, right? That's how you actually grow the of the product. The usage of the product, right?

And meanwhile, you're getting. Issue requests. You're getting feedback, 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 gonna use us for chat in mobile applications, right? Well now maybe all of a sudden you're seeing, you know, no, they actually love using it for, browser use cases. So I don't need to actually staff up an 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 base, , applications. Right. You know, 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 gonna 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? 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.

Jack: It's that kind of learning and just getting down the road and as getting as much information as you can.

Yeah.

Shomik: early is what I would say. That's the number one thing. , so the first, sales hire at Sneak, 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?

They're coming in with the 200 K contract. it worth it to have the 200 K contract or the 5K contract? The user feedback and the usage is going to be. 10 x faster, right? Because we just talked about how long it'll 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 right. Versus the 5K contract where, you're right in the hands of the customer from day zero. They're using you. They understand that the products early, so they're giving you quite feedback. The feedback cycles, , are very tight. And so now all of a sudden the compounding and the learning that you've done is. 10 x faster than the person who went with BP and is still trying to wait for them to even deploy it in the org.

Jack: It's very, valid point, but it's very hard to say no to that. , Yeah, as you said. Okay. 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.

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? And how we're 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: 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 zero, right? That affect the long-term outcomes of the business. For example, if you were seeing a slowdown. The question would be, okay, well the open source, uh, success to date, right, and now the hosted version is getting adopted and stuff, what's, 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 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, we get it. You know, this part is hard, but like, once you get through that step, like, trust me, it will, it'll solve all your problems, right. but at a certain point, either one, you don't have enough of those users that are still doing it, or two, you have to address the fundamental problem that's happening within the product.

Those are different things that you all have to diagnose, at different stages. 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 were just like, Hey, listen, this is what you know, I'm building. Uh, put me in touch with some. 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, I have a great customer base. This is awesome, right? And I, I have meaningful a r, but like, what's, what's gonna happen now? And so you took a top down approach. to something that may be necessitated much more of an end user bottoms up first approach, right? Which would be much more of focused on dev adoption, focused on, again, ease of use, community, content, right? All of those sort of things. So these are the things to balance, 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 brief community , to just get your initial users. if you haven't figured out, how you're going to continue to do that top town 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. Not many people reach that. Right? But now how do you grow from one to five to 10? you have no method of doing that unless like, okay, well now I gotta 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. In this case, the chat s d a would be Right. Any individual developer can go up and, and play with it. Versus if you have a like. I like to call it like lighter and heavier products, but it's kind of like, and 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 bottoms up, right?

Because an individual developer can't bring that into their org, you need. A top-down person to say, Hey, we're going to commit to doing this because it will 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?

Because you understand what the best way to interact with your, with your end customer and end user.

Jack: Yeah, I think it'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 cuz the kind of classic like dev tools is like, okay, it's got gotta be bottoms up cuz it's dev tool. But actually like there are cases, I think the one that you spoke about in your article was like CrowdStrike and that 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, I think it's a really good post that you did or link to it.

Shomik: I think in general, just thinking through your product, right? So if you're doing endpoint security, 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?

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, while any one person can be importing libraries or using whatever, and understand, okay, wow, there's an open source of vulnerability in this area.

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 kind of bad, right? Because it's, a lot of users are using it. 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 a, value from versusthe more like the endpoint security use case where that's a multi-player use case, right? So it just wouldn't make sense for a CrowdStrike to go and say, Hey, security engineer. Use our product. This is great, right? You need to go to the ciso, to the head of security, to the VP of engineering and say, I know this is a problem for you. 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. That that's not actually gonna help right at all. So I think understanding those early is is, is very important.

Jack: I think it's a really important one. I think that's all we've got time for, show mic. One new suggestion to the podcast from a listener, Joe, is that we should do like a T L D R, at the end. And I'd love to hear what , you are taken 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: 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? 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 the 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, 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 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: Thanks Schick, and thanks for joining and, thanks everyone for listening. And I think we're gonna be closing out of a little clip from, uh, Schick's new podcast called Software Snack Bites. So if you like the clip, go and uh, have a listen. It should be available on all good platforms.

Shomik: All right. Welcome to Software Snack Bites. I'm your host show, mcg gosh of BOLDstart Ventures where we partner with dev first and SaaS founders from the first line of code. Today we are excited to have Damien Schenkel on the pod. Damien is currently principal architect at Okta and was employee tenant O zero.

Welcome to the show, Damien. So why don't we just start off with your story, h how'd you get to become the principal architect at Okta? So, I, I joined Tzeo in, in 2014. I was finishing university back in Bono Aires. Before I was, I was doing consulting work for a company that did a lot of consulting project.