How to Cut Startup Product Development Costs Up to 50%, with Nelly Yusupova

Welcome everybody. Uh, I believe we started the webinar here. Welcome everyone to today's event, How to Cut Startup Product Development Costs by Up to 50% with Nelly Yusupova. My name is Dustin Betz. I am the content and community manager here at the Founder Institute. Okay, great. I see people are trickling in and joining us now. For those who don't know Founder Institute, we're the world's largest pre-seed startup accelerator. We've helped launch more than 6,000 portfolio companies today across more than 200 cities around the world. And we have the largest startup mentor network in the world with more than 21,000 mentors involved across all of our chapters. So if you're interested in learning more about the Foundry Institute, we're currently enrolling for virtual first accelerator cohorts across all 6 continents. And you can see that list of enrolling programs at fi.co/enrolling. So onto today's topic, one of the biggest challenges that early-stage founders face when building their startup is basically how to, how to build and deliver a product on a limited budget. You know, even if you're in the relatively earlier stages developing an MVP project, you can often encounter budget overruns, often due to a lack of prior planning or communication on parts of different parties involved, lack of technical knowledge or certain specific skills. So if you'd like to learn ways to develop your products successfully without breaking your budget, then you're in the right place. And that's because today's guest is going to be sharing ideas on how to manage teams to deliver projects on time and on budget. So thank you everybody for joining us today. It looks like, yeah, we have now more than 70+ people in the audience. I see from Toronto, from Hong Kong, from Medellín, Colombia. So yeah, fantastic to have people joining us internationally, founders from all around the world. Basically, I'm gonna give a really brief introduction to our guest speaker here, Nili Yusupova. I'm gonna turn the floor over to her. She's gonna speak for around 40-ish minutes and give the talk, and then we'll have time at the end for Q&A. But if you do have questions, don't hold back. You can ask questions at any point throughout the event. My producer in the background here from Founder Institute, Veda, is gonna help collecting your questions throughout the event so that then when we get to the Q&A, we have all of your questions queued up to ask. Nelly. And then after the event, so after the Q&A ends, we'll also have some open networking in a virtual lounge on Airmeet where everybody can hang out afterwards to meet face-to-face. So without further ado, our featured speaker for today, I mentioned, is Nelly Usapova. She is a startup tech advisor, a fractional CTO, and the creator of TechSpeak for Entrepreneurs. Her work helps entrepreneurs minimize their technology mistakes. So in part, she does this through her masterclass at TechSpeak for Entrepreneurs, where she provides a learning roadmap to successfully manage technology teams and projects. She was also recently included in Fast Company's League of Extraordinary Women, and she's been named by the Wall Street Journal as a woman in the IT fast track. So, Nelly Usupova, thank you so much for joining us today.

Absolute pleasure, Dustin. This is part 2 of our session today, and I think the first session is available for recording, correct, Justin?

That's right. Yes, yes, we have it up on our YouTube channel. So if folks go to fi.co/youtube and then go over to the webinars tab, yeah, they should able to watch the part 1 if you didn't do that before, but hopefully they can also jump in and yeah, we're so pleased to have you for part 2.

