All right, let's get started. So today, my goal is to show you how you can make this shift from struggling to launching your products on time and on budget to successful in managing your teams and projects and save up to 50% on your product development costs.So um those of you who don't know me, I am a CTO start up tech advisor and creator of tech, speak for entrepreneurs, which is an online program where I teach the most effective and efficient ways to manage tech teams and projects, even if you're not technical or know how to code and what's most important for you guys to know is that I have managed tech teams and projects for over 18 years and I've refined and optimized my process over time and I taught my tech speak 10 step process, which we will learn today.

I'm going to share with you all of the 10 steps to over 1200 students so far and work with hundreds of different start ups, helping them with their tech strategies and help them fix and optimize their processes. So this is what we're going to learn today. First, we're going to learn what is process and why a good process is simply not enough. Then we'll learn the difference between the lien versus the classic way of building products. Two money saving things that you should be doing before you build anything. How to define your mvps, which stands, which stands for minimal arrival products properly, to reduce the cost and time of development, how to see the red flags sooner and minimize mistakes. Then I'll quickly mention how to work with me. For those of you who are interested and then we'll go into the live Q and A. Hopefully we'll have some time. But if you have any questions, drop them into the Q and A part of the chat and I will address whatever questions we have at the end. All right. Are you guys ready? Type? Yes, in the chat. If you're ready to go, I'm going to check in to make sure you guys are all here. Great. Excellent, awesome, awesome, awesome, great. I was just testing. Thank you guys. All right. So for those of you who just walked in, didn't download the workbook do that. There's a link at the top of the chat and the workbook has all of the concepts summarized. I want you to pay attention and actually participate.

So you don't have to take a ton of notes. All right, let's learn what is the process. So a process is a series of steps which when followed d diligently give you the same result no matter who performs it, it is a repeatable way to produce consistent results over and over and over again again. And a good product development process is important because it creates transparency throughout your project. So you can detect earlier when things are headed in the wrong direction. But a good product development process is simply not enough because there is a difference between releasing code and releasing code effectively and efficiently. Lots and lots of developers are releasing code every single day. If you currently have a team of developers, they're releasing code all the time launching new features and improving existing features. But if they're not using the link latest methodologies in their processes, then I guarantee that you are wasting valuable time and money due to inefficiencies and miscommunications.

And I want to demonstrate how important an efficient process is with this story. So here we have Eric, he's a student of mine. He had his software start up for three years before he learned the text speak process which we learn in the second part of the presentation. He had a tech team, he had a CTO and this is what he said after three years of running his software start up, he said after three years in business tech speak would have saved us close to half a million dollars in delays development costs and sleepless nights. I will let you absorb that for a second. That's a cost of a half a million dollars over a span of three years due to delays development costs and sleepless nights. And that's the benefit of having an optimized process based on lean and agile methodologies. Again, there's a difference between releasing code and releasing code effectively and efficiently. And please, please, please please don't rely on developers to come up with your processes because most developers are not managers or might not be familiar with the latest methodologies that you should be using.

They might have picked up a thing or two from whatever place they worked at before your company, but it might not be the most efficient and effective. Remember, Eric, the story that I just shared with you, he had a tech team and a CTO, he was non technical. So he relied on them to come up with all the processes, but it was obviously the wrong choice, right? They were not using an optimized process based on lean and agile methodologies, which meant that they lost almost half a million dollars over a span of three years due to inefficiencies and delays. Now that we know how important an efficient process is, let's learn the tech 10 step process. So you can see how it can save you time and money by allowing you to see the red flag sooner and catch mistakes earlier, minimizing the effect of the mistakes because it's unrealistic for any of us to never make mistakes no matter how good our processes are and I'm gonna share with you an amazing process today, but no matter how good your process is, it's unrealistic to expect that you won't ever make mistakes.

The key is to catch the mistakes sooner because the sooner you can catch the mistakes, the sooner you can address them, which of course minimizes the effects of the mistakes. So the two core pillars of my product development process are learn early, learn often and learn cheap and executing ideas the lean way and for start ups, especially early stage ones, learning quickly is really, really important because the faster you learn something, the faster you will learn.

