Dennis Mortensen: Build a Better Startup - Obsess Over the Pain, Not the Tech

Speaker A: Suggest and try to apply myself to just go about living your life. And once you spot something or spot somebody being in pain, you take note. Too many people too quickly over invest in their belief of the particular solution they have in mind. It will be, trust me, like, cut it very thin, like uncomfortably thin. That's certainly my, uh, like what other recommendation. And if you ask people if they feel uncomfortable and they're not, I don't think it's thin enough, they can close their eyes. Think about yesterday while at noon add a few JIRA tickets to go regenerate a set of screenshots.

Speaker B: Welcome to the eight Growth Ventures podcast where we uncover the stories, strategies and lessons that drive high growth companies. I'm your host, Hamlet Azarian. And today we're diving deep into the world of AI startups and scaling successful ventures with a guest who knows all about navigating these potters, Dennis Mortensen. Dennis is a serial entrepreneur, founder of multiple companies and AI visionary. You may know him best as the founder of Launch Brightly, uh, and also Xai, the AI powered personal assistant for scheduling meetings that redefine productivity. Today we'll be exploring lessons from his journey of building AI driven startups, scaling them and finding product market fit. Dennis, welcome to the podcast. Great to have you here.

Speaker A: Thanks much for having me. Appreciate it.

Speaker B: Dennis. I mean, before we even get started, man, uh, I was looking at your history and, and if you were a baseball player, you hit a couple of nice little singles doubles home runs along the way. Uh, I mean, I just want to set the stage for who we have on today. You've had four exits. Did I catch all of them? And you are.

Speaker A: Uh, so we've done a number of ventures, uh, over the years, sadly, because we're all getting older. But I'm on my sixth, uh, venture, uh, which is, uh, something we just got started on. Over the last year and a half of the prior five ones, we've been very fortunate. Lucky, good karma. A little bit of effort in seeing four exits and one that didn't turn out as we had hoped for. But then again, you almost have to find some sort of equilibrium, right? For where if they all fail, you're either not good or too ambitious. If they all succeed, you're probably not ambitious enough. Or somehow you're playing in a place for where wealth succeed is perhaps not the right kind of definition of what happened here. So I like to tell myself when I go to sleep that I found a reasonably okay equilibrium of being ambitious, not crazy, but somehow, uh, get started on Making some good products, see people kind of fall in love and get to some sort of exit. And we spent about five years on average on each and uh, it's been a fantastic journey. Uh, I've certainly been having a ton of fun doing it.

Speaker B: Amazing. I'm really excited for the incredible wisdom that you've obviously gained and, and the traction you've been able to share today with the audience. Uh, let's start about a conversation you hear around AI which is obviously what you're predominantly focused on with your current company launch brightly. What um is the biggest misconception about AI driven startups? And how should founders and VCs set realistic expectations when scaling them?

Speaker A: That's a big question. If I had the answer that will be true and honest forever, then perhaps I should be an investor versus an um, entrepreneur. One thing that might be a little silly certainly if I today Jan 2025 told you or a bunch of friends that I'm about to start an Internet company, that wouldn't mean anything. That meant something in the mid-90s that you could tell people, well I'm about to jump into this new particular vertical and will probably classify it as an Internet company today. You could probably tell people with a reason. We kind of straight faced that I'm about to make an AI company. I do think though if you go a few steps into the future that's not going to mean anything. So I think to kind of come back to kind of answer your question. The misconception if anything, is to believe that you are in a particular space. It's just that we become much better at making a whole host of predictions at this very moment in time. But that doesn't really change the fact that if you want to do a venture, what you should get married to is not some particular technology. It's a unique pain point for you seeing something in the universe that doesn't seem right and you want to correct it. And if you can correct it, whether that be the self driving car or automated screenshots as I work on or a thousand other things, figure out what that pain is and be happy. If somebody can have current technology can kind of make the solution even better. But I wouldn't kind of jump into a pool, put an AI label on myself and say I'm in this particular space without having some real honest, tangible customer pain you can last onto and not just say hey sure, we can make these images, make these predictions, craft this language, do this synthetic voicing, whatever it might be. That's all just a little Uninteresting.

Speaker B: I love that. To summarize, it's not use the technology to go find a pain point. Know what, the pain point that hasn't been addressed yet. And even better, if there's a technological solution today, use that. Because that's what's going to really set the edge for you to be able to solve it. Is that, is that exactly it?