Absolutely. So this is part 2, but it is a standalone workshop. So if you've missed part 1, you still should be okay here, but we cover the same similar topic but from a different standpoint. So if you're a non-technical founder and you want to learn how to earn a technical co-founder, go watch that other session because that's the focused on how to build an MVP without a technical co-founder. So that's an interest topic, a topic that you're interested in, go and watch that first session. This session is focused on product development. I, as Dustin mentioned, it's the biggest problem that entrepreneurs have, whether you're just starting out or you're already in development and have been in business for 10 years. Launching things on time and on budget is probably the biggest challenge that a lot of teams have. So today I'm going to be sharing with you how, how you can make the shift from struggling to launching your products on time and on budget to successfully managing teams and projects and save up to 50% on your product development costs in the process. I'm going to be sharing a process that I personally use This is a— for those of you who possibly walked in late, there's a workbook that goes with this session. I created the workbook, summarized a lot of the concepts that we're going to be talking about, so you don't have to take a lot of notes. I want you to stay present. I want you to participate in the chat, which hopefully you will all do, because the more present you are, the more you're going to get out of this session. And guess what? I'm talking to a screen here. And the only way I know you guys are with me and are paying attention and are getting it is through the chat. So when I call it out and I ask you guys to commit, those are going to be your action plans. If you guys get to know me, or when you guys get to know me, I'm very, very action-oriented, and I want you to attend an event, understand what specific actions that you need to take, and actually take action on them. So that's why I'm going to be asking you to commit to different things. I want you to actually get a lot out of this session. All right, so let's keep going. Here's the link to the workbook again, so you— if you don't want to type it in. But let me see, make sure I can shift and change. Okay, so for those of you who don't know me, I'm a CTO and a startup tech advisor. I created TechSpeak for Entrepreneurs, which is an online program where I teach the most efficient and effective ways for managing teams and projects. And, and what's most important for you to know is that I have managed teams and projects over— for over 18 years, and I've refined and optimized my process over time. And I taught this process to over 1,200 students so far and worked with hundreds of different startups, helping them with their tech strategies and help them fix and optimize their processes. So this is where we're going today. First, we're going to learn what is a process and why a good process is simply not enough. Then we're going to learn the difference between the lean versus the classic way of building products, 2 money-saving things that you should do before you build anything at all, how to define your MVPs properly to reduce the cost and time of development, how to see the red flags sooner and minimize mistakes. And then I'll share briefly how you can work with me, and then we'll go into the live Q&A. So as Dustin mentioned, drop your questions into the Q&A. They will be collecting them, and I'll answer most of the questions at the end. If you have something urgent, do type that in, and we'll try to get that. I'm going to keep an eye on the chat, but I want to be able to move things quickly, so we are going to move pretty quickly through this so that we can cover the content, and then we'll get into the Q&A session. Also, a very quick note: I will be teaching you all of the concepts from my experience of working with different startups and advising tech startups for many, many years. And I've developed this process. I call it TechSpeak for Entrepreneurs. I'm gonna be teaching that process to you, but I'm gonna be mentioning TechSpeak a lot because that's the name of the process. So in my presentation, when I'm referring to TechSpeak, it's the 10 steps that you can learn and actually take the information and improve whatever your current process is so that you can save a lot of time and money doing that as well. All right, so let's start. So what is a process? A process is a series of steps which, when followed diligently, will give you the same result no matter who performs them. It is a repeatable way to produce consistent results over and over and over again. And a good product development process is very important because it creates transparency throughout all of your projects 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's 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 are releasing code all the time. They're launching new features and improving existing features. But if they're not using the 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 this is Eric. He's a student of mine. He had a software startup for 3 years before he learned the texting process. He had a tech team, he had a CTO, and this is what he said after 3 years of running a software startup. He said, after 3 years in business, Textpeak could have saved us close to half a million dollars in delays, development costs, and sleepless nights. I'm gonna let you absorb that for a minute. Half a million dollars in a span of 3 years due to delays, development costs, and sleepless nights. And that is 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 do not rely on developers to come up with a process. 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 process based on lean and agile methodologies. Very few big companies are actually using these processes because they're inherently big and can't move quickly and efficiently, as we will learn today. As you remember, Eric, the story that I just shared with you, he had a tech team and a CTO. He had a team of developers, and they weren't using an optimized process based on lean and agile methodologies, which of course meant that they lost almost half a million dollars over 3 years due to inefficiencies and delays. So now that we know how important an efficient process is, let's learn the TechSpeak 10-step process and see how it can save you time and money by allowing you to see the red flags sooner catch mistakes earlier, and most importantly, minimize the effects of mistakes. Because it's unrealistic for any of us to never make mistakes, no matter how good your processes are. And I'm going to teach you an amazing process today, but no matter how good your process is, it's unrealistic to expect that you won't ever make any mistakes. The key is to catch them sooner, because the sooner you can catch the mistakes, the sooner you can address them, which of course will minimize the effects of the mistakes. So before we learn the process, there are two core pillars in my product development process that we need to learn about to make sure that this process is going to work. So the first pillar is learn early, learn often, and learn cheap. And the second pillar is executing ideas the lean way. For startups, especially early stage ones, learning quickly is really, really important because the faster you learn something, the faster you will learn if you're headed in the right direction. You don't want to spend 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? Well, let's consider the classic way first, because that's what most people 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 it, the possibilities, the more incredible and flawless your idea becomes, and the more excited you get. Raise your hand or say yes in the chat if you are guilty of this. Most of us are because we fall in love with our ideas. Right. The more you think about your brilliant idea, the bigger and the more flawless, the bigger the possibilities that you paint, right? Your imagination runs wild. So what do you do? You put all of the resources behind building this amazing functionality that will change absolutely everything. And you spend 2 to 6 months to a year building it in secret. Because you don't want anyone to steal your idea. And then you launch. So you've just committed 6 months to a year or even more of time, money, and resources, and then you get feedback. So you may have hit it on the nail, and it may be the amazing success that you imagined it in your head, but what most often happens is that 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. This approach is like shooting arrows at a target with blinders on. It is a big bet, and it's very, very high risk. It's slow to market, it has zero customer validation, and it's very, very expensive. So on the other hand, we have lean, using scientific methodology of hypothesis, test, learn, revise, to discover what works with a lot less waste. In a lean process, every single brilliant idea that you have is actually a hypothesis. 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, revise, hypothesis, test, learn, revise. And the goal of your team is to minimize the total time through the loop by 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 startup is a series of well-designed experiments that you're constantly testing so you can adjust your path to success. And this is the key. 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 is going to work or not, you are taking small steps to get to success a lot faster. Type yes in the chat if you see why these two pillars are necessary to getting to success faster without wasting time and effort going in the wrong direction. If you don't agree that these two pillars are the way that you wanna work, everything I'm gonna teach you for the rest of the session is not going to work. Okay? These are the foundational elements that you as the startup founder, the CEO, and the person who is running your company has to build these two pillars into the culture of your company. Otherwise, everything I'm going to be teaching you is not going to work. Excellent. So we get lots of yeses. Thank you guys for participating. I appreciate it. So let's keep moving. Let's actually learn the process. For those of you maybe who came in late, there is a workbook that you can follow along with. I'm going to drop the link again for you to download if you haven't done that, so you don't have to take a ton of notes. I summarized all of the concepts for you there. Okay. So let's go into the— let's talk about the 4 key things in my process that allow me to manage teams and projects successfully without wasting thousands of hours. Okay. So key number 1 is to don't build anything until you refine the idea and the solution. This is the first step. In the tech speak process, because no matter how good your team is, whether they're in-house or outsourced, you will always waste your 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 all of your ideas to make sure that they are painkillers. It's not enough to have good ideas for your products and features and functionalities. Your ideas must solve painkiller problems and not be vitamins. When I say painkiller problems, it's not level 5 or 6 or 7 problems. It is 12 out of 10 problems, right? Those are the painkiller problems. Because if people just want what you're building, but don't actually need it, truly need it, you will always have a much harder time getting your customers to use and pay for your products and services. The number one reason why a lot of 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. Finding that painkiller idea that people are willing to pay you with time and/or money, and ideally both, is what is really hard to do. And once you know what the painkiller ideas are, the rest of it, building the product, is going to be so much easier. And you would refine your idea through a process called customer development. Customer development validation will help you address and understand your riskiest assumptions and adjust them if necessary. It will help you understand specifically how other solutions on the market fail to solve the problems you're trying to solve and identify the exact target market who would be willing to use and pay for your products and services. Even if you already have a product in the market with paying customers, maybe there are certain features and functionalities that should be targeted to a segment of your customer base, and you really need to understand the exact target market before you build the solution. Let's say you have two different segments of your customers. Even though they may have the same problem, the way you need to solve that problem for two different markets may be completely different, right? And so knowing and understanding these nuances before you build a product is what we're doing in the validation step. It'll help you save so much time and money. Without these details and insights, you will always waste a lot of money recoding later because you would eventually learn these insights, but only after the functionality is built. And also a very, very important note 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 potential customers. My customer development process consists of 10 steps, and I have over 20 worksheets that I use and follow. So make sure that you don't take this step lightly. And I know so many founders who read a lot of books on customer development and customer validation. These are not new concepts. 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 actually teach you the step-by-step for how to actually do it right. You must focus on testing the right hypotheses and design the interviews and the questions that match the hypotheses. It's not just asking questions, it's asking the right questions that really matters. And this is the big mistake that a lot of founders make, is that they lead the users to your solution. You are so in love with your solution. You focus so much on the solution and not the problem. That you are going to ask the questions in a way that, you know, will basically help your customers agree, or potential customers agree, that that solution needs to exist. In fact, I recommend that you forget about your solution in the validation step, and here's why. So I have a student who's going through my program right now, and she was referred to me by a startup advisor who knows me, and she literally just told her Just do what Nelly says. And she came in with a prototype into the program. So she's just— she was just starting out. She said to me, Nelly, I don't need to do validation. I'm 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. 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, great, 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 just one insight in her second interview that she continued to verify over the next 2 weeks. That completely changed the solution. She was still solving the same problem for the same exact market, but she discovered that she needed to do that in a completely different way. And that, of course, saved her so much time and money. Imagine her spending, wasting 2 years of her life trying to sell a solution that doesn't really resonate with customers, and she wouldn't even know why, right? Learn how to do this process properly. And don't lead your users to your solution. Fall in love with the solution— don't fall in love with the solution, fall in love with the problem. Okay. So let's calculate how much not validating is costing you. We'll make some conservative assumptions. Let's assume that you spend an extra 3 months of developers' time because you've built too much functionality. Let's also assume that you're paying your developer $50 per hour. $50 per hour is a very conservative number to pay per hour a developer in the United States. If you're from the outside of the United States, plug in whatever conservative number that you're paying, or you could be paying for your developers in whatever— in your country, whatever country you're in, and then recalculate some of these, but it's still going to be pretty high. Okay, so based on these conservative assumptions, the total wasted amount for each new feature is $24,000. In fact, the cost of not validating is even higher than this estimated $24,000 because skipping this step has cascading effects. First in the 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 on every single product idea that you have in your current process, I want you to type 24K into the chat to let your brain know that this is something you should be focusing on. This is your very first action step. So commit to doing validation properly. Type 24K in the comments. And by the way, your workbooks, Have all of your commitments there so you can have something that you can refer to. So type 24K if this is something you need to look into, work on, and this is going to be the most important step in your product development stage. Because a lot of people, if you don't get this step right, as we just discussed— discovered, it's just a cascading effect downwards. You will build a lot more technology, you will build products that no one wants, and so ultimately waste a lot of money. So Getting this step right is the most important. All right, on to step number 2. So once you validate your idea, you'll need to refine the solution by first building an interactive clickable prototype of the solution without writing any code. And then you will refine your 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. So I'm gonna quickly play a demo for you so you can see how realistic these are. 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? This is a recording of— Okay, so sorry that the volume was a little bit low. Hopefully you guys heard all of that. The whole idea was for you to see how realistic these prototypes are. And the reason why you should never skip this step is because prototypes are— because they're so realistic, allows you to test multiple solutions before you write any code. So here You'll see an example of one of my students who went into prototyping, and their first two versions of their solutions completely didn't resonate with their users, and they got it right on the third try. And if they had to— if they actually went in and started building whatever they thought was the right solution right out of the gate, they would have to re-architect their entire app later and rewrite a lot of the code. Remember that writing code is actually a way of prototyping, but it's the most expensive way of doing that. And it is a lot cheaper to rapidly change prototypes than it is rewrite code, which is why in the beginning, I want you to test a lot of your ideas in the prototyping stage. These are not no-code solutions. These are drag and drop solutions. So things like Adobe XD or Figma or Balsamiq or InVision, lots and lots of different tools. They will allow you to rapidly iterate on the solution with your potential customers before you build. Okay, everybody still with me? Type yes in the chat if you're still with me. Just want to make sure that you guys are all following. Excellent. Okay. 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 customers as much as you had hoped. And as a result, you have to fix things and recode. And you're paying your developer $50 per hour. The total budget blow is $8,000 for each new feature. And depending on how close you were able to guess what solution would resonate with your users, the cost of recoding can be in the many thousands of dollars. And I know so many entrepreneurs who throw away a lot of code simply because they don't do this step. Okay, so let's do your second commitment. Commit to prototyping. Type 8K in the comments if you need to revisit this, if you need to start doing prototyping and adding it into your product development process. So type 8K and commit to doing this step. Great. Love all the participation in the chat. Thank you guys. And all right, let's keep moving. So key number 2 is to plan, budget, and estimate effectively. So there are no surprises. So this is steps 3 to 7 in the tech speak process. So once you've refined your idea and the solution, you're now ready to define, build, and deploy your solution. And instead of building your entire idea, you need to define a minimal viable version of the prototype that you created in step 2. By definition, an MVP is the smallest number of functionality that you can launch with that will still provide value to your customers. But simply reducing the number of features that you launch with from, let's say, 20 to 4 is not enough. That's what most people do. They say, okay, we have this product, we have this idea, what's the minimal viable version of this? And they cut down the features, but that's not enough. Let me show you why. Have you ever wondered how the same exact project can be estimated to cost $10,000 and $50,000, and both estimates could be completely legitimate? 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,000 and cut the development time from 4 months to 2 for a brand new product. Can you imagine what it would feel like to get your project costs reduced from $50,000 to $15,000? Wouldn't that be amazing? Yeah, it would be. That's why we're all here. Well, here's the problem. The problem is that most developers, they don't think like this. And if you're working with an agency because you're outsourcing, They 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 your team and push them to help you reduce the costs of your MVP 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 1,000, 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 this trap of, we need to build this perfectly. I need to use this shiny technology that I'm really, really interested in learning. But your job as the CEO 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 learn early, learn often, learn cheap a part of your company culture and hire everyone who is willing to work in this way. Otherwise, it's not going to work. Okay. So this is a really Really important point here. 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 3 months of developers' time because you've built too much functionality, or that you have a 3-month delay as a result of a hire 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 blow here is $24,000 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 to market. A lot of you here who can't get your teams to launch things on time and on budget is because you're 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 there are no questions and no scope creep. So type 24 to 48K if you need to work on planning and hiring better and set a company culture with this mindset. Commit to doing that right now. And we will move on to key number 3. $24K to $48K. Lots of people should be typing this. This is a big, big thing that I see a lot of startups completely miss on, okay? Not being able to plan properly before they get into development consists of the biggest majority of projects not being delivered on time and on budget and getting out of scope. Okay, great. All right, let's go to key number 3: use agile project management to see the red flags earlier and minimize the damage of mistakes. So this is steps 8 and 9 in the TechSpeak process. So this is where we're actually writing code. 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 waterfall project management, you create your product specifications, you do the design, you code, you test, you correct the bugs, 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 a big plan upfront and then execute in a linear fashion hoping that there won't be any changes in the plan. Because once you agree on what's going to be built in your specifications, you actually cannot change what you agreed to build, even if your business requirements change. And as we know, a typical project takes at least 3 to 6 months and 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 more often than every 3 to 6 months, and we also need to have a lot more flexibility to be able to adjust our product roadmap if the need arises. So that's exactly what agile project management offers us. It requires us to break up big 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 2 weeks. Agile project management allows us to break up large and unmanageable projects and split them into smaller, more manageable chunks that can be completed quickly, daily, weekly, or within 2 weeks maximum. And that's the beauty, the magic of Agile project management. If you discover that something is not working how it was intended to, then at least you caught it early and now you can make the necessary corrections. The mistake didn't cost you too much time or money, and you can get back on track fast. Coding is expensive. Recoding, believe me, is even more expensive. And similar to the Waterfall methodology, the requirements of this sprint that's currently being executed 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 with the lean way of building products. Let's say you're talking to customers, you're looking at what the market has to say in your customer validation step. You discover something that needs a lot more priority than your current product roadmap says, right? And so you need to shift your current product roadmap. And with Agile, you have the flexibility to adjust that very quickly depending on how short your sprints are. So what I've just shared with you are the principles behind Agile. From my experience, there are many, many more people who are familiar with these principles. They claim to be practicing Agile project management, but who are woefully lacking ineffective practices. And this is where I personally spend a lot of time when I go into startups to help fix and optimize their agile practices, to help their teams execute more efficiently. I'll train their leaders, project managers, dev teams, UI/UX people, QA, all of them need to join me to ensure that everyone is on the same page and is working with the same set of principles. They're learning a lot of things and a lot of time unlearning a lot of things 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 cycles that we're doing? By getting your team to execute really, really well and shortening your sprints, going from 2-week sprints to weekly sprints to daily sprints, even multiple times a day sprint deployments, that shortens your learning time. It gives you a lot more data points to make better decisions with what's— what to do next, right? What steps to take next, which of course helps you refine and iterate faster and more efficiently. There's a company called Etsy. I'm sure most of you have heard of it. And this is the most amazing story. At 400 developers, They were making 50 to 150 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 150 new data points every single day to make better decisions. Of course, they didn't get there overnight, and that's what I want you to aspire to, okay? So let's calculate how much not using an efficient agile framework and principles is costing you. Making some conservative assumptions, let's say you spent an extra 3 months of developers' time because you didn't catch the mistakes early enough and you've built functionality incorrectly. And as a result, you have to find the mistakes, fix things, recode, and redo the work. And paying your developer $50 per hour, the total budget here 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 type 24K if you need to revisit and optimize your agile practices. Type 24K, this is your action step to take after the webinar. Again, your workbooks have all of your commitments in there, so you know what you need to do. Merlin, type in 40, 42K. Absolutely. A lot of people. Now, this is, this is something that you need to realize. All of these costs are for one developer, right? One developer. How many teams that you know are actually one developer only? Very few, right? So the more people you add to this process, the more astronomical these costs are. So these are very, very conservative, conservative assumptions and numbers here. So, but you quickly see how expensive these mistakes are. All right. On to key number 4: measure, analyze, and refine through rapid iterations. So this is step 10 in the TechSpeak process. Now that your MVP is launched and is in the hands of your customers, lots and lots of people celebrate. They say, woo-hoo, we did it. Let's go out and drink, right? But your work is far from over. And in my opinion, now is the time when the real work begins. So this is where you will need to implement all kinds of analytics and start to collect user behavior data. And 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 like. All of you— all of these data points will help you make decisions. Which one of your existing features need to be improved and how? What new features and functionalities would make the 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 a 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 testing and implementing, which of course prevents you from spending a lot of resources building the wrong things. So in step 1, you are validating your ideas' riskiest assumptions with a small set of your customers. Here in step 10, we are now scaling our learning with a 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? Who can tell me? The ideas that you get from the data that you collect are— are those ideas that you're going to take and start building and coding and go to step number 8 and 9? Or what are those ideas? Who can tell me? It starts with H. Type your answer in the chat. Let's see who is going to get there first. Jonathan, you win the prize. Hypothesis. Yes, these are hypotheses. These are our hypotheses. They are assumptions that need to be validated. Back to step number 1. And this is how— and then you go to prototyping, preparing for development, etc. And this is how you go through all of the 10 steps over and over and over again until you reach product-market fit. Okay, so hopefully you guys can see the, the entire flow of the process and how to use all of these steps and how they are connected. Each step in the process feeds the next one. Okay, all right, so let's see how much not using behavior analytics is costing you. The blown budget, it boils down to a formula. The formula is the number of customers that you've lost times the cost of your user's lifetime value plus the marketing costs of getting the user 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 or features quickly enough and not improving your product fast enough, the cost can be in the many thousands of dollars. Depending on the variables in your formula. So let's plug in some conservative numbers here. Let's say you lost only 100 customers and your customer lifetime value is $150, and it cost you $50 to acquire these 100 customers. Then the total amount lost based on these very conservative numbers is $20,000. That's assuming that you only lost 100 customers, right? This is how important this step is. So if you need to work on this step, commit to using data to make product improvement decisions, type 24K in the comments, because this is the step that you're going to use to scale your learning. This is what you should be using, not just customer validation, But both customer validation, which is where you're going to be talking to customers one-on-one. But this is how you're going to scale your learning and improve your product really, really quickly. All right. Lots of commitments. Thank you, guys. All right. So let's see the total minimum amount wasted or saved, saved, right? Depending on how you look at it. If you implement all of the things that we discussed today with an optimized process. So 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, if you're not using behavior analytics, then you are wasting $124,000 for each new product release. And again, this is for one developer. Think about how astronomical these costs are going to be if you have more than one developer. So this is the question I want you to ponder: why are you not focusing on optimizing your product development process? As a startup, you have very limited funds. Instead of constantly being in fundraising mode, if you understand how to optimize your processes, how to get your team to function more effectively together, then you can save thousands of dollars, be a lot more capital efficient, and not have to have— not have to be in constant fundraising mode because you need more money to sustain yourself. This is really, really important. The 10-step— the TechSpeak 10-step process will help you 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 so much time and money. And by learning early and 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 all of these steps that creates the efficiency and the transparency that you should be looking for. Okay. So with that, let's pause and review all of the different things that you've learned so far. So first, we learned that there is a difference between releasing code and releasing code effectively and efficiently. We then learned the lean way of building products, 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 efficient agile framework so you can see the red flags sooner and minimize mistakes, And finally, to use data-driven decision-making to improve your product. And I'd love to know from all of these ideas, what has been the most valuable for you so far? Number 1, 2, 3, 4, 5, 6, all, or what combination of the 6? Boyega says all. Great. Felipe says 3, validation and prototyping. So, so important. 2 and 3, uh, to think about the process before building. All 4s, 3s, 3, 5, 6. Great. Uh, 2 and 3. Great. There's going to be a recording, Linda. Absolutely. Um, very cool. Well, this is, this is great. Thank you guys for sharing. Thank you for participating. And for those of you who want to get the exact steps for how to you actually implement this process, I have created a resource for you. It's called TechSpeak for Entrepreneurs. Go check it out at techspeak.co. It consists of 10 modules, one for every step in the 10-step process that we talked about. We have an exclusive FI discount that is also in your workbook. So if you downloaded the workbook, It's there. You guys get an exclusive discount, $300 off, plus an extra month of group coaching that's included in it. So check it out and learn more about the program if you want to get all of the processes, all of the stuff kind of handed to you step by step. And for those of you who haven't downloaded the workbook or still need it, you can download it here. And let's take some questions. Dustin, I'm ready.