If you headed in the right direction, you don't want to be spending a ton of time and money going in the wrong direction. And what's the difference between the classic versus the lean way of building products? Let's consider the classic way of building products, which is what most people do so we can learn what not to do. So in a classic way, you come up with your idea, you get excited about the possibilities and you start painting the picture in your head about how this new shiny functionality will change everything for the business. And the more you think about the possibilities, the more incredible and flawless your idea becomes and the more excited that you get raise your hand. If you've been guilty of that, I have been, let me know if you've been guilty of this. The more excited, the more you think about the possibilities, the more flawless your ideas become right? This is the reality of humans. We paint the picture and our imagination runs wild. So you put all of the resources behind building this amazing product functionality that will change everything.

And you spend 2 to 6 months to a year building your functionality in secret because you don't want anyone to steal your idea and then you launch. So you just committed six months to a year or even more of money, time and resources and then you get feedback, you may have hit it exactly on the nail and maybe it is an amazing success that you've been imagining in your head. But most often this is what happens. You discover that not many people buy or that it was not a problem worth solving or you built the wrong solution or, or, or, or, or so many wars. This approach is like shooting arrows at a target with blinders on. It is a big bet and it is very, very high risk. It's slow to market, it has zero customer validation and it's very, very expensive. On the other hand, lean uses scientific methodology of hypothesis tests, learned revised to discover what works with a lot less waste in a lean process. Every single brilliant idea that you have is actually a hypo. It is an assumption that has to be proven right or wrong by talking to customers and getting insightful feedback, which allows you to learn whether your hypothesis is valid or if it needs to be revised. And then you create a new hypothesis that needs to be tested again.

And everything drops into a lean development cycle of hypothesis test, learn wise, hypothesis test, learn wise. And the goal of your team is to learn uh is to minimize the total time through the loop by you guessed it right? Learning as quickly as possible. We already discussed the importance of learning quickly. The faster you learn something, the faster you will learn if you headed in the right direction. So basically, in the lean way of building products, your start up is a series of well designed experiments that you are constantly testing.

So you can adjust your path to success. And this is key, the simpler or the smaller your experiments are, the faster you can test and learn whether something is working or not. So instead of taking this long approach to figure out whether something works or not, we're taking small steps to get to success faster. So type yes into the chat. If you see why these two pillars are necessary to get into success faster, without wasting time and effort going in the wrong direction. This is the foundation of everything. I'm going to teach you for the rest of the session. I'm gonna dive into the 10 steps. But without you committing and creating a culture in your company around working these this way and training all of your team members to work this way. You're never going to increase the product velocity that we're going to be talking about. The key is to launch early often and cheap so that you can iterate really quickly to success. Thank you. Lots of yeses. Excellent. Thank you guys for participating. Let's keep going. So let uh I'm gonna do do a quick reminder again for people who walked in late. If you haven't downloaded the workbook, you can do that at the link at the top of the chat or just go to tech speak. That's your women tech. I've summarized all of these concepts there for you.

So you don't have to take a ton of notes and can actually participate. Awesome. Let's keep moving. So let's go through the four key things in my process that allow me to manage my teams and projects successfully without wasting thousands of dollars. So the first key is to not build anything until you refine the idea and the solution. So these are the first two step in the tech speak process because no matter how good your team is, whether in house or outsource, you will always waste time and money if you jump straight into coding without refining your ideas and the solutions, because you'll end up building a lot of unnecessary features and functionalities that your customers won't end up using.

Which of course results in a lot of wasted development, which directly translates into wasted time and money validation will help you refine your good ideas to make sure that they are painkillers. It's not enough to have good ideas for your products and features and functionalities and services.