Speaker A: Right. Where you can fall in love with many things that as you get started on a new venture and uh, there's the original pain, then there's the idea of your first way of solving it. A lot of people will fall in love with this because you're a technologist, you're a geek, you hack away, you love your laptop, uh, you pushing some code. And that's all kind of very romantic, but this part you shouldn't be in love with. You should be very unemotional and willing to kind of discard the whole thing. And I'm not talking about the idea of you needing to kind of pivot seven times over in your venture. It should just be a setting where these people had uh, this pain. It was true and they agreed. I tried to solve it in one way, uh, that didn't work, but the pain is still true. Well then I'll try in another way. And, and it certainly great if there's some new found technology that could allow resolve this. It might even just be that it was not even solvable for decades, but now we can kind of revisit it. So I just keep coming back to the fact that if I speak to somebody where their first presentation is not one of a set of people who are in pain which they think they can help. Sure. I can also get excited, I'm a kid like everybody else. If they tell me about some sexy kind of set of predictions that they're about to make that we couldn't do five years ago or 10 years ago, hey, that's cool. But this though, if the conversation is void of this particular pain, I'm rather skeptical of being able to see any success of that.

Speaker B: I love that. Let's talk about the pain that you're trying to solve today with launch. Brightly, uh, can you tell us how you first, uh, were 100% sure that there is a real true pain point here and then. And kind of let's go through the formulation of this because this, this isn't your first time at the rodeo anymore. Right. Like now, now you've gone through this a few times over at what is the. What is a skill that you feel that you guys have developed as a founding team that can really help identify pain points and really come up with a solution that nobody else has so far today.

Speaker A: So if you and me want to team up and I'm very easy to persuade, I spent my whole life, uh, doing entrepreneurial endeavors, so. So if you kind of turn up at my apartment with a laptop and a couple of Diet cokes and a pizza, I'm up for it. However, that particular tactic of you and me standing by a whiteboard trying to come up with good ideas is probably the worst way you can come up with good ideas. I said, it's very easy to kind of fall in love with kind of all sorts of things that you read on the Internet over the last kind of week and kind of extrapolate that into a future. And perhaps that could be a business. What I do suggest and try to apply myself, just go about living your life. And once you spot something or spot somebody being in pain, you take note. That doesn't mean that there's a solution. There should be a solution. Or it might just be that there's only one person in pain here, which is yourself. But that's rarely the case. This particular pain point that we spotted, which is always I. It's not always the case, but it's always nice. It's one which we had ourselves. Because then at least the initial validation for whether, hey, I did 40 interviews, what I've distilled seems to be a true and honest pain. Perhaps it's not. Perhaps I just want it to be because I'm excited. No, if you have it yourself, then you have to close your eyes and say, do I like this? Nah, I fucking hate it. And what I hated, which I've done it across all my ventures, which have all been in software, is that you make some product, you push it to market, you have a little bit of success, and now you have customers who end up, uh, needing support. As in just as a sidebar. There's no software product, no app, no destination, which is so easy, so intuitive, so obvious that there's exactly zero percent support. I say that's just no app. Where that exists, it might be they have shitty support, no support, self serve only. That doesn't matter. It just means that I tried to do something in your app and I couldn't do it. Now in that setting, which is true for 100% of all software being pushed to market, some are easier to use, certainly on the B2C side. Some are more complex to use often on the B2B side. But once pushed to market, the way we tend to solve it, certainly over the last three decades or so, is that we assemble a help center. Here's 300 some odd articles that explain. Here's how to set up two factor authentication, here's how you do a segmentation, here's how you sort the table, here's how you add a user, and so on and so forth. In each one of those articles there'll be some text and it'll be choked full of product screenshots. I said this is what it looks like in the application itself. Those screenshots I will guarantee you in any help article that you read this week or next week will be outdated.

Speaker B: Why?

Speaker A: Because we had tremendous progress on the engineering side, as in any junior engineer on any piece of software will probably put something to production in the next hour. We have all this stuff velocity on how easy and protective it is to push new things to production. We're not sending things out on CDs once a year. No, we're doing it 20 times a day on some SaaS app. That means the app moves forward at rapid pace, but these static articles with these static images stay constant. We've then made this platform where you can set up automation recipes where, hey, I want you to log into my application, go through all these features, put them into this particular state, take a screenshot, style it, annotate it so that those who kind of consume it later understand what they should look at. Log into my standdesk intercom, what have you. Scan all my articles, see if any of the imagery is out of date. If it is, go sync it with your image. Give me that as an audit. Do it every Sunday night or every other night or once a month so that I don't have to do it. And, uh, the funny thing here is that today there's people for where this is their job, but it's not a job where they say, oh, awesome, uh, Friday. I'm looking forward to it. Perhaps I'm going to sit in and do some of this on Saturday. No, it's one of those little chores where I'd rather do all the other things. If I can escape this, that'll be awesome. So automated product screenshots for people in CEX so they don't have to do it, to make sure all of the help articles are always up to date. That's us.

