AA147 - Creating and Launching New Software Products (0 to 1)

, We're talking about new products today. We're talking about creating new products. Or, as some people , Online, say zero to one, zero to one. Wow. That's an acceleration right there. Zero to one. Yeah. Well, this is going to be a good podcast for anybody who's interested in product or not, right? Because everyone's interested. I mean, if you're an agile coach coaching product is part of your job, right? And, and invariably, you have to say itself invariably. Invariably, you'll approach a point in your career where you'll be developing a new product. Something that didn't exist before, something that's not just maintaining what was there, something that is truly new. if you have a executive, you have a leadership direct your product. Doesn't matter who it is. If somebody comes to you and says, okay, oh, and we got this great new idea for a product we want to launch from the ground up. And now we think you're the guy to do it. All right. Let's start with the gut check. The gut check is run. Don't walk. No, no, seriously, though, they're telling you that there's a products that they need. And so immediately I'd be going, Hey, okay, let's think about this a little more. Right. I feel that's the way a lot of these things started is somebody runs some, somebody with some, either some money, some budget, or somebody high up in the organization will run in and say, I got this great new idea. I was in the shower. I had this great new idea, or I was at this customer. I had this great new idea, or actually, you know what, to be fair sales. We'll do this a lot. I was talking to this customer, they said they got this great they said they got this big problem and if we can solve it, they'll give us their business and they'll run in with this, this, we gotta develop a new application to fit this. I have a lot more time for that approach when sales comes in. As opposed to the executive just came back from a conference and talked to a bunch of people that are doing stuff and he feels you know, left out or full or whatever. Right. There's many different ways that you could be alerted, apprised, ordered to create a new product, what should you be looking for? What should you be watching out for? And yeah, all of that basically. Let's start with a question that I will ask in a hundred percent of those situations every single time. Sometimes, which gets me in trouble, which is, what is the problem here that you are trying to solve? Or, what is the problem here that the customer is trying to solve, or that you're trying to solve on behalf of the customer, etc. etc. Regardless, I will ask, what is, what problem are we trying to solve? I will ask for it to be an individual problem. What singular problem are we trying to solve? Yeah. So there's a couple of things you kind of mixed in there, right? One is absolutely, what problem are we trying to solve? And it isn't just a smorgasbord or a bullet list of here are all things all and sundry for everybody, right? No. So I think it's critical we separate those out. What problem? And it is a singular. What problem? Not what problems? Because now you're assuming that a solution fits multiple problems. Big, big red flag right there. So yes, what problem? And I would say at that point, you've got to validate the why. Why are you trying to solve the problem? Is it a real problem? How big is the problem? Is it worth chasing? Right. So there's so many other questions that fall out of that. You know, how big is the market? Are we the right people to come up with a solution for this? Yeah. What's our competition, right? What will the customer pay? What's the appetite for this? How will we know we've succeeded? I mean, there's this a thousand questions that. Come to mind at that point. Unfortunately, 999 of those are ignored most of the time. It's like, yes sir, that's the answer. Right, and that is not how to go ahead. the larger the company, the less leverage you have to ask those questions and, and basically delay the beginning of development until you've started with those questions. Like I guess the, the first thing for me when someone brings me an idea or, it could even be me seeing the idea. The first thing that I want to do is go out and run that MVP. There's some things that need to be done before the MVP is run. the concept of product market fit exists for a reason. Like I don't even know what, what, what. Market we're trying to target with this. What, what, what audience like if we say, well, what is a market? These are meaningless terms, Brian. Oh stop with your word salad. Okay, valid critique, but Let's just let's define a market. It's just a group of people. So can we list those people by name can we put their names on a wall and be like these are the people we're trying to sell to Yeah. And do they share the same pain point or pain points, right? Right. Because maybe you have, maybe there's an opportunity here to say, let's funnel in on a singular pain point and deliver an MVP that fits that as opposed to You know, more of a generalized solution in the hope that it sticks, right? That, that's not a strategy. No, I don't think so either. And that this, this is, this is wrapped up with your, your go to market as well. Like your traditional marketing, go to market type of activities. But to, to stick on value. How do we know the customers are going to get value out of it? We're going to stay on this phrase for a second because if there's no business viability in the idea, then we're already done. I mean, if you're going to go back to Eric Ries's Lean Startup or if you're going to jump to Marty Kagan's four, four categories, it doesn't really matter. Business viability is handled in either of those models. Marty Kagan didn't really have a model. He just had four things. Anyway, the, the point is what have you done to confirm the business viability of this idea that, that this is the problem we need to solve? And that generally. This, this guiding policy will solve it. Yeah, I think yeah, absolutely spot on. I think there's other things that fall under the same umbrella of business viability, right? Which is what is the problem? Can we solve it? Yeah. Do we have the skills to solve it? Do we have the technical know how? Do we have a potential market for it? If so, how big is the market? Is it a market that's hardly going to pay back the investment that we make in it? In the hope of a future payoff, or is it a market that we can expand out to others? Once we've proven it in this little niche area, I mean, there's just so many different ways you can go. Do we have the right talent in house to, to do this? I would crowbar that apart from business viability, because I've seen companies. That will pick their problem they want to go after and then they'll hire offshore teams or I think there has to be a strategy, right? That's all I'm saying is if you don't have the skills in house, that's okay, you can borrow them. You can rent them or whatever. That's fine. But that is a strategy. If you've decided that this is so cutting edge that the skill sets are just not available or not available now, that influences your, your overall strategy for pursuing this solution or product. In the technical feasibility consideration of can we build this solution we're going to talk about do we have the skills to do this? For example, I read a couple articles that they were sharing how much money the company saved from not. Going with the cloud solution and hosting everything in house. And, and they were kind of throwing in everyone's face about like, Oh, I wanted to go in house with this hosted solution. And everyone kind of laughed at me and said, Oh, everyone's in the cloud now. And this seems like this seems like a stone age kind of a strategy. But the person on LinkedIn was like, yeah, but I pay like a 10th if that of what y'all pay in the cloud by just hosting in the house. And that's just the monetary aspect, right? What about the risk, right? You know, the cloud provider. poses a risk basically. And if you have things in house, well, those stones are real, right? So yeah, it may seem like stone age, but you have a lot more control over that. Yeah. In the value category, we sort of talked about. Product market fit, but we didn't, we didn't stop on it for a second. Right. Product market fit, crossing the chasm we have previous podcasts on this topic, so we're not gonna spend too much time here. But the product market fit, the majority of this topic is about. research. Like you have done your homework. You know, you talked about addressable market the size of the addressable, the potential market or whatever, right? Like you don't get that without research, or already starting your company, your team or whatever, with industry experts starting, or, or maybe you pay industry experts for a percentage of their time or pay them hourly or whatever. If you're small, you can't afford them. You can buy some of this stuff as well, right? I mean, that's fine, but Your point is valid. You have to do your research, no matter how, whether you do it from the ground up, from within, or you buy some of it, that's fine, but do your research, because you, without that, the alternative is, is conjecture. You're listening to somebody and believing what they say right or wrong, and that's just opinion. And when you start off creating a new product with opinion based, Approaches? Yeah, I'm not investing in that. Well, let's pivot to the backbone of your organization being a data driven culture. I mean, if you're going to pick an idea out of the air, if you're going to pick a problem, basically, what you're doing here is you're picking a problem out of the air, and you're saying, you know what, we're going to derive a solution That nobody else has for this problem. That's just one strategy, right? oH another way would say, okay, we're gonna take this crowded market, and we're gonna do the same thing everyone else does, because it's super easy to just copy everyone else, but have a better UX. Because we're we don't have to rethink any of the deep features or anything. But we'll have a couple of niche, real, yeah, real differentiating features. But also we'll copy what everyone else did and then we'll make it a lot sexier than everyone else does. Well, we'll market it better. Whatever, price it better. Yeah, there's a lot of strategies there, but I want to go back to the first one, right? So if you say we're going to come up with a solution to a problem, how do you know that problem is real? How do you know that problem exists and it's worth tackling now? Have you done the analysis to say? What are the problems that your customer, customers are facing? And then which one, which ones are you going to tackle now versus later? That is not so much a science. I think some of that is art. I think some of that is, is intuition. People knowing the customers. Even customers you don't have now, you're, you're guessing what they're going to do because they're going to emulate the customers you do have now. Some will, some will come out with things completely out of the blue, but there has to be some sense in trying to define if the problem is there. for sure. Is it the right problem to tackle? Is it the right time to tackle the problem? And are you the right company to tackle the problem? Yeah, right. I think there's a lot there, honestly. You know, the last one is the simplest one. We can peel that off of here, which is the capability issue, right? Do you have the skills or can you get the skills? I'm so lucky that real early in my career I had an opportunity to, to really practice the BA skill set. And really like be free with exp expanding the BA skill set. And because everything you just described of like interviewing users and knowing the questions to ask and knowing how to kind of go from A to B to C to walk through and knowing how to, how to dig through the solution being asked down to the problems that, that are underlying each one. All that kind of stuff came from talking directly to customers and exercising that BA skill set. How did I not have that? You know, maybe I would be one of these people that just jumps from solution to solution The wrapper around all of this was about being data driven. Like you're, you're never, you're never going to value having a staff of people doing that, or even, even having that. If you go to your teams and you say, Oh, I talk to the customer, I know what to build, just build what I say. And then you don't need to do follow up after the features in production. You don't need to watch metrics. And you don't mean that, that kind of stuff like that. The data driven is like part of the culture or it's not. I agree with that. I think there's so many Companies that are basically working, existing in the way you just described, which is somebody talks to the customer, then they come out and translate what they heard, what they think they heard to the teams. The teams never talk to the customers, right? Yeah, unfortunately, that's a reality. And it's really sad to see that because you're, you're missing out on something that is so basic. What does it take to have your team talk to the customer? Honestly, why not? And, and I'll tell like for me in a couple shops like this where you were discouraged from talking to the customer, usually there's some gatekeepers, or there's some territorialism happening or whatever but. The higher you escalate in the organization and talk about these things, I would say that the less important it becomes. I usually, what the strategy, I don't know if it's a great strategy. We'll see if you agree or disagree with this, but the strategy that I usually find is I just climb higher and higher until I get someone that Will tell me like there's no reason why everyone shouldn't be talking to customers. That's ludicrous that anybody's blocking you You know Let me at him and then usually that the star power of somebody higher up in the organization is enough to at least initially Breakthrough that first Stone wall, and then once you break through that first stone wall every other wall to break through becomes a little easier after that And you know what else you know also help so Getting the initial like going from a culture of not doing it to doing at least one once one once is one thing but actually, actually incorporating that user feedback and then changing the product based on the user feedback. That will also make it a lot easier. It makes no difference to talk to customers and then you don't do anything. Exactly. That's a waste of their time and your time. My approach has been a little bit different. I take more of a guerrilla tactic to that, which is I just basically have my developer, development team talk to customers. Now the contrarian argument to that is, hey, these are technical people. They don't know how to talk to customers. They might say yes to everything. And what I've found is If you spend a little bit of time with your team ahead of that and say, look, the purpose is to listen. The purpose is not to just say, yes ma'am, no ma'am. The purpose is to listen and ask questions. But when they ask you questions in return and say that some customers are really savvy, right? And they will do what I call ego stroking, right? They'll say, you're a smart guy, Fred or Mary. Surely you can have this knocked out in a couple of sprints and Alfredo Mary feels really good. And they're more inclined to say yes. So I, I basically work with the team ahead of times. If that question is asked of you, your response would be, let me go back, talk to the team. We'll discuss this further and we'll get back to you. That's it. Yeah. The team's not going to learn those skills unless you actually put them in front of real customers. Exactly. Death by fire. I look, it's, it's. It's like the teams want to talk to customers, right, to the point about gatekeepers. It's the gatekeepers that are preventing this from happening for some fear of some kind. So if you tackle the fear and get rid of that eventuality from happening, the team over committing not understanding and still saying yes, all of those kinds of things that people are worried about, then I think the gatekeepers will fall in line. Yeah. But I take a little different approach and I just. Do it. Yeah. Basically. Yeah. And then, you're in a weird spot when like some of your organization or some of your teams are data driven and the other if you have, Some of your teams are feature factory teams and some of your teams are not like that. That is a i've been in an organization like that. It's very strange. It is very strange But it's very pervasive too. I mean that's very common out there, right? Unfortunately. Yeah, it's it's very odd because whoever holds an opinion gosh there's a there's a great strong opinions loosely held is that the is that the phrase? Loose opinions are strongly held? I don't know. I don't know. Yeah I mean the basic meaning of that is if if you're if you're given new evidence or evidence that shows You know, the contrary to what you believe you should just adjust and then move on unless, unless you're, you're ego driven in that case, all bets are off. Yeah. That's, this is a, this a whole different podcast. I feel like we did. We'd love to do that. We do, we do do a podcast on ego, but I think the podcast here is about. Identifying why someone is unwilling to change their opinion, even in the face of evidence because there could be an identity aspect in here as well. Yeah, they may have already put their bets on the table, right? So then you show them evidence that basically leads them to understand that their bets are going to fail. They're going to resist you. Right. Right. That's the bottom line, I think. And again, what I told you on a previous podcast and what we were talking about earlier today you know, I've, I've encountered this in the real world with like the development manager I was talking about who, he owned the stats system and, the stats were not transparent, people could not just go to the stats. that to the system to get clean stats. They would ask him for the report they wanted and he would generate the report and send it to them. And of course he would throw out the outliers before he sent them the stats. So they got quote, clean stats, so there was like, there was some obfuscation happening. Absolutely. We've seen that this happens typically the, the public facing aspect of military leaders are like that. I mean, they're going to always sugarcoat things and tone things down and. Whatever else dress it down, but people out in the field know what's going on, right? Yeah, and then unfortunately what happens though as a result of all this is it creates distrust between You know the troops and the leadership right and that that's sad because that's never gonna lead to anything good, right? You might know that you're not in a data driven culture if you know every session or when a big blow up happens or whatever, you see the big tap dance happening and you know, it's, it's not a straight a to B to C type of conversation of like this, this specific thing happened and now let's go to a five whys exercise or this specific thing happened. And here's Here's the things we're going to implement to make sure it doesn't happen again. Ego out of it, emotions out of it. Type of type of situation. Yeah. Yeah. Reality on the ground though, really is that doesn't happen. And what happens instead is like you said, obfuscation also a lot of deflection. Yeah. Oh, it was because of bad weather that this happened, right? It's like, no, that could have been prevented. Well, you're probably not going to solve your problems in companies like that. No, you're probably gonna have the same problems occurring over and over and over. We're going to give you the same advice we always give you on this. Podcast, which is keep that resume updated. when you decide to launch a new product there's, there's a bunch of different go to market strategies that, that are pretty traditional. Like you learn about them in, in basic marketing type stuff. However the rollout that I prefer is to do an MVP, a real MVP. Not, not a minimum viable feature set or minimum viable cat herder or whatever people make up, you know. I don't know, like actual MVP of the business viability of I'm going to test this with these customers. You know, the funny thing is, we were talking about user interviews you can, I mean, if you're willing to compensate people for their time for user interviews, you can get a lot of mileage out of a very little amount of money. I mean, you could even go find out who consumes your competitor products and interview them because I mean, they're just customers like they're not They're your customers maybe but yeah, they're just walking into the shop Like they're not they're not loyal slash beholden to only shop from that shop Like they're very likely they're not under any kind of contract where they can't even talk to anyone else You could interview like hey, buddy. I like 100 bucks, 50 bucks for 20 minutes of your time and maybe we got some valuable insights. This is exactly how a lot of the the pharmaceutical businesses is operating right now where they will. Figure out who are some of the actual patients that are suffering from, whatever, insert your malady here high blood pressure or diabetes, whatever it is, right? And they will ask them a bunch of questions, and they will learn so much. They will ask you things like, Are you using anything for controlling your condition, right? How well is it working, right? What do you wish that it would do that it's not doing today? Yeah, that's gold. Now they're not throwing the other company under the bus at all by doing this, right? All they're doing is learning the real pain points from the people that matter the most, which is your customers. The paying customers at the end of the day that you hope to satisfy with your product, right? I think it's fantastic. I think people should do that more and more. Unfortunately, we don't see that outside of a few industries like that. Like maybe I think the pharma industry is leading the way here. But others, not so much. Yeah. Software. We hardly ever see that. Hardly. Yeah. Hardly ever. There's a lot of, a lot to be gained by doing that. And there's, I mean, survey technology is out there. You could throw a wide net, get a lot of survey responses and then filter through the surveys to get your exact fit for what you're looking for. So as long as you can construct a fairly decent survey and there's knowledge out there to how to construct a survey. So, I feel so much of the survey questions for what would be relevant to your company would be company specific. So, I don't even really want to go into that now. We probably could do a whole podcast on surveys. We probably could find some people that are, that know. how to really conduct real, real pointed surveys to get at the point of what they're looking for. But when I'm through the MVP phase, I know that this idea is going to go over well with a particular market segment or a particular audience of a market segment, right? Let's niche down to a very specific audience inside of a market segment. Yep. Try it out. You can't be all things to all customers. Well, we're trying, we're trying to identify the underserved group. That's what we're trying to do. It's a lot easier to say like a rattle off in like a one sentence thing. Then in actuality, it's like probably weeks and months of work to, to identify this underserved group. If you, if you don't know any of the users, like ideally, like I've always been in a good position where I'm coupled with founders or domain experts or people from the industry. that now work in the business and they can point you in the right direction. And then they point you at people who are very influential. And then those influential people can point you to to 5, 10 other people. I think conferences are a great fertile ground for that. Conferences, yeah, yeah. Yeah, good one. Yeah. So let's assume that we've got to the point where we defined what the problem is. We find the fact that it's worth solving. We have an MVP that we've kind of crafted now, right? So we have a target audience. We have the MVP would be every every feature that we think is important. We've tested with that audience. So 234 features. Hey, is this good for you? Yes, yes, absolutely. You must have. Fantastic. I'll use that right away. I'll sign up tomorrow. I've got my signup list that I said, if you, if we gave you this and it did whatever, and it maybe looked like this. Would you sign up, here's a here's a form, sign up to be on the early, early list to test it or whatever. I'm trying not to use any terminology right now. I get that. So I think that's really kind of the natural progression. What happens after that part, right? Yeah. What would you do? Say you have a few people interested. They filled out that form and they're interested. What's the next step? Is the next step maybe just to say Listen, try it out for real, right? And that's, that's that pilot that we talk about. Oftentimes that term is misunderstood. People say we're piloting when all they're doing is UAT internally. That's not a pilot. A pilot is when you have potential customers using your product as though it was in production. That's the definition of a pilot. Otherwise it's not a pilot, it's just a UAT. Or whatever you want to say, SAT, UAT, all these AT terms, right? A pilot means that somebody tried it out, for real. They're not throwing away their existing system by all means. They're doing this in parallel, maybe they can do some comparisons. Right? But they're giving you valuable feedback because they actually tried out in their environment. The framework that I would deploy for this is alpha, beta, and production. That's the, the basic framework that I will roll out. And, you can get more complicated than that if you want, but, and sometimes you can even skip alpha. The concept is, I would take my MVP confirmations of these things are valuable. I would rank them internally with my team, based on all the research that we got. Or maybe we'd rank them with customers. I don't know. It depends if it's for a couple customers or really like one specific customer. Could be different. But the point is, it doesn't matter. There's some kind of ranking involved. We pick one. We start developing that one to be an actual product that people will be able to pay money for and use in production. And this is where, this is where like a lot of my disagreement with MVP comes in, which is this alpha release. Like it doesn't scale. We're watching it every day. We're double checking the logs. You got the product manager with their phone checking the stats every day and sending out emails or whatever. And I mean, you got your engineer babysitting it cause, the application pool needs to be reset before it runs out of memory, or it's running on this machine and you don't want to swap it over to this to the proper machine it should be running on or you run it and you don't think like there's not a hard drive space or memory or whatever, the point is, it's not meant to last forever in its current form, it's really meant to say, hey, let's prove that we can do this, let's gather evidence of if people are using it, how they're using it, let's get their feedback about how they use it. And let's talk to them, every single feature we put out, let's talk to them about it. The sprint review, this is the whole point of it. Every time you touch that software and put something out, get that customer on a, on a, on a call, have them walk through it and just watch them. You know, this is what you, this is what UX people do. And somehow it's magic. Right, right. So a couple of things I want to just kind of unravel there, right? So I absolutely agree in principle. The MVP isn't designed to be scalable, right? So maybe you don't reset the application pool because whatever you've set it to, it's There and if it sits in Spain's, you learn from that. Yeah, it's not like you have thousands of users on yet. Eso. That's one. The other thing is when you're getting feedback from the customer, it's, it's gotta be real time feedback. It's not like go use it for a couple of weeks and come back to us because one of two things that happen, they'll use it half heartedly if it only sort of works some of the times or they'll stop it, they'll stop using the, this thing crashes. It crashes because it's not designed to do all these 15 other things that you're trying to do. So educate the customer. Somebody needs to shadow them. Right? I don't know who that is. Maybe it's your your tech lead, architect sales, whoever it is. They need to shadow them and say, this is all it's supposed to do. Just use that part. How do you like that? Right? Get that feedback in quickly. That's, that's one thing. The second thing I want to say yeah, definitely get your customer in on your sprint reviews every sprint. But you don't you don't have to wait until then. The minute you have something spun up that kind of looks usable, get them on. So it could be a week into your two week sprint. Don't wait another week. Get them on. And say, here's how it looks. Are we going in the right direction here? It's far better to pivot then, than wait till the end of the sprint, in principle it doesn't matter much, but the earlier the better is what I'm saying, right? Yeah. And I I think of an alpha as it's very fragile. It doesn't scale. It doesn't do more than maybe one or two things at all, really at all. Right. That's the, and, and the, and the users that you've invited are a closed ecosystem. You know, you're not opening it up for the whole world to create free accounts or whatever. You might do that in a beta phase. Where you've said I want to onboard X amount of users or I want to, I want in the beta phase, I want to allow basically all my users in my existing app to flip over to this new, like if I have a mobile app already published in the store, I want to add a link inside of it that says, Hey, we have a new mobile app. It does this other business function that the the current one doesn't do. We think it's really great. Here's a link. It'll take you to the app store and download the new one. It's completely separate. That, that, then you're allowing people to sign up for a closed beta. Like maybe you don't, maybe it's not in the app store for general availability. Maybe only the people that are currently signed up for your current app can use the new or what I don't know how you invite people to the, to the beta, but the idea is now that you have a couple of different pieces of functionality. What we went to before, we're like, well, when we, we said we MVP to all these features, we, we, we decided that yes, the customers do want them. Yes, there is signal there. Yes. We have signups or whatever pre pre pre NDAs or whatever else. Yeah. Whatever, whatever it would be for the alpha. Or maybe you're not doing it like GA type of like open it up to people. Maybe it's like one company. If you're doing like B2B, right. Right. One company says. Hey, sign us up and then we'll be your alpha tester or we'll be your beta your beta customer or whatever so you're, you're, you're bringing on companies into your product ecosystem, whatever it is that could be, cause I did that way back in the day when software used to be installed you know, CDs, send people CDs. Yeah. There's a couple of things there that I want to also touch on here, which is oftentimes the term alpha, beta are misunderstood. Right? So what I found is a lot of that people say, well, it's alpha. It's internal within our own company. Customers are not seeing that could be okay. That's your definition. That's okay. You can go with that, right? In terms of inviting customers, you could do one of two things. You could either invite them onto a stage environment Which is a copy of their production system. So their risk is completely eliminated. It's separate from their actual production system. But it's a copy and they can use that one sliver of functionality that you're delivering here. That's one way. The other way is to use feature toggles and then they can toggle on the functionality in their environment. But the risk is still reduced because if the proverbial crap hits the fan, they can turn off the toggle and they're safe again. Right? So there's many approaches to this, right? I think, you need to kind of Understand what the customer's comfort level is and go with that. Because there's a lot to be said for having the customer come and work with you shoulder to shoulder. If they're not comfortable, already they've got the defenses up, right? And the minute something goes wrong, the second, the first thing goes wrong, they're on their guard. Oh, this is broke, right? So if you want to improve your chances, think through how you're going to do the actual the deployment and the measurement, the telemetry after you've deployed it. Because that's something that's quite Quite lacking. Well, all this is very difficult to do if you're not data driven. Absolutely. It's impossible If you've picked a bad partner if a lot of your prep work has not been done in good faith or now not been done with the proper diligence Now, when you get to trying to move between alpha and beta it's going to bring you a lot of pain that you've you've chosen the wrong partner who is like your alpha server, for example, there's no guarantee of availability of a product in alpha phase. Like the product could be non operational. For hours at a time or, or, or we could just turn off the server when we're not at work could be just be off and there will not necessarily be a bad thing because you know, when you're talking about cloud tech, right? Those servers cost money every second. They're up and spinning. So yeah, turn them off. 5 p. m. 6 p. m. or whatever until the next morning. You're saving money there. Turn them off over the weekend. I specifically think about data science applications where the GPUs are processing all those mathematical operations. Like, they're extremely expensive, so I can completely see, we're only going to run these servers for 8 hours a day, and it's only one where they're here to monitor them because We don't want to work the whatever at two in the morning trying to figure out why a server needs to be rebooted. Like we'll, we'll do that in during the work day. And that's just your cutoff. And if you have partners that are not okay with that, like they are not good partners. I mean, unless obviously, unless they're willing to kick you in some money for right, right. So you could adjust based on that cause you're catering to their need. And they haven't really invested fully, but they're testing the waters, right? So they can pay towards that. Or you could adjust and say, look, when are you testing? Are you testing between the hours of 11 and three? We'll have the servers available then. So it's just, it's a case by case, I think, but it's something that could be won. This is not a battle that you can, you have to lose. Again, I go back to my frustration with MVP, like MVP. All the conversations you have when you're stepping through a logical progression from alpha to beta to production through the phases. Like that stuff is, it clogs up the clarity of MVP is like, is this idea, Viable business viability. Is it viable for the business? This idea, not it will the server run 24 seven or whatever like that. I probably, I handled that in beta at some point, maybe towards the end of the beta, I don't know, but definitely by GA general release, production release, whatever you want to call it, I've handled scaling the system and making sure it's going to run and making sure that I've got air handling and all that kind of stuff, but the technical feasibility of. Can I create the system to be highly available? Can I code in the proper technologies? Can I maintain the solution now into the future? All of this is like technical feasibility of Can I do this with the technology? Completely separate in my brain from the MVP discussion, and that's why it's like super frustrating to me that it's all bundled together. Yeah, it's obviously I agree. I call this the illities. So there's one thing to test out. Your MVP, but all the ilities, feasibility, scalability, availability, right? Resilience, all of that's not an ility. But anyway, all of those things can follow. That's not what you're really putting out there in your MVP. It shouldn't be because you are wasting your time there. Get your MVP tested and then fix it up so that it is available, it is scalable and all of the ilities are satisfied. Yeah. That's secondary to the MVP. But at least you know now that you're in the right zip code at least, right? And without that You don't even know. Then the, kind of the last thing that I'll, I'll point out during that, that, that alpha beta production phased type of approach. Is watching out for the technical debt. Like that kind of what we just talked about is you know, does the system scale, is it going to be available, whatever, like saying no, and then moving on, like saying like, well, no, servers are only going to be on 12 hours a day instead of 24 hours a day like that, that right there is like, okay, let me put a little marker on my technical debt. Wall and let me put a little sticky on my wall of technical debt of like we, we have decided that this, these are the technical limitations of our application and we all decided this and we know in some state in the future we're going to have to take these stickies off the wall and address them one at a time but, but you as a business in order to get through these phases. You make those tradeoffs, you make those concessions, you put that kind of stuff in your backlog and you say, Oh, for every one of these things that we decide, let's put it over here. Yeah. So those are conscious and overt decisions, right? So there's two types of technical debt. One is you deliberately say we're not going to work on this now, and that could be going down the path of that now next later kind of thing. But then the other one is, is that. Covert technical debt that you're doing that that you're building up because of bad practices. That's a different issue Those are less visible, but you have to be very vigilant to get those Exposed into your backlog so that you can deal with them that comes later because you've already proven that there's a market That there's a fit that the product is real, that it works. It's past alpha, right? And people are willing to go to beta at least. Therefore that people are going to pay for that. And then at some point you can decide to fix up the technical debt. So two sides of the technical debt, the overt and the covert, right? The overt, you already know about it because you've made the trade offs to your point. Right. And those are usually. Time and money related. Not now, later. We're not going to spend money now to make it scalable. But, when we know that it has to serve a thousand users concurrently, we'll get ahead of that and we'll make it scalable then. But for now, it doesn't do what it's intended to do at a core minimum. Or, you just sell your company and make that somebody else's problem. Yeah! And take all your friends with you and go somewhere else and repeat the whole Silicon Valley strategy right there. Kick technical debt off until you've made a billion gillion dollars. The last of the Marty Kagan four categories that we didn't talk about was like you're going through this alpha beta production and like your UI might look like it's geo cities from the nineties. You know, until you hit a point and you have to say. Like, is this UX something that people are willing to use and people will be happy to use and that it is clear what path the user should take to the application. You've done some basic journey mapping, you know what I mean? You've done some basic understanding of how users solve the problem. And you know, it, can users figure out how to use your software somewhere along with this alpha beta production flow? That should be going on just like somewhere along in this flow. The discussion of technical feasibility should be going on. So I, maybe I don't, I don't put them as early as MVP. You certainly could. You could do high fidelity user designs. You, you could mock up a whole application in, in, in high fidelity wireframes that nobody would even know what was in an application quite honestly because there's so much functionality inside of Figma. You can fake stuff left and right. XD, Figma, there's tons, yeah, tons but , usability testing. That's what I'm saying. I kind of put that with the technical feasibility hand in hand where they, they're, they're advancing. As we advance along these tracks, but the MVP, does the idea work? I Think that comes before these two categories. I'm willing. I'm flexible on this one, but I think it comes before it's, it's a tricky one because I think there's a delicate balance, right? Obviously the thing has to be usable, but to what degree? So we're talking about MVP. Some usability that befits the MVP functionality has to be incorporated from the beginning. What you should be doing though, is to get feedback throughout. The process from your users to see where the kinks are right in their journey. So you can ease those those issues in subsequent releases. I'm assuming that this isn't a gunshot approach where you're saying, well, this is the MVP release and we're done. You're saying this is MVP. What do you not like about this? And then build it in and know this is the next the next release. If you're doing that, then throughout the process, you're getting feedback from the customer on their User experience right and building that in but yeah, I mean don't release an MVP if it's Hard to use because you're already behind the eight ball there Yeah, well that again Mike you hit on my another one of my gripes with MVP. It's like, oh, we're gonna pick a date And that'll be the MVP release and then we'll the whole team will move off to another product or whatever is right That's not that's not An MVP, that's not, what are you doing? Like, where'd you go? We just got started. You know, you basically, you just kicked off your open beta at that point. And you called it an MVP, but it's not an MVP. Like, the MVP is just testing ideas. Nothing good could come out of that because you're going to have customers screaming at you when these things don't work as well, right? Or don't work at all in some cases and you've already Redeployed your teams to do other things. So who's gonna pick up that right? That's a very sour experience Good luck surviving that the old waterfall hyper care period that's even right. Yeah You pay for enough hypercare bucks. This thing's so bad that for the next 90 days, we're going to just pretend that we care. That's right. Another one that people kind of fail on is a strategy. They'll, they'll build it thinking they got something new and they have no idea what, what they should charge for it. This is very difficult because it's very difficult to figure out. You know monetization. I mean that, that, that, that super easy plan say just figure out what your closest competitors cost and just charge the same as them. So how well are they doing? No, I agree. This is actually a tricky thing. I think that we started with being data driven. Definitely figure out where your competitors are charging because that's one little variable in the equation here, right? But the other side of it, which is I think more critical, is what value are you adding on to the functionality you're providing and what is that worth to the customer? Now, you don't have to guess at this. Right. There's some science to this, which is to say when a customer receives a piece of functionality that they can use from your MVP, let's say, what are they doing with that? Like, what is the benefit for them? Are they saving money or are they making money or are they becoming more effective or efficient? Whatever it is. Hone in on that and figure out what it's worth to them. And, and, don't be afraid to ask them. What is this worth to you? What, what does this mean to you? Right? What do you save by having this functionality? Or what do you, what can you get more of? Right? And based on that, you can guide your pricing strategy. Yeah. I've also seen this in terms of how many tools it replaces or but savings, right? Yeah. Savings. Yeah, exactly. And then, and then going in under that I've also seen more clumsy methods of whatever it is. And then just double it and then double it again or something like that. I mean, monetization strategies this advice on this is like a dime a dozen. You can read a million different strategies. Nobody's is going to be satisfied that it's not, none, none, none of it is going to be satisfying because a lot of it depends on your industry. And it's very hyper specific. Yeah, I mean, sometimes I've seen people take the jeweler's approach, which is it's worth what the customer will pay for. And yeah, maybe it works sometimes, but more times than not, it doesn't work. Because as soon as that price is out. It will be out the minute you say it. Your competitor comes in, bolsters up their product to have similar functionality to yours and undercuts you on price, right? So you're already, why would a customer stay with you when you're pricing this thing way up high using the jeweler principle again, when the competitor comes in and says we can do almost that, if not, if not exactly that at a much lower cost. Now you've got to Now you're on you're playing defense, right? And you're trying to figure out how you can differentiate yourself even more. Maybe like, I think there's a, there is a in the Robert Cialdini influence book, I think there is a a strategy about outpricing all your competition so that you could be seen as like the luxury. Sure. Good. But that, I mean, like not a lot of people can take that strategy because you're counting on a couple of big whales. To buy your product rather than like a lot of people you're, you're really trying to hype your market becomes hyper specific at that point. Yeah. And yeah, there are examples in industry where these kinds of suppliers are successful. But if you look at their products, not only do they have the cache of the name, but the quality is there. Right? Not always, but most times. And so, yeah, I mean that is a strategy if that's how brave you feel. And then like our, our last category about creating new products is at some point you, you are going to need marketing. You're going to need a A go to market strategy, whether that go to market strategy is the, the normal traditional media blitz or the, the, the, I think of a traditional media blitz is the same as like a social media blast or campaign or buying ads or defining an audience. Like on social media, you'll say, well, I want to, I want to identify suburban women between this age and this as the ethnicity that live in these particular urban areas. So I want to advertise this new product to them or whatever, and you'll buy. that demographic and you'll just blast it on all the social media sites that you can find whatever. I don't, Facebook is the biggest one, but you'll, you'll blast across all the social media applications that you have access to. And I equate that basically to like buy and add time on the radio. Like you're blasting over whatever media channels you have access to. Whether it's to a hyper specific audience or just to like putting a billboards to everyone, whatever works for your product. I'm not really sure what what your product would be, but traditional marketing social media marketing, traditional marketing are kind of one strategy of blasted out there and then hope that people that I will tell you, that's a, that's a strategy that scares me the most. Well, that's the most prevalent strategy, too. I mean, think back to the days when you know, cell phones first came out. I, I well remember large companies there's an ampersand in their name they would, they would buy newspaper ads. And newspaper ads back in the day, when newspapers were still being read were pretty expensive, especially full page ads. And now, when you have a full page ad in, in full color, the price is like eight times that of black and white. They would buy these. And not necessarily targeted anybody, but it would have upwardly mobile, whatever that means, upwardly mobile people there in suits and with phones, big old phones. These people need these phones to communicate. So that was the strategy, pretty broad brush at that point. And then it became from, it went from there to magazines, right? And from there. You know, like you said, and now it's social media. So I think the media has changed, but the strategy is largely the same, right? That's what I'm saying. There's a luxury car brand that is, it's well known that they, I think they went on record as saying we run these ads for our customers. We don't run them for general people that like nobody's going to see on the TV. Oh, buy this 100, 000 car. But the people that have bought the a hundred thousand, a hundred thousand dollars car, when they see the commercial, they feel better. And now they're more brand loyal because they feel special. Yeah. Because oh, they're in that category. Like the, the, the positioning of like, oh, we are the car brand for smarmy, suburbanites or whatever. Like Right. The positioning of getting your, getting your name in front of a customer. with a we're the people for X or whatever. That's a, that is what I think is most covered in this here. Yeah. And just taking that a little further, what I've seen with super luxury cars they would normally. Pinpoint their audience like existing people that are either running their own vehicles or vehicles of equal in the same bracket, let's just say but they would also leave out some information just to propagate this sense of mystique, right? So a car brand, very popular would not publish their horsepower for their engine, right? Instead of that. It simply said engine output. One word. Adequate. And now you think about that and you go, Oh, how much is it? Now you're intrigued. You're gonna look further, right? The fact that it was 600 horsepower, way overkill, didn't matter. But they didn't tell you that. And there's other things like, Every one of their cars, the engine is, they say hand built, and the person that quote unquote owns that that engine throughout the duration of its build process. They will stamp their name on the engine block. What is that worth to the customer? But it's it's a sense of pride, right? That's what they're selling you on. And and implicitly the quality because it's one neck to choke at the end of the day. But that's really what they're doing. All of these little things add up to the sense of mystique and feel like the customer, the prospective customer feels like they're somehow special or valued. That's the whole point of this, right? Yeah. And that there's tactics. These are just strategies, but there's tactics they use, right? Yeah. But this is all, all part of their go to market is like, no other car has this. No other, yeah, absolutely. They're extra bells and whistles. Like, are they necessary? Do they really matter? Like, I don't know. It depends on your audience. If you find the right audience. Yeah, they absolutely matter. where I started with the whole MVP thing is like, you have, if you really are launching a software product from the ground up, you probably need to find those early adopters. If we're talking about the technology adoption life cycle, the. The curve, right? That crossing chasm, right? If we're talking about that, you need to identify that audience of early adopters. And, and if it's not you going out and surveying and finding and constructing that group, then that group may already exist as a community. It's you don't going and joining that community. I mean, the agile community is a community like this, right? You know, if you were trying, if you were trying to sell a product. Whatever that product might be. Could be, could be classes, could be your latest training, could be anything. If you were trying to sell a product to this group. You would go to whatever the Facebook groups or the meetups or wherever where these people are, conferences where these people are, and you would continually peddle your your wares. And that's being done all the time, as we know. I mean, is it? I don't know, maybe. I don't know, it's been a while since I went to a conference, but I do remember going to one some time ago. They would offer a 50 percent discount if you signed up for their course. Yeah, buy my book. But, finding the community that's already existing is one way. Building that community, because they don't exist, is a whole more difficult. Is a way more difficult, but, but also equally effective. It's very rewarding if you can pull it off, but it's an order of magnitude more difficult. Yes. Yeah. fiNding the early adopters. Going to them and pitching your solution to them to their specific problem that nobody else is solving Whether you're building a community out of them or not Finding a community that's already underserved for things and then We haven't even talked about the whole product led growth movement that's out there that many, many successful company we just talked about Figma, Canva, a bunch of other companies that I could probably think about off the top of my head. If I really sat down, a lot of SAS products do this. Yeah. You know, product led growth, which is the sign up, you get the basic features and then for a few dollars more per month you can get. You know, all of our premium features that hopefully they're good. Yeah. Yeah. And some of that is also, well, you get this thing for free, but it's ad driven and whatever else, and pay more money and we'll take the ads off and whatever else. So these are different ways of really getting in with your, your, your target market area. Yeah. That's exactly but we didn't talk about strategic partnerships either, like a bundling your service or your software or whatever, with another company that already had, that was already in the market and you cut them in and like that, I worked for a company a long time that that was, that, that was their main measure of success is that they had these they, they had channel partners too, but they had these means they had these strategic partners that you know, they'd cut a certain amount of revenue if they resold. You know, yeah, there's handshaking. So there's that, that one. And then the other one is piggybacking off of there. So there's plenty of techniques out there. I mean, that, that's good. I mean, it does require a little bit of you know, executive horsepower to make these partnerships and stuff like that. But again, it's just another community. It's just another yeah. I just want to say that we started this podcast by introducing the term zero to one, right? Maybe there's interim steps in between. Maybe you go zero to a quarter or a half and then go to one. I don't know. Just putting it out there. No, sorry. There's only zero or MVP slash production release. MVP slash production release. That's what I learned today, which is it's just, just pick a date out of the air and take your MVP to production and then fire your team because you're in production now. So it's all good to put something up in the air, turn on the fan at full speed and hope something sticks on one of the walls, build something and hope that people will buy it with no plan on how much, like that by the end of this, hopefully you're, you're at least informed about some of the things not to do. If you see your company headed in the direction of building something with no plan how to price it or no plan how to market it or you don't know what the roadmap looks like to, to get to GA. You just, Oh, we're going to launch our MVP and it'll be in production. Everyone can sign up for it. Yay. Well, let's take a step back and some random person on the internet told me that like unless we're kind of thinking about these you know, we, we may be headed for a rocky waters with our company slash definitely our product for sure. Maybe our company, depending on how much money we throw into that sinking ship. Maybe the individuals listen to this. Maybe their job. So at the end of the day, look, hope and a prayer ain't a strategy. Also I'm not saying you have to have all these skills and you have to do all this yourself. Like you could certainly reach out, get some help with marketing, hire somebody part time or hire some services a couple of hours. from somebody who, who's an expert in the field to help you. If your company is real small or whatever, like you don't have to do all this alone. Absolutely. Buy a rent. I mean, do what's do what's needed, right? But validate what's needed first, right? See if you can monetize it. Is it worth it to be in this game to begin with? Yeah. Ask for help. The worst your company can do is say, no, , we want you to do marketing and product management and direct sales and do your own stunts. Well, if that happens yeah, just call a Brian and Om's software company. That's right. And ask for a raise! All right. So with that, hopefully this has been informative valuable. For you, let us know in the comments down below, what other subjects you'd like us to delve into. That's right. Hopefully, hopefully this has been minimum and viable. Absolutely. It's yes. And, and don't forget to subscribe and like that's right.