Your ideas must solve painkiller problems and not be vitamins because if people just want what you're building, but don't actually need it. You will always have a much harder time getting your customers to use and pay for your product. The number one reason why products and new features for existing products fail to be adopted. It's not because they couldn't be built, but because no one wanted them in the first place. In comparison, it's actually easy to build something I know people always get so stuck on building the product, but that's easy to do in comparison, finding the painkiller ideas that people will be willing to pay you with time and our money and ideally both, that's what's really hard to do.

We call that building a business around your idea, right? Finding something that people will pay for happily. And once you know what the painkiller ideas are, the rest of it is going to be so much easier. Ok. So you would refine your ideas through a process called customer development. Customer development validation will help you address and understand your riskiest assumptions and adjust them if necessary before you build the product, understand specifically how other solutions on the market fail to solve the problem you're trying to solve and identify the exact target market who would be willing to use and pay for your product.

Even if you already have a product in the market with paying customers, maybe there's certain features and functionalities that should be targeted to a segment of your customer. And you really, really need to understand the exact target market. Before you build the solution.

You could be having two types of customers who have the same problem. But the way they need that problem solved could be different. And that's what you're doing in validation is really understanding the nuances around how to solve the problem and build that into the product planning. OK.

So without these details and insights, you will always waste a ton of money recording later because you would eventually learn these insights, but only after the functionality is built. And also a very, very important note is that customer development validation is not about putting together a few surveys or doing focus groups to get these types of valuable insights. You have to follow a very detailed hypothesis testing process by conducting one on one interviews with your potential customers. My customer development process consists of 10 steps and I have over 20 worksheets that I use and follow. So make sure you don't take this step lightly.

And I know so many founders who read all of the books on customer validation, they know all of the terminology, but they either implement it incorrectly or frankly, they don't do it at all because the books don't teach you a step by step process for how to actually do it right.

And how to take those insights and bake them into your product development process. You must focus on testing the right hypotheses and design the interviews in a way that does not lead the user to your solution. In fact, I recommend that you forget about your solution in this validation step. And here's why. So I have a student who's going through my program, who was referred to me by a start up advisor who knows me. And she told her just do what Nelly says. So she came into the program with a clickable prototype. She said, Nelly, I don't need to do validation. I am a veteran in this industry. I've been doing this for 20 years and I know my market in and out and I know that this is the solution that they need. But of course, I pushed her to do customer development. I said forget about your solution and do some customer discovery interviews for a week or two. And if you discover something new, amazing because you can take those insights and bake them directly into the solution, which will save you time and money. And if you don't learn anything new also great because that will give you a lot more confidence that you're headed in the right direction.

And reluctantly she did and she discovered one insight in her second interview that she continued to verify over the next two weeks, that completely changed the solution. She was still solving the same problem for the same exact target market. But she discovered that she needed to do it in a completely different way. And that saved her so much time and money. Imagine her spending two plus years trying to sell a solution that was kind of good but not so good, right? And not even knowing that uh this, this was existing. So I see so many entrepreneurs wasting so much time and money simply because they do, they skip this step. So learn how to do uh work uh this process and or work with someone who can teach you this. OK. So let's calculate how much not validating your ideas is costing you. We make some conservative assumptions. Let's assume that you spend an extra three months of developers time because you've built too much functionality. Let's also assume that you're paying your developer $50 per hour.

And I know we have an international audience, $50 per hour is relatively conservative in the US. So if you're from another part of the world, I want you to plug in a conservative number per hour in whatever country you're from and then redo the calculations. So based on these conservative assumptions, the total wasted amount is $24,000 for each new feature. In fact, the cost of not validating is even higher than our estimated $24,000. Because skipping this step has cascading effects first in a development stage and then in the sales and marketing stage, you will spend extra time and money at every single stage, possibly for features and functionalities that no one will ever use. And for those of you who are not currently doing validation at every single product idea that you currently have in your process, I want you to type 24 K into the chat to let your brain know that this is something you need to focus on. This is your very first action step. And I want you to commit to adding this into your current process. Let's see who needs to work on this type in 24 K in the comments we have uh Vera, I'm just gonna call you Vera type in 24 K. Usually I get a lot more participation. Uh Do we have Julia come on guys jump into the chat, start typing you in like just doing this action is going to help your brain know that this is something that you need to take action on.