Speaker B: Amazing. I love it. So the pain you've identified, if I can summarize, this is a pain that is a natural occurrence that's happening because of the speed of software development and the innovation cycle that occurs with every agile SaaS software or any software in general. Right. But the reality is the current solution is for people to understand how to use the products is outdated because meaning I would have created a help desk article, but the flow has changed or there's a whole new functionality that has been introduced.

Speaker A: It's not a drop down now it's a button. Now it's checkboxes in this model and moved over to the other modal, it's not under this menu item, it's on another menu item. We can do four things here. I used to be able to do two things. Well, the app move forward is living in somewhat the future compared to the help desk garden.

Speaker B: Yeah. And now you've automated that. Where in the past it would be a CS support person or even someone a marketer or even an insurance sometimes that. So it was the job to be done, but it wasn't the desired job to be done that needed to be updated and refreshed. So you guys are now be able to capture that and fix the imagery. Are you fixing the content as well and the stuff like that?

Speaker A: We're focused today on the imagery itself, given that is the most kind of time consuming part. And it is wonderful where we didn't really see this. If you go back a few decades where the release cycle of software was kind of more staggered, monthly, quarterly, half yearly. Now, as you just described, we push to production two dozen times a day. And that means if we uh, speak to anybody at Slack or Dropbox or any kind of, we're talking hundreds of times a day, small little changes. But why would you not want the very kind of support material that you tried not to be up to date with the application that you're trying to support? So it's just one of those guys very thin sliver where people would say, yeah, I'll buy that, Dennis. Is that really a pain? Well, uh, if it's not uh, up to date, what happens? Uh, worst case scenario, I can't figure it out and I just don't do it. I said, you don't extract the value from my application that you should. And you're now of a higher likelihood of at some point churning. You don't churn because of one shitty sport article. You turn because of a bucket of disappointment. Well, at some point that bucket is full. Or you say, you know what? I need the solve. You put in a ticket. It's just a ticket. Yeah, but anybody who gets 80,000 tickets, they can cut that down to 60,000. I have a real amount of money saved on something. For me, it's not even like, oh, they loved speaking to me. No, they don't. I don't want to speak to support. I actually don't want to have support at all. I just want my problem solved. And I couldn't figure it out because you're shitty articles. Now I can kind of decrease some of that. Then of course, that's all the kind of raw ri on just having these people do this particular job where, well, it's only 10 minutes for every screenshot. Yeah, but you got a thousand. Anything which you multiply by 1000 turns into real money at some point. So yes, hyper focused on this. I can tell you, uh, where I'd like to go in the future, but let's just leave it at that.

Speaker B: Yeah, so I love that. I mean, you jumped into two or three different value propositions of the pain point that you're trying to solve to. Um, but let's kind of take the conversation a little bit if we can, to just in general, how do founders balance? Because you know, obviously here what you're trying to do is you have a really good utility for vision AI, it seems like. Right. And so there's a technical solution that you're applying to another area and you've been able to figure out a way of solving this pain point. Uh, how would, what recommendation would you give to founders to start thinking this way a little bit more? Right. Like, hey, if you see a pain point, how do you find the right technical tool set to be able to use, to be able to solve for it? And how do you then go from there to be fully committed the way you guys are? You guys, uh, at this point are committed to the level of like this pain point is big enough that we're all in.

Speaker A: We're building two outcomes here. Either we win or we die trying. And we're probably going to die trying. And that's okay. It's all part of the game. But we're certainly leaning in on this particular pain, which we have confirmed to be true. So to answer your question, I do think, uh, that too many people too quickly over invest in their belief of the particular solution they have in mind. I would much rather in much simpler ways, even manually over invest because there's very little penalty in over investing, in trying to confirm that the pain is true and honest. That means is there anything which I can do to speak to more people, to present them more material to get through a set of obstacles to know for sure where I can state as a fact that this is a pain. And many times that doesn't really require you writing any code or pushing any software to production. It requires many other things, which many, certainly technical founders are, uh, uncomfortable doing, which is getting very close and very intimate with a set of users to get to that point where you can state as a fact, certainly as you kind of choose to see in the universe, that this is a pain. Now, that will then allow you to be very confident, as in, I'm going to get married to this. I do have some idea. I think you shouldn't really extract the solution from the customer. You should extract the confirmation that it's a pain that I have this way of tackling. But if that doesn't work, I'm not even going to be sad. It doesn't really matter. Yes, there's going to be some throwaway code, then we're just going to try to tackle from over here, over here. But that though, that's where I would invest all my time and energy.