Yes. All right. Let's see. Yeah, I want to turn it right over to questions that Veda has been queuing while you were presenting, because we do have a good amount of them. And so I guess the first category of questions that I'm seeing here is really around the prototyping and testing. And so I really like Rami's question here. I think I sort of have an answer, but I'll pose it directly to you, which is, how does one approach prototyping when the user is needed even for the first iterations. And so I guess this would go back to kind of point number 1 in your list. But yeah, thoughts on doing those one-to-one interviews when the user is really needed even for the earliest iterations?

Yes, absolutely. So what we're talking about here, it's such a great question because most people are conditioned to think of the solution first. So you have your, your, your idea hit you, and the first thing you think about is, okay, this is what I'm going to build. This is what the product is going to look like, right? And what I'm telling you is forget about that. Okay, so your idea hit you. Go and actually make sure that there is a market that is willing to pay you for that idea. Make sure that it's not a level 5, 6, or 7 problem. but it's a level 12 out of 10 problem. That's what we call the painkiller idea. And when you go and do that, you might take your good idea and refine it to be amazing. And through that process, you're actually understanding who is the exact customer that I should start with, how to market to them, right? You're actually doing a lot of customer acquisition. You're actually understanding marketing to them, right? And all of this work you're doing before you build anything. Once you understand the problem really well, you'll know exactly what the solution is. You won't even have to guess or think, right? Because you will be able to build the exact solution based on the problem that you, that you have done. And by the way, I did mention in this training, I mentioned in the first training, I had students who just did the first 2 steps and they were able to go and sell the solution without having a product, right? So If you do this effectively and efficiently, you will be able to know exactly who your customers are from the first step. And so when you have the prototype, you're going back to the same customers that you've interviewed already, plus some other new customers that you will find because you now know who is the type of customer you're going after, who is going to be willing to pay you with time and money for. And that's really how you're going to know who to show the prototype for. But don't stop— don't start with the prototype. I know it's it's so sexy or so exciting to actually work on the product. But if you do your work in part 1 and actually understand the problem so much better, the nuances around the problem, you're gonna be way better off.