So type in 24 K, if this is something that you need to continue to work on post this webinar, and by the way, if you downloaded the workbook, all of your commitments are in the workbook as well. So you can remember what you have committed to as well. All right, let's keep moving. So once you validate your idea, you will need to refine the solution by first building an interactive clickable prototype of the solution without writing any code. And then you'll refine the solution by getting feedback from potential customers.

And these prototypes are so realistic, your potential customers won't even know that it's not real. And I'd like to share a quick demo of a prototype of a mobile app that this is a recording of me using the prototype on my phone. This is a recording of me using the prototype on my phone. As you can see, I can click on buttons and different elements and it feels like I'm using a real app. We're simulating these interactions using prototyping tools. These tools allow us to easily define what elements will be clickable and what the user will see when they click on the hotspot. And all of this is done without writing any code looks very realistic, doesn't it, isn't it? So um let's go through and and understand why you should never ever skip the spec. So here you see a case study of one of my students who is a non technical entrepreneur who wanted to build the application around politics. So this is the prototype that you just saw prototyping helped them uh test multiple solutions before writing any code. And as you can see here, the very first two prototypes that they tried out completely did not resonate with their customers and they got it right on the third try.

And if they had jumped into coding the very first with the first very first guess and an attempt, right, they would have had to rearchitect their entire app later and rewrite a lot of the code. By the way, writing code is a way of prototyping, but it's on the most expensive spectrum and the most expensive way of doing that, remember, it is always a lot cheaper to rapidly change prototypes than it is to rewrite code. OK. So let's calculate how much not prototyping is costing you again, making some conservative assumptions. Let's assume that you spend an extra month of developers time because you've built a solution that doesn't resonate with your customers as much as you had hoped. And as a result, you have to fix things and recode again, pay your developer $50 per hour. The total budget blow based on these conservative assumptions is $8000 for each new feature. And depending on how close you, we're able to guess what solution would resonate with your users.

The cost of recoding can be in the many thousands of dollars. Again, I know so many entrepreneurs who throw away a lot of code simply because they don't do this step. So if you need to work on it, commit to prototyping type eight K in the comments. And I know this question is coming. What are some of the tools that you can use to prototype? Uh Adobe XZ FIG A. Um What else we have? InVision Marvel App Balsamic. There's a slew of to tools that you can use tons and tons of tools on the market, add it and bake it into your current process. Great. We have some bunch of people who committed to doing this action. Excellent. All right, let's go to key number two, plan budget and estimate effectively so that there are no surprises. So this is step number 3 to 7 in my process. Once you refine your idea and the solution, you're not ready to define build and deploy the solution. But instead of building your entire idea, you need to define a minimal viable version of the prototype they created in step two for that idea. By definition, an MVP is the smallest number of functionality that you can launch with that will still provide value to your customers.

But what most people do is think about an AN MVP by reducing the number of features, let's say going from 20 to 4, but that is not enough. And let me show you why have you ever considered or wondered how the same exact project can be estimated to cost $10,000 and $50,000. And both estimates could be completely legitimate. Think about that. Well, that's because the details of what and how you build something matter.

A lot using the many development cost reducing strategies that I teach. One of my students was able to reduce the cost of her MVP from $50,000 to 15 and cut the development time for from four months to two. Can you imagine what it would feel like to get your project costs reduced from $50,000 to 15. Wouldn't that be amazing type? Yes. In the chat. If you would like the cost of your project to be significantly reduced, all of you should be typing. Yes. Right. That's why we're here. Well, here's the problem. The problem is that most developers don't think like this and agencies, if you're working with an agency won't tell you this because the more you build, the more they get paid. So it's really, really important for you to know these cost reducing strategies. So you can work with them and push them to help you reduce the costs of your mvps and push back if they try to tell you it's not possible. Or this is the only way to do something we need to build something that really scales to millions of users when you only have 100 or 1000 or maybe zero. It doesn't make sense. You need to strategically plan things and optimize over time. Your goal is to launch as quickly as possible and refine and iterate from there. And unfortunately way too many technical people fall into the trap of we need to build this perfectly.