Speaker B: I love that. Uh, it's the customer discovery process, right? It's the core customer discovery process process. Really understanding the pain point and then not overselling the solution, but really digging into the major pain is kind of what you're addressing here, Even to the

Speaker A: point where don't even spend too much time talking about the solution, just always talk about the pain. I'll give you a good example. In our prior adventure, we did predictive analytics for media, trying to figure out what story CNN should carry on their homepage, in what position, and for how long. Think of it as an AI editor. Uh, we wouldn't call it that. But conceptually, as if somebody needs to decide what story goes where for how long, and wants to kill it. What we're replacing with very standard. We moved in, like, moved in with the New York Daily News. I sat next to the editor for, uh, the New York Daily News for a year. Not just to kind of. Ah, yes, I've done a couple of interviews. I chatted with a couple of folks, I think understanding it. No, me, Scott, like him shouting at me for 12 months, um, straight until I really understood it. Like, not as in, yeah, I got a good understanding. I read a couple of blog posts here. No, no, I sat next to him day and night for a year straight. And I'm not saying that's the answer. I'm just saying that there's very little chance that you're going to pay a penalty for over investing. And you Understanding the particular pain point you're trying to solve.

Speaker B: I love that. So almost better to over invest in really understanding the pain versus trying to get some version of a solution out. Right? Like don't even bother building the MVP if you don't even understand the pain yet or what you're going after.

Speaker A: Exactly. I think that's actually uh, nothing wrong in spending four months trying to tease out that pain until you really believe it's true and then finding out halfway there. You know what, I uh, wanted it to be a pain. I find the whole space interesting. I think we can write some software, but everybody I speak to, I can't get them to the same conclusion. I should walk away. And you walking away, that is the best way to kind of confirm that that's not the pool you jump into at this particular point in time. I might revisit it. I might come back in a couple of years. And just as a side note, I'm not uh, allergic to writing some kind of uh, proof of concept or a kind of half hacked kind of mvp. I did the same myself for launch brightly, but I do it late sometimes. The only way I can get an answer is when to see something. Fair enough. Then you kind of put that in place. Uh, I'll be kind of skeptical if you tell me that you couldn't mock that up in Figma or you couldn't do a couple of things on a whiteboard for him to also kind of see, uh, what you see to get to the same conversations. But sure, sometimes you have to kind of make some version of an mvp, but try to see if you can't do it without it would be my recommendation.

Speaker B: Uh, would you say this is one of the keys to having so many exited multiple startups is that you spent over invested here and this is one of the biggest things that you've kind of figured out along the way. Or is there another lesson or another key here?

Speaker A: If I was gonna uh, put a few stickers on a board on what I thought would be some of my few superpowers, that would be one of them. Because you haven't seen some of the ideas that we killed before they turned into adventure, which is that we just over invested in the research phase to come to the conclusion that yeah, it would have been awesome, it would have been fucking sexy man. But you know what? We're not going to do it. Those were the four best months invested where it didn't turn into four years. Right? Then you raise a little bit of capital, you assemble a team half of a customer, the mice they put. And all of a sudden you spent three years on something that you didn't even spend any time on. We just.

Speaker B: I love that. Uh, yeah, you're no longer building this sort of, like, zombie startup where you can get it to a state, but you can't get it past that state.

Speaker A: You know what? Yeah, we're not dying, but I'm not sure we're kind of alive either. Right?

Speaker B: You're not alive. You're not dead. You're kind of stuck in this, uh, I call the zombie startup. They're, like, stuck in this, like, middle plateau and they're not moving forward. And so what I'm hearing from you is the going to. One real thing is understanding the pain, not the solution. Right. So that. That's one really important lesson that clearly has led. Um. Is there another one that you. You have learned over the years that you're like, man, I wish more I did. I wish I did this more earlier. I'm doing it now. But is there another lesson like that that you've kind of learned over the years?