Yeah. Yeah. I love that advice. Yeah. Make validation sexy again, right? Like it's not just the prototype that is the sexy thing. Yeah. I think that's a really important kind of learning, especially for those steps 1 and 2, which are, you know, the anchor for the other 8 that follow it. A related question here that Yenga asked is, should the people who test your product be innovators or a sample of the general population? The answer is that the people who test the earliest or you're doing your validation with should be your target customers. I think that we've kind of hit that over and over, but wanted to knock out Yenga's question there too. There's a couple of questions, I guess, around— and this pertains to part 1 where we dropped the link people can go back and watch the video, but Felipe is asking, you know, who should create the prototype? Is it the product owner, like an IT team? And Lulu asked a similar question. How do we find someone to prototype for non-technical founders? So I know you covered this more in part 1 and people can go back and watch that on YouTube and we'll drop the link, but yeah, just kind of any thoughts around those 2 questions in the prototyping, especially for non-technical founders?

Yes, absolutely. So they— there are 3 things that I teach you, or there are 3 roles that you need in to run this process. Okay. There's a product manager, there's a project manager, and there is someone who can run that, that whole process, right? So if you're not technical, you also need to be technically literate. So the— all of those things we discussed in part 1. So if you want to learn that, jump in that. But the product manager is the person generally who is interacting with the customers. They're doing the customer validation interviews, and they are essentially building the product. If depending on how early you are, right? Like if you're a strappy founder who's just starting out, you don't have money to actually pay somebody else to do product management. So you're doing that work. So you have to learn this. If you don't have the money to pay a UI/UX designer to build a clickable prototype, You can do this. I teach this to my founders. You can learn how to talk to customers very easily. And by the way, I think every single company founder should be the product person early on because it'll help you understand and connect to your customers, really understand the problem and how to solve that really well from the beginning. And of course, then as you start to grow, you'll have dedicated people who will run that role for you. But what I find, and the reason why I teach this to founders, is because in the early days, you just don't have the funds to pay full-time people to do that work. And that's something that you can easily learn. And the project manager usually focuses on steps number 8, uh, 2 through 8, through 2 through 10, right? So this is where you're running the project and making sure that what you guys have agreed to build is actually executed properly. Okay? So hopefully that answers that question.