I need to use this shiny new technology because I want to learn it and not because it's good for the. But your job as the CEO or product manager is to implement a new way of thinking to make sure that they are not building more than you need to. And in order for this process to work, you must make, they learn early, learn often and learn cheap mindset, a part of your company culture and hire everyone who is willing to work in this way. Otherwise it's not going to work. So let's calculate how much not planning properly and not hiring properly. With the learn early learn often, learn cheap cultural mindset is costing you making some conservative assumptions. Let's assume that you spend an extra three months of developers time because you've built too much functionality and or that you have a three month delay as a result of a higher that doesn't fit into your company culture and it's not working out as well as you had hoped and paying your developer $50 per hour.

The budget below here is 24 to $48,000 for each new release. But in addition to the monetary cost of delays, there's also opportunity costs as a result of being slower market. A lot of you here who cannot get your team to launch things on time and on budget. It's because you are not planning well, steps 3 to 7 are so key to making sure that by the time you get to development, all of the details of what and how you're going to build something are set so that there are no questions and no scope creep. So if this is something you need to work on type 24 to 48 K in the comments in the chat and um to let your brain know this is something I need to work on. This is the mo one of the most like all of these are important. But if you focus on just controlling the costs of um the things that you are building and actually do it on purpose, strategically, you're going to save so much money. Remember the same project can cost $10,000 and it can cost $100,000 for the same exact thing. You can strategically determine what and how you're going to build something. So Julia apparently is the only one who needs to work on this. Thank you, Julia. Come on. You guys. If you really need to work on this, I want you to type and participate in the chat just so that your brain is focused on and knows like you're literally making a thing in your uh brain waves that this is something that's important for you to focus on.

Uh Do you recommend so Jenna is asking a question, do you recommend red lines for building an MVP? You can desco but there may be items you cannot remove. Yeah. So there's many different uh ways to plan the MVP. And I think that really the, the, the reason why validation is so important, it can actually help you determine what, what needs to be included in the MVP that is still going to provide value. What are people going to actually pay you for in order to in that most minimal version? OK. And you're doing this for every new feature and functionality. And I think the mistake that a lot of people make and then we're going to continue to build on this um is assuming that whatever you plan in your MVP, that's it, right. But you are, you have an entire ongoing uh product road map that you're going through over and over and over again and you're continuing to build, build, build, build, build, the key is to iterate but launch something as quickly as you can and then iterate on it, change it as quickly as possible and we'll talk about that in the next steps.

OK? Yes. Uh You definitely need to include the Q A cost and every other cost as well. Great. So let's move on to key number three to use agile project management to see the red flags earlier and to minimize the damage of mistakes. So this is steps eight to not in my process. And this is where we're actually going to write the code and manage the coding process. OK. And there are two different project management processes that you can use waterfall and agile. I of course use agile and in a few minutes, you'll see why. First let's analyze the waterfall project management. So in a waterfall project management, you create your product specifications, you do the design, you code, you test you correct the bots and then you test again and then you deploy the code into the live environment where your potential customers can use and interact with it.

In waterfall project management, you make this big plan up front and then you execute in a linear fashion hoping, hoping that there won't be any changes in the plan. Because once you agree on what is going to be built in your specifications, you can't change what you agree to build even if your business requirements change. And a typical project usually takes at least 3 to 6 months, sometimes a year to deploy. And if our goal is to launch things early and often this process simply won't work for us. We need a way to deploy code more often than every 3 to 6 months. And we need to have a lot more flexibility to be able to adjust the product road map if the need arises. And that's exactly what agile project management offers us. It actually requires us to break up code delivery timelines into shorter periods. Essentially agile consists of a lot of mini waterfalls and each period between analyze and deploy is called a sprint and it shouldn't be longer than two weeks. Agile project management allows us to take break up large and unmanageable projects and split them into smaller, more manageable chunks that can be completed quickly daily, weekly or within two weeks. Maximum. That's the magic of agile project management.