Speaker A: I'll give you two out of sheer entrepreneurial excitement. Um, uh, the first one being try to cut a solution slice so thin that, uh, none of your friends can see this as a, uh, company, or none of your friends, investors, possible co founders, can see this as a company. Certainly could barely see this a product. Perhaps it's a feature, Denise, in somebody else's product. I cut it so thin that it feels super uncomfortable because I will guarantee you it is always much, much fatter that, uh, you and the people which you spoke to about this particular idea kind of saw it. So really cut it thin. As in there's two stories here, right, where there's a story, which you rarely hear, if ever, of this particular person who became extremely good at a small thing and died because of it, or this person who was kind of okay at a lot of things, who survived. Right. Of those two stories, you try to be the guy who went aggressively deep. Like, fuck. I think they are the experts. It's very small, though. But they are fucking killing it. That this, like, one thing. If you can kill it at one thing, expanding into kind of adjacent areas, that's much, much easier than you having, like, this thin slice on, um, top where you not really good at much. So I try really to cut that slice so thin that when I'm in the lift on the way down a little bit later today and somebody asked me, so what are you working on days? Yeah, I'm making some automated PNGs. Is that a company? It will be. It will be. Trust me. Like, but you're just taking screenshots. That can't be it. It will be. Trust me. Like, cut it very thin. Like uncomfortably thin. That's certainly my uh, one other recommendation. And if you ask people if they feel uncomfortable and they're not, I don't think it's thin enough. That's the one. The other one I would add to the list, uh, of three items we could uh, put in the notes here is almost obvious, but having confirmed with yourself, uh, is what particular challenge is this venture? It could be many things, right. But it's certainly something that tends to land in one or two buckets. Is this a research and or technology challenge? One bucket and. Or a sales and modeling challenge? So say the self driving car. I actually don't think that's a sales and marketing challenge. I actually don't think you read any article where people question the idea of whether we need it. It's more one of when we get it, we'll just take it. Right? As in it sold itself. It's not a sales and marketing challenge. Then you can take something like um, Airbnb. That's not a technology challenge. That's a directory of other people renting, uh, out, uh, rooms in their apartments. Sure, you and me can build that today. That's a sales and marketing challenge. Where can I somehow present a story where that will be accepted? So you need to figure out which one of these are the primary challenges. I'm not saying it's ones and zeros, but which one is it? Because the team you assemble and the way you uh, build that company will differ. And uh, you can see typically what type of company you are, whether you are in one of the other bucket but you not knowing it and you're not assembling the team around the fact that you're in one of the. Either can somehow add an unfortunate amount of friction that you.

Speaker B: Oh my, I love this. This is, this is a great insight. So, so what is the real problem here for adoption, if I'm hearing you correctly, right? Like, like uh, if something like the self driving car is the problem for adoption is not people are against this. It's just, hey, is the technology going to be solved and is it going to be safe enough once it's solved that who's not going to want this, right? You don't need to sell this concept. You don't need to market this concept. Once you've solved the technological Breakthroughs and you've made it safe enough. And who knows, Tesla might have recently with their new release of that. Right. But once you've gotten it to that level, then it becomes a, uh, no brainer. People are going to adopt to it, people are going to take over. While on the other hand, like, what you were sharing here with Airbnb is, the technical challenge wasn't that complicated to solve per se, but it was really solving the whole notion of having a stranger stay at your place. Like, are you comfortable with having someone come sleep on your couch or stay at your home or yet alone? Are you comfortable with you going sleeping at someone else's home as well, too? Right. On the dual side of that and over time as how they were able to combat that and, and make it almost like an alternative to renting a hotel or anything. Anything of that sort of.

Speaker A: Very well. I'm, uh, super impressed. I'm just saying that they probably also knew early on that we are in this. They might call it something else. Uh, but I think it's a good concept. Suddenly, even if you're on one of your first ventures or your very first venture, have a clear idea of, am I in one or the other, and if I know which one I'm in, what type of team do I assemble, how do I present this, how do we get to the other side? Uh, that makes for, um, a lot of different kind of, uh, discussions and debates and, uh, conclusions.

Speaker B: Yeah, let's talk about that. Right. Let's talk about a little bit. You've obviously done well assembling your teams, and it seems like this is one of the lessons you've kind of taken away from that. Uh, what are the things that founders who are building because we're far away from the solo founder being able to do everything on their own. As much as we want to idealize and dream that this is a team sport, at the end of the day, what are the ways that you've at least over the years done a great job of forming teams and gotten everyone on board and gotten everyone bought into the same vision and the same problem to solve. What are some lessons around that that you could hopefully share?