Yeah. There's a couple of questions here around sort of definitions and Agile methodology. And so this question is also from Lulu. It's about just recommended tools. She asks, "What is the best product management platform for Agile? Do you have tools that you recommend for implementing this kind of structure?" Yeah.

So, To me, the tools actually don't matter. You can have the best tools on the planet, but if you don't have a really good process for how to manage all of the different pieces, the tools will not make you better. Okay, just— I just wanted to underline that. So you have to have a process to be able to manage the project first. So some of the tools that you can use is Trello, the simplest one. You can use any project management tool like monday.com or ClickUp or Notion, any of them are pretty much the same. What they're missing is a process, which is why I always say to people, the tools don't matter. You can— I've seen people do really good product project management with Excel spreadsheets, right? It doesn't matter what you use as long as you have a really good, efficient process for how things get actually done. And that every one of your team members actually knows what to do and when, which is what a good process allows you to do.

Yeah, there's two kind of questions here from Body Doubler, presumably your pseudonym in the chat. One question, the person asks, most early startups have small teams, less than 5 people. Does that change the Agile deployment at all? I guess just working with a really small team, And then the other question that they asked was, should we use the same beta testers every time or should they ideally be different? And so I guess that would be towards the end when you're getting down to 8 and 9 and deployment and then your analysis in step 10. But is it, yeah, is there, I guess, strategic advantage of, I guess I posed two very different questions. So, okay, yeah, go for whichever one you want.