If you discover that something isn't working how it was intended to, then at least you caught it early and you can make the necessary corrections. The mistakes didn't cost you too much time and money and you can get back on track. Fast coding can be expensive. Rico is even more expensive and similar to the waterfall methodology. The requirements of the current sprint that is being executed right now cannot be changed. But all other upcoming sprints can be shuffled around and new requirements can be added to any future sprints and this works really, really well in with the lean way of building products. Let's say you're talking to customers and you're looking at what the market has to say and you discover that something needs a lot more priority than what you currently have in your product roadmap. And so you can shift things with agile, you can have the flexibility to adjust your product road map very quickly depending on how short your sprints are. So if you have two week sprints, you can't, you have to wait two weeks. But if you have daily sprints or even multiple times a day sprints. Imagine how quickly you are learning, imagine how quickly you are launching. And so what I've just shared with you are the principles behind agile.

And from my experience, there are many people who are familiar many more people than the lean way of building products who are familiar with these principles. And they claim to be practicing agile project management, but who are woefully lacking infective processes. And this is where I personally as a fractional CTO spend a lot of times when I go into uh start ups and, and other companies to fix and help and optimize their agile practices to help their teams execute a lot more efficiently. I'll train their leaders, project management, dep teams, Uiuxq a groups, all of them join me to ensure that everyone is on the same page and working with the same set of principles. They're learning a lot of times unlearning a lot of times with one goal to optimize their current process so that their team performs like a well oiled machine. Remember in the beginning, I shared the hypothesis test, learn, revise uh cycles. Well, uh we're doing by, by, by uh getting our team to execute really, really well and shortening our sprints going from two weeks to weekly to even daily to multiple times a day deployment that shortens our learning time. It gives us a lot more data points to make better decisions and what steps to take next, right. Which of course, helps us to refine and iterate a lot faster. So, um I'm going to use an example as an inspiration for all of you guys.

So there's a company called Etsy. I'm sure you've heard all of the about them and they are now a public company, but at 400 developers, they were making 50 to 100 and 50 deploys a day. Can you imagine how finely tuned their process needed to be to do such frequent releases? And what they got as a company are 100 and 50 new data points every single day to make better decisions. They didn't get there overnight. Of course. And that's what I want you to aspire to. So let's uh calculate how much not using an official agile framework and principles is costing you making some conservative assumptions. Let's assume that you spend an extra three months of developers time because you didn't catch the mistakes early enough and you didn't build the functionality correctly. And as a result, you have to find the mistakes that fix things and recode or redo the work and paying your developer $50 per hour, the total budget blow is $24,000. But of course, in addition to the monetary cost of delays, there are also opportunity costs as a result of being slower to market.

So if this is something you need to work on and maybe revisit and optimize your agile practices, if you're already doing agile and think about how can you shorten your release cycles? Type 24 K in the comments. And if you're not using agile, this is your very first thing to do is to switch and figure out how you can make that switch. Ok. So type 24 K in the comments. This is the low hanging fruit that you can add today that will make the biggest impact to your product development process. Excellent, lots of commitments. Thank you guys for participating. Let's keep moving. We have one more key and that is to measure, analyze and refine through rapid iterations.

So this is number 10, step, number 10 in my process. So now that your MVP is launched and is in the hands of your customers. Lots and lots of people celebrate and they say woo we did it. But your work is far from over. And in my opinion now is the time when the real work begins. This is where you will need to implement all kinds of analytics and start collecting user behavior data that will help you learn how your users use your product, what features and functionalities they use the most, what delights them and what makes them frustrated, what brings them back to using your application over and over again and why they might not be coming back as often as you would like, all of these new data points will help you make decisions which one of your existing features needs to be improved and how what new features and functionalities would make your product stickier.