Speaker A: Um, it's very nice if you've had some sort of success in the past where you can carry over good people to the next thing. But let's leave that aside. There's some sort of luxury that you might be able to assemble over a long period of time. Let's paint the picture of the initial, uh, start where, well, how do I connect with one or more co founders, I do think there's a few tricks in a positive way or processes, that's a better word, uh, if we go McKinsey and this to go apply. One thing uh, I found is that I need to put something in place for where there's real aggressive obstacles for them to join so that if they do join, there's me knowing with some level of certainty that they're not going to quit. Everybody can and will quit over time simply because it's so hard. Some will stay towards the end. But as a co founder, uh, at least the idea should be that we're the only people who can't quit. We can ride the whole thing to a point where we die, as in it didn't work out and that'll be it. And we'll thank everybody uh, very much for having participated. But how do we do that? And uh, I'll give you some of the obstacles uh, that I've used, uh, that seem uh, silly but have certainly worked. One is that uh, I like the idea uh, of seeing them quit a job really getting funding and go from pick some high level of salary to some very low level of salary. As in that's a picture, you can pick other little challenges, but there's a picture of a person where there's no guarantee that we can raise any additional capital. But I'm willing to quit whatever I'm working on some job, go work here for next to nothing, uh, and be confident that you, me, you, me and her can somehow assemble enough energy to raise some amount of capital. Not necessarily to increase my salary, but to make this whole thing not die that I like is way more difficult. If you say I've had a little bit of success, you go raise some capital, you fund it yourself and then some co founder joins. How do I know that they have enough resilience to not quit when it gets hard? And it will get hard. I'll give you another one which is that uh, I've always liked for each uh, of my co founders sidebar. Uh, in any co founding setting you're rarely on equal footing. There's typically one will be the initial catalyst either on idea market pain, sheer uh, excitement will kind of be the one who kind of just brings this uh, to bear. One thing I like is that for them to buy with money their founding shares, we don't need that particular, uh, um, small pot of money to make this succeed. It's not a funding ground. No, what it is is a sacrifice, uh, of you going to citibank with your debit card, take out, pick some portion of money. I'll give you a good example here. In, uh, one of my prior ventures, a young, two years out of engineering school, first venture, wanted to join, had 10k in savings, took out 5k in savings, uh, from that and bought those founder shares. We're not going to live or die on 5k. Uh, that's going to be whatever first month on AWS bills. But you know what it's going to do? It's going to have them be very diligent, like aggressively diligent on how we invest time and money during this, uh, venture. This particular individual and I fucking liked it would go bananas when other engineers would just spin up instances on Amazon, leave them over the weekend, continue their experiment on Monday. Like, what the fuck? Like you are pissing away my money. Like, I went to Citibank on my debit card, took out, um, this money and you just leave that instance up. Not cool. Like you can assemble a set of emotions by forcing them to do that at whatever range that is kind of befitting for that, uh, individual that I like. And it worked very well. And I've had people where that's just not an option. Well, then, uh, there's things which I don't understand. As in, you must believe. If you don't believe, then you wouldn't do it. And if you don't believe, well, then we shouldn't team up. This is good. We're both equally happy now. I thought I saw something, but you're right, it's not for you. So find your own obstacles. Uh, but I do think you need to have obstacles that make it very hard for people to say yes versus the opposite, where you have appetizers laying around that make it very easy for them to say yes. Because what you don't want is them quitting 11 months in. You want them to quit before they got started.

Speaker B: Uh, I love that what I'm hearing from you is some level of commitment, right? So commitment can be.

Speaker A: But you can't ask about it. You have as in are you committed?

Speaker B: Yeah, no, no. But it actually be through action. Right. So the commitment level here is, uh, buying founder shares was one example, right, where they're putting some capital into, into it. It's minor capital in the grand scheme of things, of what the startup will, one successful raise. But it is enough that shows that, hey, I, uh, have capital in here, you have capital in here. And we're both focused on trying to solve this. And that naturally brings the Ownership mentality, right? It's like, man, that's, that's our $50,000 that we got riding on this thing. Let's see where this goes. And the other one, which was also very interesting is the commitment of like, hey, you have a six figure salary, you know, you're making $200,000 a year, you're ready, you're ready to leave all that, the, the health care plan, all the, everything you got. And you're ready to not only put some capital in, but also be understanding that this, you know, we might be making nothing. We might make 20, 30, 40,000 for a while until we grow out of this stage and get to the next stage. And it seems like the combination of those two things are really producing the resilience factor that is, we all know no startup is up to the right. That just never happens. It's a, it's a roller coaster, right? You go up, you go down, especially in the early days, more down and up sometimes. And to be able to have that resiliency, to be able to muster through those, uh, really hard initial months and years, to be able to survive that together as a group and be able to take that. Am I kind of understanding this correctly or.