I'll take them both. So the first question, should you be using different agile practices if you have a small team? The answer is absolutely not. The whole idea behind agile. So number one, if you're not using agile, why? Why not? Right? Like, this is the first thing you need to do is switch. You're going to reap so many benefits from just taking your waterfall methodology and releasing every 2 weeks. For me, even every 2 weeks is slow. What I'm suggesting is that you release or you get your time, you tighten up your team and your process so much that you are able to release multiple times a day. Because as we talked about, the more often you release, the faster you are learning. And it doesn't matter whether your team is 20 or 100, right, or 2, you should have this mindset of the sooner we launch, the sooner we're learning, right? Learn early, learn often, learn cheap. Write it down on, on, and paste it somewhere on where you can see it constantly, because it's a mindset, it's a philosophy of how you make decisions and how you are iterating. There's a concept I talked about as increasing product velocity, right? They being able as a team to be able to work together, all of your teams marketing and sales and business development and your product team and your developers, all of you being able to iteratively work together and improve the product, improve your marketing, improve your value proposition, all of that at the same time, that's when you're going to be able to reach product-market fit quickly, which is why the sooner you launch, the faster you will learn. And the last question about— sorry, What was the—

Beta testers. Yeah, using the same beta testers, I guess, for multiple releases versus having a fresh look from new people. Yeah, thoughts on that?