So more and more of your existing customers use your product on a regular basis and also recommend and refer new users to you data driven decision making to improving your product is absolutely transformational because instead of guessing what exact features to focus on, to get more and more of your users to use your product, you will actually have data that will inform you on what next functionality that you should be using and testing and implementing, which will prevent you from spending a lot of resources, building the wrong things.

So in step one, which is validation, we're validating your ideas, riskiest assumptions with a small set of your customers. Here in step 10, we're now scaling our learning with a much bigger subset of our customers from the data that we collect. We will get ideas on how to improve the product. These ideas are, what, what are these ideas that we're going to understand how to improve our product? Are we going to go into step eight and nine and start building them? Because we see that the data is telling us to go build that and that's how we should improve the product or what are these ideas that we need to improve? Who can tell me? It starts with an H Hello anyone. These ideas that we're getting for product improvements are what? Let's see. I'm gonna test you guys. Hm. All right. I'm gonna give you a clue. It starts with an H and these ideas are hypotheses. Yes, Deane. You got it. You got it. Excellent. These ideas are hypotheses. They are assumptions that need to be validated in step one. And then you take those ideas, you build a prototype, you uh determine what and how you're going to build that functionality. And you go through the agile coding process and then analyze analytics. And this is how you go through the 10 steps over and over and over again continuously until you reach product market fit. So let's see how much not using behavior analytics is costing you. The blown budget boils down to a formula.

The formula here is the number of customers you have lost times the cost of the user's lifetime value. Plus the marketing cost of getting your users to sign up to your application. And depending on how many users you lose as a result of not communicating the value of your product of features quickly enough and not improving your product fast enough. The cost can be in the thousands to hundreds of thousands of dollars depending on the variables in the formula.

So let's plug in some conservative numbers here. Let's say you've lost only 100 customers and your customer lifetime value is 100 and $50 and it costs you $50 to acquire these 100 customers that the total amount lost based on these very, very conservative numbers is $20,000.

That's assuming that you've just lost 100 customers. This is how important this step is. So the key here is to never spend a lot of money on marketing until you have increased the retention of your product until you've improved your product enough that you know that when you spend a lot of money on marketing and you bring people in that you're not going to just lose them.

That's called a leaky bucket. OK? So this is a very, very important step. I, I know a lot of start ups struggle with this. A lot of people in general struggle to really understand what specific behaviors they need to track into the app, how to do it and all of that stuff. So if you need to uh and want to use data to improving your product decisions, type 24 K to let your brain know this is something that you should, should invest in learning. OK? Let's see. We have lots of people committing such an important step here. This is a way to scale your learning. OK? Uh Now, let's see, let's do a tally of the total minimum amount wasted or the saving the total minimum savings. If you implement all of the things that we discussed today with an optimized process, right? But if you're not validating, if you're not prototyping, if you're not planning and hiring properly, if you're not using an efficient agile framework not using behavior analytics. Then you are wasting 100 and $24,000 for each new release. If you have one developer, now imagine if you have a team that is bigger, which is most teams, right? The costs go astronomical. So this is the question I want you to ponder why especially as start ups that don't have a lot of extra cash laying around.

Why are we not focusing on optimizing the product development process? Because having an optimized process is clearly a huge way to save yourself from wasting precious cash on something that can easily be avoided and expand your start ups. Uh runway. All right. So um the tech speak test, the process will allow you to learn early, learn often and learn cheap. It'll help you minimize mistakes and miscommunications, minimize missed deadlines and minimize waste and of course, save you a lot of time and money and by learning often you will increase your chances of hitting success again. All of these steps are a part of the process. So make sure that you don't skip any of them. It is the combination of these steps that creates the efficiency and the transparency that you should be looking for. All right. So very quickly, let's do a recap of what we have learned so far and then I'll answer whatever questions that we are talking about. I see a bunch of questions in the chat. So I'm going to address some of those questions. All right. So first we learned that there is a difference between releasing code and releasing code effectively and efficiently to use the lean way of building products to learn faster and iterate to success, to use validation and prototyping to test and refine ideas to use development cost reducing strategies when defining your mvps to reduce the cost and time of development, to implement an official uh efficient, not official, to implement an efficient agile framework to see the red flag sooner and to minimize mistakes and finally to use data driven decision making to improving your product.