Speaker A: You nailed it. I'll give you one that we used for early employees, not founders. Um, we had many, uh, but, uh, one that really worked as a very strong obstacle was that we had mandatory six days a week until we hit a certain, uh, metric that mattered to the business that kind of signified we were slightly safer territory or the waters were not as dangerous as before. And asking anybody, myself included, to do six days a week. I got a wife, I got kids, I got a family, I got a nice apartment, I got Chelsea Football Club to watch on Saturdays. But we did it, uh, I think for VR. Ah, we did it for perhaps 13, 14 months for X AI, I think it turned out to be like 18 months. Like, it's not like, oh, yeah, I enjoyed those Saturdays. It's the worst. Like, great. We shook hands on we need to cross this inflation. But when we crossed that inflection point or the bond, we had a laugh. But then we also instilled the idea of who we wanted to be, uh, in all of the others that kind of came along and plenty of people said, denis, I am not quitting my job at Google to go work for less, uh, for you and work on Saturdays. I think not. And it's cool, we might even meet up later, whatever. Series B and whole environment have kind of changed into something a Little bit more kind of normal. But it was a good kind of uh, optical for early employees as well.

Speaker B: I love that too, by the way. So it also puts everyone on equal playing field at this point. Right. Like I can only imagine. I know people don't like working on that, that six day per se, but I'm pretty sure the cumulative effect of that like over two months, three months, four months, the productivity gains that you guys are getting and the clarity and the focus, I'm sure was astronomical. Probably one of the reasons to be able to push through some of these things.

Speaker A: Yeah, it's not even the extra day itself. It's the fact that there's some metric and it doesn't even matter. It just needs to be directionally correct that we want to achieve faster. But you know what the reward is? Not a few extra monies. Sure. I can see us being slightly safer waters with the fact that I can kill a Saturday if we reach this. So I'm just going to lean in. So my Wednesday is even better now because I want to kill Saturday. Right. So it worked very well.

Speaker B: Uh, talk about one metric that matters or one goal that matters. Keeping everyone organized around that. Uh, I love that. So a lot of things that you've been able to do and you kind of hinted to a little bit here is figuring out a pricing model that's semi related to value based pricing or some type of value value extraction. Can you talk a little bit about that and share some insights around that?

Speaker A: It is not easy and I'm certainly not suggesting that we always uh, got it right to find first your pricing, uh, metric and then the actual pricing attached to that particular. I do think the most important thing is to find a metric that you price against. Then you could do all sorts of testing against that particular pricing metric to kind of figure out where on the curve you want to set. And I've certainly seen plenty of people being a little too inward on trying to come up with that pricing metric. Usually, uh, something that uh, is attached to a cost setting, uh, which is often okay, but sometimes not so much. I tend to be eager to find a pricing metric where the customer has a very easy way to understand why they are paying against this particular metric. Then sometimes it doesn't even matter whether it's premium pricing as long as they understand why am I paying this? If you take, uh, certain settings, uh, it might be easier to understand why I'm paying on a per se basis. In some SaaS solution. I say, ah, I see why we're paying for Every additional person we include into this subscription. Or I see why for every additional Lambda call I do on aws, I need to kind of pay for that. Or I see why for every kind of consumption of this particular thing with the providers, I have to pay. But I think it needs to be something for where the customer can clearly, intimately understand why I am paying for this. I'm okay paying, uh, $10, $12, $100, $1,000, but I need to really understand it. Once they lose that grip with what I am paying for, it's not even a matter of the amount. It's a matter of I'm uncomfortable paying this. It feels like, uh, any opportunity I have, I would like to replace it. So that's certainly something. And it perhaps kind of circles all the way back to the beginning of our chat here for where you need to have this very intimate relationship with the customer and their particular pain. And the solution kind, uh, of is attached to that and the way you price it. Here we take our current venture. Uh, the pricing metric that we picked is on a per screenshot generated. Why they can close their eyes. Think about yesterday. Well, at noon, I had a few JIRA tickets to go regenerate a set of screenshots. I logged into the demo account, I found the page, put into the right state, command shift4, rectangle, took screenshot, logged into kind of, uh, canva, did a few annotations, saved it on my desktop, logged into Zendesk, found the four articles, replaced the image. Like, I, uh, have this visualized, as in, ah, so this is what you're doing for me and I have to just pay you a few monies. I'm getting paid $65 an hour. It looks like for a few bucks, you can do it for me like this. Just I can connect the dots.

Speaker B: I love that, like, directly tied to the pain is the price. I love that. I love that a lot.