The answer is always both, right? So you wanna be able to consider old, the people you've already talked to, but also a new fresh set of eyes on your product as well, all the time. And then once you have customers, right, you can analyze the data and see, Who are the most engaged people? Let's talk to them. Let's learn about them, because part of your job is to constantly pivot not only your customer segment, not only your pieces of the product and your hypotheses, but also who are you targeting, right? So if you, let's say, are going after a broader audience and you see that a certain segment of your population is really engaged with your product, Maybe once you learn that, right, you can refine your persona that you're building the product for and go in your marketing intentionally after that segment of that customer, right? Which is why when we talk about product velocity, it's not just about improving the product. It's about improving your marketing. It's about improving your sales strategy and all of that based on what you are learning from what's already working.

Perfect. I know I want to be cognizant of your time. I know we can go over like a few minutes, but maybe just like 1 or 2 questions. So tell me, tell me if you want to stop at any point. Okay. This question is from Ray asking about sort of definitions of minimum viable product. Says minimum viable product is not necessarily minimum sellable product, or that's what Ray says. So how do you bridge that gap, I guess, cheaply? I mean, maybe this is just a definition of an MVP, but yeah, thoughts on minimum viable versus something that you can actually sell.

Yeah, absolutely. So I think, there is, there is a point where you are able to sell your product, right? So minimal viable, the reason why I want you to think about that is because what I, the way that I define it is being able to produce enough value for your customers that they're going to be willing to pay you for that, even though it's not complete, which is why in the beginning of your product journey, you are targeting your early adopters who have the highest pain point, right? So there's different types of customers you can, you can go after, but you want to be able to go to early adopters because they won't care that your product is not complete as long as you solve a core problem for them. And that's going to be your minimal viable product. So let's say your minimal viable product takes 6 months to build, right? It doesn't mean that you're going to wait 6 months to launch your product. You're still going to take and release, release, release. You don't have to launch to the public, but you maybe you have a few beta customers that are using your product that you are constantly testing and iterating with, right? That's the mindset of, okay, we're gonna iterate really quickly. We're gonna show this to customers and gather feedback and actually see, you know, somebody actually using the product and then refine from there. Because you're going to have your product roadmap of all the things you're going to build. But then when you start to learn from actual users using your product, what's valuable and what's not, guess what? Some of the things that are on your product roadmap will never be able to get to because there are more important, more pressing things that will take precedence. And so if you are so focused on just building what you have in your product roadmap, then you're building too much technology. You're building way too much of something that is not a priority, right, for your customers. And that's why this approach is going to help you really iterate on and build things that people actually care about and will pay money for.