So I'd love to know which one has been the most valuable for you so far. Number 123456 all or what combination of the six. And uh as you guys are doing that, I am going to share some of the resources for next steps. So Julia says six, great to use data driven decision making lots of threes which is validation of prototyping, uh sixes and threes and fours. Uh Excellent. I'm glad that you guys got uh very specific things that you can then now work on in your processes. So if you're resonating with me, if you'd like to take it to the next step and uh want to learn exactly how to do this process. I have an entire training that I've, it's called Tech Speak for Entrepreneurs Academy. It's um a tech speak curriculum. Of 10 modules. There's an exclusive offer in the workbook that you've downloaded and you can learn this process in just two days. If you want to learn how just go to the tech speak website, there's a video that explains how all of that is can be learned in just two days. Um So, uh if you have not downloaded the workbook, you can still do it. It's tech, speak.co forward slash women tech And you can have all of the, a lot of the concepts that are summarized are all in there and there's also the uh exclusive discount link there as well. Um Other things that you can learn from.

So there's uh three other master classes that I've created how non tech is, can launch successful tech start ups, how to build an MVP without a technical co-founder and how to reach product market fit quickly. That's a live class that I'm doing tomorrow actually. So go to tech speak.co forward slash classes and um you can register for those. So with that, I'm gonna take some questions. Uh let's see. Uh Begay is asking, can you explain and let me know about LTV. So LTV stands for uh life uh lifetime user, lifetime value. So uh this is where you need to determine how much uh value that a customer brings to you in terms of money over the lifetime that they are a customer with you. And you have to calculate that based on the different types of products that you have. So an example that I'm gonna give you is in the dating space. Uh So in dating, you can say, well, you know, based on our patterns, uh a customer is uh with us for about four months and then they find a partner, they go and date them and then in four months because they broke up or whatever they come back to the app, right? And so you use lifetime value to determine how much money you can use to acquire a customer. OK.

So these are things that you need to understand the metrics that you need to understand so that you can uh effectively understand how much money you can use to acquire customers. And you always want your customer acquisition cost to be lower than the lifetime, the user lifetime value.

OK. Hopefully, that helps. Um And if you're interested in metrics in the webinar that I'm doing tomorrow on uh how to reach product market fit quickly, we'll talk a lot about these metrics there as well. Let's see if you have questions, feel free to type them in and I'm going through and addressing them right now. Um Let's see, uh Barbara is asking hypothesis. What do you mean by that? So hypothesis is a an assumption that you wanna test. So if you think of um like a uh a scientist, right? If you want to run an experiment, you would make an assumption that, hey, what I'm assuming is, is this and then you go out and create an experiment to test that. That's what hypotheses are. And so when you're doing validation, your questions need to be connected to the specific hypotheses that you're testing. So just asking random questions to your customers is not how it works. You want to be very strategic to gather the information and you never want to lead the user to any specific solution, right? The whole idea behind validation is to discover insights that you didn't know before. And so you wanna ask hypothesis driven questions to get uh to, to derisk your assumptions essentially because the more you know, before uh you build something, the more likely you could just take those insights and bake them into the product and less likely that you are to redo things later, which is where we are cutting a lot of the costs.

So, um I, I think we are done here. I see some, somebody else joined the session. Um Any other um last minute questions that I can answer for people, I'll take one more and then um I look forward to uh connect with me on linkedin or anywhere else and I'm happy to answer additional questions. I also do uh frequent Clubhouse live uh events where I answer questions. So if you didn't get your question answered, definitely um jump in. Um All right. Thank you guys so much. Hopefully, this was helpful. To you. Uh, and I look forward to supporting you guys in the future.