Speaker A: So I'm certainly a fan of that versus the whole. I could also, if I was really kind of attached to, um, my cost structure. I'm really, if I'm honest, I'm spinning up these machines, uh, in the cloud to generate a screenshot. They probably run for, what, somewhere between 100 to 150 seconds, I close it down. So I should really just price on a amount of compute seconds or compute minutes. That is my real cost. And some screenshots are very elaborate, or some applications I take screenshots of are just very slow. I have to keep these instances running more than for others. That very kind of rapid Infrastructure which I can take faster screenshots against, like, well, sure I could, but if I told you, yeah, you're going to pay on a, uh, kind of compute per, uh, minute. You're, uh, going to pay 40 cents. Okay. I'll look forward to the invoice. Uh, it increased last month. Why, like, no relationship. I'm just very uncomfortable kind of bringing that to market. Even if it's making a ton of sense on my end. Like, yeah, I'm just adding 20% on top of my compute cost. That's kind of my margin or whatever I choose to pick. Right. So I pick something else, something which they understand and they relate to. And my margin will be elastic from customer to customer.

Speaker B: Perfect. Dennis, this has been an incredible conversation filled with a lot of incredible insights and lessons for our, uh, audience of growth leaders and VCs listening in before we wrap up. And I have to ask this because we're recording this on the week that Deepseek has shaken the market a little bit, let's say, and has come out, uh, released on Monday. Today our recording is on a Friday. So. So I'm kind of giving context to the people listening in. What, what is your thoughts on this? I, uh, mean, uh, I, I've been asking everyone that's been on the podcast this week about this. I'm kind of curious to hear your, your own take. What does this mean in the state of both model training as well as what, what, what the, uh, what in general this means in the landscape of technology? Uh, why did it catch everyone so much by surprise?

Speaker A: It seems to me, certainly looking from the outside in that we chose as an industry at large, to focus on what we could extract from this thing that we learned that, uh, more data in yields, uh, new exciting outputs that we couldn't really predict in the past. It's not like we haven't had neural networks. We've had that, uh, forever. But somehow there's the fact that you can cross an inflection point and out comes a set of things that we didn't expect. We haven't exhausted that. Well, meaning that we're still trying to pull out, uh, new things from that particular. Well, it seems to me that it was somewhat inevitable that at some point we're going to start optimizing on what we have now. These folks, given their particular situation and not perhaps being able to get their hands on enough GPUs, uh, or enough new GPUs, just kind of jumped to that particular moment, uh, because it was a force function of where they're located. Okay, nice. I think we would have reached that anyway at some point. It was just not what we wanted to or uh, decided to focus on. As in there's so many new things and there's enough capital where we haven't reinforced to say well you must do this, you only have N dollars to spend. It seems like we have infinite N dollars to spend. That's going to change, uh, but it seems inevitable. So then having done some essentially cost resource optimization, while the existing kind of players would have done the same, if not next year, then the year after or the year after, but it would have arrived or on whatever vector uh you look at here that was just a forcing function given the political climate that had these people do that right away. And I think they've applied some interesting kind of uh, ideas to kind of figure out how to use less resources to spit out something which is as qualified, perhaps even on someplace uh, on par with uh, what we have on models that are way more expensive that you can put in place. But I don't think it really changes the path we're on. It might make for one or two uncomfortable board meetings in some settings where hey, it will also be nice if you guys could accelerate this path. Less new features, a uh, bit more resource optimization. But I don't think that was the play we were looking at in our current setting where there's so much we can do. We should try to do that as fast as we can be first figure out what we can capture and then we'll kind of optimize later which is generally how you do many things in software. So I'm not uh, I don't think it changes the picture really. I do think yes, perhaps a couple of meetings will be a little uncomfortable in Q2 or Q3 for some people where their particular investors don't have kind of infinite capital and they'll be forced to kind of do some of the same or similar type optimizations.

Speaker B: Perfect. Thanks for sharing your thoughts on that. Thank you again Dennis uh, for sharing all of your experience and wisdom. Um, uh, for our listeners if you want to dive deeper into AI applications or hear more from Dennis, uh, check out his past venture or Paul's latest work. What's the best place? LinkedIn or, or your website or where should we go?

Speaker A: Everywhere on the Internet under uh so uh, feel free to kind of push uh back or even call bullshit on some things which I said today. They might not be true disclaimer. But I certainly believe in them, uh, myself But I'M happy to discuss or debate, uh, anything. LinkedIn is something where I think spend more of my time, uh, outside of, uh, just working on product.

Speaker B: Perfect. We'll make sure we leave that in the show notes. Uh, if you've enjoyed this episode, please subscribe, leave a review and share it with your fellow growth leaders. Stay tuned for more conversations on scaling, innovation and growth. Until next time, I'm Hamlet Azarian. Thanks for listening to 8 Growth Ventures podcast.