Yeah, that definitely makes a lot of sense. I love the structure and framework around the, the TechSpeak for Entrepreneurs process. Like, I think this really— and I'm seeing this in the comments that people are definitely finding that the structure of it really helpful. And final question, I guess, before we move over to the networking is from Lulu. This goes to step 10 in the process. Where can we find behavior analytics tools? So another tools-related question, but for the very end, are there, you know, people think of Google Analytics, I think, when they hear of analytics, but are there other tools you recommend for that step 10 and the behavior analytics of what's already been deployed for your learnings? In the cycle?

Yeah, so there's a few tools. Google Analytics actually provides behavior analytics. It's just so hard to use that a lot of people turn away to competitors. So Mixpanel, Amplitude, there's lots and lots of people again who are solving this problem. Heap, uh, Heap Analytics is another one. Um, I think the biggest challenge for a lot of founders in this area is not knowing what specific behaviors that they need to track, right? These are your key performance indicators, and they don't understand how to go through that process first, because your analytic tools will support what you want to collect. But if you don't know how to collect the right data, you're never going to get the right insights. And so it's important here to understand what specific behavior and behaviors you want to track. How to collect that data properly, and then also how do you analyze that data so you can actually make those decisions. So the tools again are there, but you need to be knowledgeable enough to know how to use them properly, because otherwise you're just collecting data that you can't do anything with.

Yes, absolutely. That definitely makes sense. I guess before we end, any final closing tips for founders who are building products? At this time, anything that you want to kind of echo and refrain, Nelly, here before we close it out?

Yeah, learn early, learn often, and learn cheap. Make that a part of your company culture. I had somebody who attended one of my early workshops, and he was a 3-time founder with 3 successful exits. And this was when I used to teach TechSpeak in person. And he introduced himself as a as a founder with his last exit was $100 million plus. And I was just like, why are you here? What am I gonna teach you? You obviously have it figured out. And this is what he said to me that completely shifted what I realized that I was teaching, right? And this all around learn early, learn often, learn cheap concept. And he said, I had a tech team and a CTO, every one of my companies I built with these people. And they were using some version of your process, maybe not as optimized, but he's like the, The biggest realization I made is that as the CEO, if I implemented this learn early, learn often, learn cheap mindset and hired every single person, whether they were in tech or in marketing or sales, business development, or even our secretary, and every one of them had this whole mindset of this is how we made decisions as a company, then I wouldn't just have a good exit. I would've had a great exit and it would've happened a lot faster. That's the benefit of taking this mindset and implement it as part of your culture, because then you as a company can move forward so much faster and achieve that product-market fit a lot faster.

Definitely, definitely. The minimizing mistakes by catching them early, yes, it is something that can be put across your organization. And that's where, yeah, the like positive effects really like compound on top of one each other across the team. Yes, that's a, Yeah, great, great wisdom. Thank you so much, Nelly. Yeah, everybody in the chat has been saying thank you as well for your energy and explaining the process so simply. So yes, I want to just echo everybody's thanks and thanks to everybody for joining today. Yes, everybody who registered for the webinar should get a copy of this video recording as well. I'll have the slide deck within the next few days. And if you're a founder who's interested in being backed by the top free seed accelerator in the world. You can visit our website, it's fi.co or fi.co/join if you want to apply to the closest program near you. Thank you again to Nelly Usupova and thanks to everybody for joining us live. Thanks to Veda, our producer in the background managing the chat. And yeah, please everybody, yeah, stay healthy, stay safe, and thank you for joining us.

Absolutely. Have a great night, everybody.

Thanks everyone. Bye.