Expert Tips on Building Startup without Technical Co-Founders with Nelly Yusupova

Welcome everybody, welcome, welcome, welcome. My name is Martin Martinez. Welcome to another global event, uh, hosted online for all you amazing people. Um, we're already sitting at 130. We're just counting down— counting up, actually. Tell us where you're coming from, ladies and gentlemen. Y'all are already doing it right. We got people coming in from Singapore, we got people coming in from all over the world. Chicago, Miami, lots of Miami, San Diego, Morocco, Toronto. It just starts already. The chat's getting nuts. Uh, I will promise I will follow up as quickly as possible for all of that. Malaysia, Canada, what's going on, guys? So, um, welcome. My name is Martin Martinez. I am the entrepreneur in residence for the Founder Institute. We're based in Palo Alto. I'm actually coming to you live from Austin, Texas. Howdy, y'all. I also serve as executive director for the Founder Institute programs here in the Lone Star State. Applications are open for all, for all of our programs. We're kicking off in the summer. So if you are here in, in the Lone Star State looking to join an upcoming FI program, feel free to reach out to me, get an application. But also applications are live for all of our spring and summer programs. Head on over to fi.co/join. If you've got an invitation for, for this event specifically, That means you probably already are interested in joining the FI community and turning your business into the next big thing, taking it to the next level. 14-week program, we turn ideas into companies. See Houston in the house. This is awesome. So what's going on, y'all? We got a great event going on for you. Definitely connect with each other. We're about to be hitting over, getting over into some great content today. So Let's dive right into it. Today we're here to learn about building an MVP without a technical co-founder, trying to do that as easy as possible. Let's get some— give me one second, y'all. I'm gonna go and get some people out the room. Be nice to each other, y'all. Definitely be nice to each other. So let's bring up Nelly Yusupova. She's coming to you from out of New York City. She's gonna dive right in right now. And tell us a lot about what we can do starting right now. You don't need a technical co-founder to start your company. Y'all definitely don't. So Nelly, how you doing today?

I'm doing well, Martin. How are you?

Oh, we're living another day, another day in paradise. Love helping entrepreneurs. I'm really looking forward to this talk. So let's dive right in. I know you got a lot to share. If you have questions in the audience, please use the QA tool. We'll try to get through these. As possible as well. And then of course, we will be pulling in your questions towards the end. We'll be taking them from the chat, and we'll try to save those to the end. But Nelly, I know you got a lot going on, so let's get into it.

Great. Thank you so much, everybody. Welcome to this session. We have somebody saying not such nice things in the chat.

Yeah, we already just shut down the chat. We will get through that.

All right. So besides that, welcome everybody. I am so excited for this topic. I work a lot with non-technical founders, and the number one thing I want everyone to do after today is figure out one thing that you can do to bring your idea into more reality. And I'm going to tell you exactly what you should be doing step by step by step. Today. If you are— want to follow along and so you don't take a lot of notes, you can download a workbook. I just dropped the link in the chat, techspeak.co/FI, and we can— this workbook covers the exact information that we're going to cover today so that you don't have to take a ton of notes, but it also has things that you can do in terms of taking action. So in different places, after you learn the information, I want you to actually figure out what are the things that you can do to accomplish some of those things that we're talking about in the webinar. I see so many entrepreneurs going to events and webinars and doing all of the networking, but not taking action, not enough action. If you want to be successful as an entrepreneur, the number one thing that's going to make you successful is actually every single day moving forward towards the action that you wanna take. So today I am going to show you how you can make the shift from struggling to develop your MVPs and feeling uncertain on what you should be doing to successfully building an MVP in the next 3 to 4 months so that you can start to get traction for your products. And if you're looking for a technical co-founder or CTO, How can you attract them? For those of you who have not met me, I am Nelly Usupova. I am a CTO, startup tech advisor, and creator of TechSpeak for Entrepreneurs Academy, 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. But what's most important for you to know is that I have personally managed tech teams and projects for over 18 years. and I've refined and optimized my process over time. We'll talk about my process in the second part of the presentation, and I taught my TechSpeak 10-step process to over 1,200 students so far and worked with hundreds of startups, helping them with their tech strategies and help them fix and optimize their processes. So this is what we are going to learn today. First, we're going to learn why it is so hard to find a technical co-founder or CTO and what you should be doing instead. Right. A strategy for building an MVP without a technical co-founder. Two money-saving skills that you need to know about so you don't build more than you need to. How to define your MVPs properly to reduce the cost and time of development. The importance of a good process. Then I'll share how to work with me for those of you who are interested. And then we'll go into the live Q&A. So as we go through the presentation, you might have questions that come up. Most likely I'll answer a lot of the questions. This presentation is very structured, but if I don't answer your question, we can take those at the end. So check that out and drop your questions into the chat. And I think Martine is going to collect them and we're going to be able to address a lot of the questions at the end. Also a quick note, I'm going to be teaching all of the concepts from my personal experience of working with lots and lots of tech startups and advising them. And I've developed a process that I call TexSpeak 10-step process. So in my presentation, I'm going to be referring to TexSpeak as the process, and there are 10 steps in it so that you can take that information and improve whatever your process and your approach. And you can literally steal my process if you need to, because it works. All right. Sounds good. Say yes in the chat if you are ready to go, if you're excited, if you can see me and then you can hear me and everything is good to go. Before we move forward again, I'm going to drop the link one more time for the workbook. So if you haven't done that, go ahead and download it. All right. I don't see any yeses. Am I not seeing the chat? Okay. Oh, did you turn off the chat, Martin?

Yes.

Okay. All right. Okay. So, okay, then I won't be able to interact with you guys. That's a bummer. Because I love interacting with the audience.

I know, I know. We're doing some best. We got some, we had some, some—

I get it. I saw some of your comments.

I'm being nice there. We're here for y'all. So make sure that you take care of yourself, report those things. But yeah, I will be, we'll be using the Q&A tool moving forward.

Okay, sounds good. All right. So tell me if you resonate with this scenario. So you're a non-technical founder. I know that because you've come here to this event, and you have hopefully an amazing idea for some technical business. And think of the first time you've thought of your business idea. Was the first thing, the very first thing that went through your head is, I need a technical partner, a technical co-founder or CTO. Think about it. And it makes sense, right? You think to yourself, having a co-founder will save me money because they'll work for equity. You also think to yourself, I don't have to worry about the tech side of my business, and I can actually focus on marketing and sales and growing the company. And so you start looking for one, and months go by and you have no luck. You even think to yourself, maybe I need to learn how to code. I don't know about you, but it took me years to become a proficient enough coder. And here's the problem with waiting. The longer you wait, The big risk that you run is that you will miss the market opportunity. In the early days of your startup, finding a technical co-founder or CTO is a very, very, very common problem. That's why in my TechSpeak program, I teach my students that you don't find a technical co-founder or CTO, you have to earn one. Here's the thing, a good technical person who wants to take a risk and work in a startup is probably already busy doing a startup with their own idea. So you have to convince other technical people who are risk-averse why they should take a risk on you and your idea by showing to them that you're not just an idea person, but that you can actually get stuff done, that you'll be able to deliver as the business person. These other great technical people who are not already working on their own ideas, they don't have a problem earning a living in today's environment. In fact, there is a shortage of great developers and companies are willing to pay top dollar to hire great talent. So you have on one hand, great developers who are risk-averse and have plenty of choices and opportunities. And on the other hand, you have 2 out of 10 startups fail in their first year. So there's obviously a lot of risk involved. And one way to get the potential technical co-founder to say yes to you is by showing to them that you have taken some of the risk out of their time and opportunity cost investment. Here's some things that you can do to mitigate the tech person's risk and earn a technical co-founder or CTO. By the way, the strategy that we're gonna be talking about today is going to work for earning any kind of partner or an investor, okay? This is the thing that works. The first thing you need to do is validate the idea and build a clickable prototype. This will demonstrate that there's a need and a demand for your product, that your idea is not just an idea. And as we'll find out in the second part of the presentation, these two things actually require no technical expertise. So that's exciting. The second thing is to build a community and a following. This will further demonstrate the need for your idea and also show that you have the marketing skills necessary to sell the product. Again, that you're not just an idea person. And finally, if necessary, invest some of your own money to build the MVP, and most likely you will have to outsource the building of the MVP. This will demonstrate that you believe in the potential of the idea, that you have some skin in the game, and that you will find a way to bring your idea to life no matter what. And again, in the second part of the presentation, I will show you how you can plan your MVPs effectively. So this step should actually not cost you a lot of time or a lot of money. Okay. But by getting traction, this is really, really important. I'm going to underline it 1,000 times. By getting any level of traction as a result of doing these 3 things will shift the conversation from I need you to here's a great opportunity, and you should feel lucky to be a part of it. You don't actually need to say that last bit, but it will definitely be inferred by whoever you're talking to. You'll be able to say, look what I've been able to achieve without you. Imagine what we can do together. Say yes. I can't see you, but say yes if you see the power of this conversation shift. It is so much more effective as a sales pitch to say to somebody, So much more powerful to say to somebody, come be a part of this amazing opportunity than saying, I need you to come build my product. Okay? So first I want you to realize the power of this, and this is how you're going to do this. With this strategy, you're gonna do two things in parallel. The first thing is to de-risk the opportunity for the tech person by validating your idea, building the clickable prototype, And if necessary, outsource the building of the MVP. And the goal is so that you can gain traction for your idea so that you're much more attractive to everybody— investors, co-founders, partners, everybody else, right? And while doing all of this at exactly the same time, parallel, you need to start to actively look for that technical co-founder or CTO. By building your network of technical contacts. And hopefully by the time you meet them, you will have enough traction that the opportunity will be a no-brainer for the potential technical co-founder or CTO to simply say yes to you. This approach is very, very effective because it allows you to showcase your commitment to the idea, showcase your skills and value as a non-technical founder, and also highlight and demonstrate that you are an amazing asset to the success of the company. This is such an important mental shift, and I want you to commit right now. We don't have the chat, but so I want you to take a pen and paper, and I want you to write, "I am committed to earning a technical co-founder," on anywhere, right? This is your action step. This is the first thing I want you to really start to understand and know that as a non-technical person, there are things that you can do to move the conversation forward. Okay? So type, write, I am committed, or even say it out loud if you need to. This will be a game changer for you. And this is a really, really important note. Once you find someone, do not make the mistake of saying yes too quickly. I always equate finding a co-founder to dating. Just like you wouldn't ask someone that you just met to marry you, you shouldn't ask a person that you've just met to become a co-founder. Way too many people, especially non-technical people, say yes to a co-founder relationship way too early. It's not just about finding someone who can complement your skillset. It's about finding someone who believes in the vision and how you want to grow the company. Someone that you're going to be able to solve really difficult problems with and get through challenging situations. And you have to feel good about working side by side with that person for 5 to 7, hopefully, or more years, right? What I am describing is a true partner. So don't get a co-founder so you could put a check mark that you have one. It is the wrong approach and one that can literally cost you your company. The number one reason why a lot of startups never get off the ground or fail, it's because of a falling out between co-founders. When I found out this stat, I was blown away. The number one reason why a lot of startups never get off the ground or fail, it's because the co-founders can't get along. They can't figure out how to move the company forward because they disagree on everything. So if you find someone compatible, figure out how you can work on a project together. Maybe you pay them first and then you decide to make them a co-founder. And that's why earning a technical co-founder is such a great strategy. It will allow you to make progress while you're searching for a partner and building that relationship with someone. It will give you room to select the best person for the job and make that decision from a position of power and not from a position of need. Okay, so I hope you guys are getting this and are on board. Can't ask you in the chat, but let's shift gears a little bit and actually learn how you can build MVPs effectively and efficiently. Again, if you showed up late, I'm going to drop the link in the chat. Download the workbook here if you want to follow along and figure out your action plans and your commitments are in there as well. All right. So the hard truth is that as a non-technical person without a technical co-founder or CTO, you actually most likely will find yourself that you need to outsource the development of your MVP. And that will actually be the fastest way to launch your idea, start to get traction, and as we just learned, to earn your technical co-founder or CTO. Because all of this, building a product, launching something which doesn't have to be expensive, by the way, we'll, we'll get to that. Launching something, getting traction is going to be able to provide that de-risking opportunity that you need to be able to get people on board with you. So let's address the elephant in the room here, which is outsourcing. You're probably thinking of one or two horror stories that you've heard about outsourcing. In fact, I personally rescued at least 25 project in the last 3 years that my team and I took over from bad outsourced situations. And I created TechSpeak after speaking to thousands of entrepreneurs in my workshops and seminars at conferences across the country and hearing the horror stories about their tech projects getting out of control. Thousands and thousands of dollars wasted with no products to show for them. And I mean $60,000, $80,000, even a startup who lost $100,000 of their seed round. To outsourcing because they had no idea what they were doing. And here's a recent story of one of my students who is in real estate. She hired the best consultant in her area with an amazing track record. She sold her house so she can afford to pay his rates because she had so much conviction with her idea. And a year and a half later, she discovered that he hired a team of developers in another country to do the development that she hired him to do. And of course, he didn't manage the team properly. And after paying thousands of dollars, she didn't have too much to show for it. And when I met her, she almost had to start her entire development from scratch. And this is not a unique situation. I've heard thousands of similar stories, and at first I actually blamed the developers and the agencies, and I just couldn't understand how they could morally function like this or even stay in business. But the more I dug into it, the more I started realizing that the problem is not always with developers. Most often it's actually the entrepreneur. So part of the problem for non-technical entrepreneurs is not knowing the process for building web and mobile applications, not knowing how to communicate their ideas so that their tech teams will know exactly what to do. Not knowing how to hire the right tech people, not knowing how to manage the project, trusting that the developers will take care of everything, and not knowing the right questions to ask to ensure that the right decisions are made for the business and that all of the technology decisions are aligned with business goals. And when you don't know any of these things, you will always, always, always make a lot of costly mistakes because you will miss a lot of the red flags. The red flags are always there. But when you don't know what you don't know, it's like going to a mechanic without knowing anything about cars. You will believe everything they tell you. You will buy everything they tell you, and you will fix everything they tell you that needs to be fixed because you want your car to work. And the same thing happens during development. When you don't know what you don't know, you don't have a way to spot the red flags. You don't know when to ask the right questions to see if you're being duped or even to see if the suggestion is what's best for your business and your situation at that moment. Okay. So here the issue isn't that outsourcing doesn't work. The issue is that you may not know how to outsource properly. And the good news is that I can easily teach you how to do that. Okay. So I am going to quickly look at the chat. Great. So there's a question about co-founder splits. We're gonna take that at the end because I wanna make sure that we cover the material. That is something I can definitely answer for you at the end. Great question. All right, so we now know that outsourcing is not the problem, right? And what helps me be successful is having a really efficient process that I've refined over the years. And in a few minutes, we'll actually dive into the 3 key things in my process that allow me to manage teams successfully, whether they're in-house or outsourced, without wasting thousands of dollars. First, let's learn what is a process and why is it important. 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 it's important for companies because it will allow you to get everyone to execute more efficiently and effectively. It will allow you to set expectations, and most importantly, it will allow you to catch mistakes earlier. To me, the job of the founder is about minimizing mistakes. Because it's unrealistic that you won't make any mistakes. Even with the best processes, you will always make mistakes. Everyone makes mistakes. Even I do sometimes, right? Hard to believe, but yes, I do. So the key is to catch mistakes sooner, because the sooner you can catch the mistakes, the sooner you can address them, which will minimize the effect of the mistakes. So now I'm gonna walk you through the 3 secrets to outsourcing success. Using the TechSpeak 10-step process. So secret number 1 is to not build more than you need. Because no matter how good your team is, whether they're in-house or outsourced or any combination of that, you will always waste your time and money if you jump straight into coding without refining the ideas and the solutions first, because you'll end up building a lot of unnecessary features and functionalities that your customers won't end up using, which results in a lot of wasted development, which directly translates into wasted time and money. Validation, which is the very, very first step in my process, will help you refine your ideas, whether they're ideas for a new product or a new feature for an existing product. Every single idea that you have in this process is a hypothesis. It's an assumption that needs to be proven right or wrong. And the idea here is that you need to make sure that those ideas are painkillers, because it's not enough to have good ideas. Your ideas must solve painkiller problems for customers 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 products and functionalities and services. And you would refine your idea through a process called customer development. Let me demonstrate how valuable customer development is through an example. So here we have a non-tech entrepreneur who wanted to build a tech application around international news. Validation helped them identify their ideal customer for the service, and it actually wasn't who they originally thought it was going to be. It helped them understand how people felt about their riskiest assumptions and how to adjust those assumptions to directly address potential customer concerns. It helped them learn specifically how other solutions on the market failed to solve the problem they were trying to solve, what type of content they should create, what countries to focus on first, what the business model should be, and so much more. Without these details and insights, they would have hit— they would have definitely built so much more functionality than necessary, targeted the wrong customer segment, and ultimately wasted a ton of money recoding later because they would eventually learn these insights, but only after the product was built. 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 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 all of the books on customer validation. They know all of the terminology, but they either implement it incorrectly, or frankly, I find that a lot of founders don't do it at all because the books don't teach you the step-by-step for how to actually do it right. They don't give you a step-by-step process that your team can follow and use on a daily basis. And that's the problem. You don't have a process, and you must focus on testing the right hypotheses and design the interviews in a way that does not lead the user to your solution. Biggest mistake that I see entrepreneurs make when it comes to validation. They lead their users to the solution that they ultimately want to build. In fact, I recommend that you forget about your solutions in the validation step, and here's why. So I have a student who's going through my program right now. She was referred to me by a startup advisor who knows me, and she just literally told her, do what Nelly says. So she came into the program with a clickable prototype, which is Step 2, we'll talk about that in a second. And she said to me, 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, 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 don't discover anything new, great. Great, because if you know, you've just saved yourself a lot of time and money, but you also got confidence that you are headed in the right direction. But if you do discover something new, great, because you can take those insights and bake them directly into your solution so that over time you can save time and money. And reluctantly she did, and she discovered 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. Her original solution was actually a part of the final solution, but it wasn't the main part, which it was at the beginning. And that, of course, saved her so much time and money. Imagine her spending 2 or more years trying to sell a solution that no one fully resonated with. And the cost of not validating 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. So learn how to do this work properly or work with someone who knows and has a process that your team can follow. And I would like for you— this is so big, so important— that I'd like for you to commit to actually validating all of your ideas properly. So, you know, before developing anything, that you are going to be building something that someone actually wants and needs. That is such a crucial step and will inform every single product decision that you make. So grab your pen, grab your paper, write, I am committed. In your workbook, you also have your commitments in there. So definitely this is like, if you don't take anything away from any of the webinars that I teach, this is the most important one. I'm a technical person. I have all of the resources at my disposal, and I never do anything until all of my ideas go through a validation process. Okay, because it helps them. It helps me to refine them so that I don't have to rebuild later. Okay, so once you validate the 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'll refine the solution by getting feedback from potential customers. Prototyping is step 2, as you can see on the screen of the TechSpeak process. And these prototypes are so realistic, your potential customers won't even know that it's not real. So I'm going to play a quick demo for you. So you can see how realistic these are. 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 pretty realistic, doesn't it? Doesn't it? So let's talk about a case study. So I'm going to demonstrate how valuable prototyping is through an example. So here we have a non-tech entrepreneur who wanted to build a tech application around politics. This is the demo prototype that you just saw. Prototyping helped them test multiple solutions before writing code. The very first two versions of their solution did not resonate with their users. And after collecting user feedback, they went back to the drawing board and got it right on the third try. Now, if they had jumped into coding after creating their very first prototype, they would have had to re-architect their entire app later and rewrite a lot of the code. And that, of course, would have been very, very expensive. Writing code is actually a way of building prototypes, but it's the most expensive way. And that's why I want you to start refining your solutions with clickable prototypes first, because it is always a lot cheaper to rapidly change prototypes than it is to rewrite code. And inevitable question I always ask, or I get asked from people, is what about no-code tools? No-code tools is still writing code, and I want you to use tools like Balsamiq or InVision or Marvel app. What else? Figma and Sketch and all of these types of tools, right? These are literally drag and drop that will allow you to very quickly iterate on your ideas. Okay, so this is where, this is where you will be able to save a lot of time and money before you build anything. At all. And it actually gets even better. So I want you guys to meet Gabe. He was a realtor who saw a lot of inefficiencies in the real estate business, and he used validation and prototyping to come up with a solution to solve some of those inefficiencies. He took his clickable prototype, not a working product, product, clickable prototype, to a real estate agency and was actually able to sign them on as a customer and got paid in advance to build it. Can you imagine what it would feel like to get paid in advance to build your apps? Wouldn't that be amazing if you were able to pre-sell your solutions? And the answer is you can if you have these two skills: find a painkiller idea, a level 12 out of 10 problem in the validation step, and then build a clickable prototype of a solution that directly solves the pain that you've discovered in step 1. And if your solution targets businesses, you will also have a much higher chance of pre-selling because businesses actually have budgets to solve problems, okay? And by the way, validate and prototype are step 1 of earning your technical co-founder strategy that we talked about earlier. And again, does not require any technical knowledge to execute. So if you're in a pre-idea or idea stage and you haven't done anything at all, and you need to know like, what's the first thing that I'm gonna do? These are the first two things that you need to be doing, okay? I have a student right now who also is a non-technical founder, does not have a technical team. Before he just did these two steps. And before he did anything with tech, he actually had five customers that, He's in a B2B space that gave him letters of intent, and he used that then to go and raise some seed, some seed money. Okay, so you can do all kinds of different things if you get this right. You can actually understand how to sell to customers, how to communicate the problem really well. If you do this really well, do not lead your users to a solution. Okay, so Is everybody with me? We see chat is back. Is everybody here with me so far? I don't see anything in the chat, so maybe it is— okay, there we go. Excellent. All right, I feel like I am connected with you guys now because I'm talking to a screen. All right, welcome. Okay, great. So let's go on to secret number 2. Define your MVPs properly by understanding what affects the cost of development. So once you've refined your idea and the solution, you are ready to define, build, and deploy your solution. You now need to define a minimal viable version of the prototype that you created. So this is steps 3 to 7 in my process, and by definition, an MVP For those of you who don't know, it stands for minimal viable product. It is the smallest number of features 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, it's not enough. So let me show you why. Have you ever wondered how the same exact project could be estimated to cost $10,000 and $100,000? And both estimates could be completely legitimate. Think about that. Same exact project. $10,000, $50,000, $100,000, right? Well, that's because the details of what and how you're going to build something matter a lot. One of those details is knowing and understanding what affects the cost of development. Here's an example to illustrate this. What do you think will cost more to implement? This form where we collect the user location in 4 fields, or this form where we just ask the user to enter the zip code and automatically show them their city and state? Number 1 or number 2? Type your answer in the chat. Let's see, number 2s. We have 2— lots of 2s. Some ones, mostly twos. Great. So if you guessed number 2, you are absolutely correct because in the second implementation, we have to write a lot more code on the backend to get the user's city and state based on the specified zip code. For the user, the user interface, it's brilliant, right? They— the user doesn't have to do a lot of work, but from a technical standpoint, it's gonna cost a lot more. So you can actually on purpose decide to implement the cheaper version of the solution, which in this case is number 1, so you can save money. And there are lots and lots of decisions like these that you can make that will help you control the costs of your MVPs, okay? 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. 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? Type yes in the chat if you would like the cost of your projects to be significantly reduced. All of you should be typing yes, right? That's why we're here. It doesn't make sense to do any other way. Well, here's the problem. The problem is that most developers and agencies 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 10 users or 100 or maybe zero. It doesn't make sense, right? You need to strategically plan things and optimize over time. Your goal is to launch things as quickly as possible and refine and iterate from there. And your job as the CEO is to implement a new way of thinking to make sure that your team is not building more than you need to. Okay? So this is another commitment type. I am committed in the comments. This is really, really important as a mindset to take control of your development process. This is why you as a non-technical person need to have a process. You need to understand how to communicate and actually have enough confidence to communicate that this is the way we want to work rather than relying on your developers to just dictate what and how things will happen. Okay, very, very important. Lots of commitments. I love all the participation. Thank you guys. So let's go on to secret number 3: have an impeccable process based on lean and agile methodologies to manage the outsourcing team. So validating ideas and building a prototype are a part of the lean product development process, but it goes beyond that. The bigger picture behind the lean way of building products is this whole mindset of learn early, learn often, and learn cheap. And lots of developers and outsourcing teams don't think like that. They don't think how to cut development time and costs, right? It goes against how they make money. So it's going to be up to you to take this learn early, learn often, learn cheap philosophy and make it a part of your company culture. And you have to have someone on your team enforce the lean way of building products at every single step of your product development process so that you can iterate really quickly. And agile project management will allow you to get working code from developers in at most 2 weeks. Imagine that, getting working code in at most 2 weeks, and it can actually be done weekly, daily, or even multiple times a day. The beauty of Agile project management is seeing the mistakes earlier and course correcting sooner. From my experience, there are many more agencies and developers who are familiar with these principles, and they claim to be practicing Agile project management, but who are woefully lacking in effective practices. And this is where I personally, as a fractional CTO, spend a lot of times when I go into startups to help them fix and optimize their Agile practices to help their teams execute a lot more efficiently with one goal: to optimize their current process so that their team performs like a well-oiled machine. I want you to go from 2 weeks to 1 week to multiple times a day to multiple times a day. Yes, multiple times a day. Because the more you launch, the faster you are learning, which of course allows you to make decisions better. You can launch things in 2 weeks or as often as every day. And I want you to eventually get your process optimized to a point where you are able to get your team so efficient that you have amazing product velocity and that you are learning really, really quickly. To me, an efficient process is absolutely everything because it creates transparency throughout the project so you can detect earlier when things are headed in the wrong direction. And I wanna demonstrate how important an efficient process is with this story. So this is Eric. He had a software company for 3 years before he learned the TechSpeak process. He had a tech team, he had a CTO, and this is what he said after 3 years of running his software startup. He said, after 3 years in business, TechSpeak would've saved us close to half a million dollars in delays, development costs, and sleepless nights. I'll let you absorb that for a second. That's a savings of half a million dollars over a span of 3 years. And that's the benefit of having an optimized process based on lean and agile methodologies. There's a difference between releasing code and releasing code effectively and efficiently. Lots and lots of developers are releasing code every single day. 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 you to get into a habit of releasing code as often as you can. As I mentioned, multiple times a day if you can, because that shortens your learning time. It gives you a lot more data points to make better decisions. And allows you to catch mistakes earlier and of course course-correcting faster. One of the most frequently asked questions that I get is, wouldn't the developer or the tech team that I outsource to have a process? Shouldn't they just follow that? And the answer is absolutely not. That is a recipe for disaster. If you want things to go off the rails, do that. That's the traditional way of doing things. There are 3 different approaches to outsourcing development, and they all have pros and cons to each. Local freelance developer, local agency, offshoring to freelance developer or agency. But no matter what option you pick, you pick there, there you have to have 3 roles in to be able to run this process. Okay. You need to have a product manager and a project manager on your end. Managing the development team. Even though your outsourcing agency may have their own product manager or project manager, I want you to enforce your own process and manage the development team. Otherwise, prepare to overpay and have a lot of inefficiencies. I actually call this developer as a service arrangements. This is where you manage the developers directly. And enforce your own process. So to me, when people ask me, should I outsource or should I build my own team? If you follow this developer as a service arrangement, it doesn't matter because you are working with developers directly, you're managing them, and they're part of your team. There's no such thing as them versus us. We are a team. They just happen to be somewhere else. Okay. And in the early days, this job will fall to you. Because often you don't have the funds to hire a product manager and a project manager. This is where a lot of entrepreneurs make a mistake. If you don't have the money to pay an external person to do this role, you have to learn this job. Product manager, project manager, and using the lean and agile methodologies. Okay. And the last piece of the puzzle, if you're not technical, to allow you to manage a team successfully, is to become technically literate. This means that you'll need to learn some fundamental technical concepts. You'll need to know what some of the tech jargon means. You'll need to understand the best technical processes and how to easily identify when things are going wrong. You need to become knowledgeable about the web, how things work, what's behind the scenes, what happens when you click on a button on the browser, what happens on the back end. You need to understand servers, how all of that communication happens. Learn all about the different languages and how they work together. Understand APIs, databases, libraries, frameworks, no-code, low-code, third-party tools, all of that stuff. Understand the high level of what goes on behind the scenes of your product, and then you can set expectations in your mind and with your team on how things should work. This was what will allow you to catch when someone is trying to take advantage of you. Or is giving you bad advice, which happens so often, even by well-meaning technical people. This is what will give you the confidence to have those conversations and ask the right questions. This will give you the confidence to push back when the developer says it can't be done, when it can only be done a certain way, right? So they are constantly telling you what to do. It will give you the confidence to control and negotiate how much time something should take and how much money it should cost. The confidence you get from being technically literate is literally going to change how other technical people perceive you. You're going to be able to attract better technical people just because you're able to communicate more efficiently with them. And I want you to commit right now in the chat to take steps to becoming more technically literate starting today. This is really, really important. And by the way, Even if you have a technical co-founder, I want you to be technically literate because this is the only way where you can stand in your power. You need to understand where all the technology is, how the technology decisions are being made. Because guess what? I've seen this horror story. I'm gonna share it with you. Co-founder, technical, non-technical work together. They didn't understand any parts of the business. The technical person actually knows the business, right? Because there it's a lot easier to learn that. But the non-technical person completely trusted the technical person to do the work. And guess what? Their relationship fell apart a year into it. Who had the shorter end of the stick, the non-technical person or the technical person, right? The non-technical person, because they had no idea where the code was. The technical person just took everything, and the non-technical person found themselves just wasting a year of their life with nothing to show for it. Okay, so get— this is really important. Well, if you're going to be running a tech startup, this is not an option for you. You must become technically literate. You need to understand enough so that you can communicate with people effectively, technical people effectively. You can manage a team, you know their jobs, etc. Okay, so very cool. Lots of commitments. Excellent. So let's do a quick recap of what you have learned so far, and then we'll dive into the Q&A. So first, we learned that you have to earn a technical co-founder and not look for one. Then we also learned that outsourcing may be actually the fastest way to find a technical co-founder by helping you get to traction faster. You learned that you need to validate and prototype all of your ideas so you don't build more than you need to. To use development cost-reducing strategies when defining your MVPs to reduce the cost and time of development, and to implement lean and agile processes to manage teams effectively. And you also learned that there's a difference between releasing code and releasing code effectively and efficiently. And finally, that you must become more technically literate. 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, 7, all, or what combination of the 7? So let me know that. We have David says 3, validate and prototype. Excellent. The most important step. We have lots of 3s and alls. Excellent. I'm glad that this has been transformational for a lot. 2 was a surprise, outsourcing maybe the best way. That's great. I'm glad that you guys can see this. Because if you have a technical person that you know from college or from somewhere else, and you have a deep relationship with them, a deep trust, and you know that this is the person that's aligned not just on skill set, but on values with you, of course, it's better, right? If you have that type of person, definitely do it. But you can't wait around, take a chance on someone you don't know, and risk missing the market opportunity. Right? So this is a way that I've seen a lot of non-technical people make progress while looking for a technical person. It may take you 2 years to find a really good CTO/co-founder, right? It may take you— you may get lucky, but if it takes you longer, you shouldn't be waiting to move forward with your idea. Okay, excellent. Thank you guys. So if you resonated with me and you're ready to take the next step in our serious about committing to running a tech startup effectively and efficiently using my proven roadmap and get exactly the recipe that for launching products on time and on budget, then I want to invite you to learn more about TechSpeak for Entrepreneurs Academy, which is an opportunity for you and I to work together and learn how to implement all of these steps step by step by step, how to manage a team as a non-technical founder. And I would coach you through all of this And the entire program is online and you can learn it in as little as 2 days. So go check it out. There's an exclusive offer in your workbooks where you get, uh, $300 off, off of the curriculum. Plus you get an extra month of coaching. So 4 months rather than 3, uh, which comes as standard with, uh, the program. So check that out. And the link is in your workbooks. Okay, so let's— for those of you who didn't download the workbook, this is where you can get the workbook. Let me drop the chat into— let me see if I can drop the link into the chat, and we will start taking questions. All right, so, Martín, let me jump into the Q&A.

Go ahead. How you doing? This was awesome.

This was great.

Yeah, took us a little bit. We had to, you know, kick out a couple rodeo clowns.

This is what—

that's why you don't— that's why you don't let 12-year-olds use the internet, y'all. Come on, check on your kids. Don't let them— don't let them Zoom bomb Zooms. Yeah, especially when y'all are trying to get some great content out of this. We're still sitting at 250. So again, y'all are still joining with us. Let us know where you're coming from. Connect with each other. We had so many questions, now that we only have so much time. So I'm gonna consolidate a few of them. The first one, I saw a pattern. There were a lot— Miami, right on. Recording will be available in the next 48 hours, Ken, so no worries, you will get it. So I've seen a lot of feedback from a lot of the questions that were coming in in the Q&A. We tried our best to consolidate and get a bunch of them in, but a common pattern I did notice. A lot of these founders or aspiring founders that are in this room right now, they're worried about, you know, just putting it out there and potentially having somebody steal this idea. And I get this all the time and I know you do too. So what do you tell them when you hear that, I'm worried someone's gonna steal my idea, what do you say?

So ideas are just ideas without execution, ideas do not matter. So I talk about this whole concept called product velocity. So if your team cannot outperform your competition, if your idea is good, even if you are able to run with it and hide it from everybody, as soon as you launch it, if it's good, there are people who will copy it and be able to launch it probably in a lot sooner than you. So talking about team velocity and the reason why process is so important and really understanding and controlling your team in this way that I described is because you need to be able to iterate really, really quickly to be 10 steps ahead of your competition. Okay, so if somebody's going to steal your idea and they can outperform that, outperform you, ultimately they're going to win in the market, and you should actually say thank you to them for not— for actually saving you from years of working on something that, you know, is, is going to be a waste of your time. So That's what I say to a lot of people. I think a lot of inexperienced founders, first-time founders usually ask this question because they feel like their idea is what defines the business. Idea is just the first step to be able to build a business around an idea. You need to be able to understand how to sell it. You need to understand how to position it in the market, how to acquire customers, how to do all of these things right, find a business model that works. And sometimes it takes people years to be able to get that, right? Those overnight successes. So it's never about the idea. It's about putting together a team, understanding how to get the team aligned on a vision and a goal and move them in the right direction really quickly so that you are not spending a lot of time going in the wrong direction, but you are learning and optimizing constantly and you are able to out-execute your competition. So that's So that's my answer to that question.

I love that answer too. Again, like, if you're too worried about somebody stealing your idea and picking up with it that quickly, it may have not been that great of an idea. It may have not been as unique as you thought. And the only way you're actually gonna figure out if it's something worth building is if you talk to people. You have to talk to people.

And the other thing I'll share, 'cause I think this is connected with validation, when you're talking to people, invalidation, you're never asking people, is this a good idea? You're never sharing your secret sauce with them. You're only assessing the problems. You really know, like, your goal is to be the fly on the wall so that you can understand their process, their thinking, the problem. Is this a big enough thing that they're going to pay money for? Right. All of these things are never— you're like, you're never asking, you're never leading with any specific solution. Solution, because that's a big mistake that a lot of people make. They want— they are so in love with their solution that they'll actually ask questions that will get people to, to basically tell them, yes, we need this, right? And then when they put it out in the market, the response is lukewarm. So that's why never worry about your ideas or sharing or talking to people, because you're never sharing your secret sauce. You should never share your secret sauce to anyone but the people that are working with you and that you trust.

Awesome. That's getting right on the nose. And we only have so much time, but I know you've got some stuff coming up too. So I'm gonna ask one more question, another one that was really showing a lot of patterns from the community. Compensation, equity, you know, how do you distribute that? How do you approach it? Especially if, say, you know, you're taking this contractor relationship because you outsource and like, wow, like you really have what it takes. Let's talk about a true co-founder relationship, how do you bridge that gap? And then what does that look like in terms of compensation, equity splits, etc.?

Yeah, so compensation is a very tough thing to do. So as I always get this question as like, how much should I compensate a technical co-founder as a non-technical person? And it all depends on what the other person brings to the table, what their current circumstances. For example, anyone who's working with me, I'm already established, right, in the industry. I have certain standards. I have a family, I have things that I, you know, like I am already too far and in the process of being a technical co-founder. So I am requiring a lot versus someone who's just starting out. So you need to understand where are people at, what, uh, how much do you want them at the end of the day, right? Because I want you to do your research of what's standard, and then it's a negotiation tactic. It's you being able to tell and communicate effectively why you think this is fair, and them knowing what they're worth and communicating back to you why they think what they want is fair. And I always say the first test with co-founders is if you're able to very calmly discuss the equity split and actually are able to come to a solution and do it in a very empowering way, this is a first good test that you guys are gonna be good co-founders. And if you are having a really terrible time discussing this one difficult conversation, like you'll have lots of difficult conversations in your startup. If you are not able to do this effectively, not a very good partnership, I can guarantee that. So the first thing. The second thing, if you're working with an outsourced team, I almost never— I don't like giving equity to an outsourcing team because you are testing them. You have no idea if they're going to be able to deliver, if they're going to do a good job, what that working relationship is going to be like. So I've seen people start to work with development teams and then over time they saw that, wow, this team is really going above and beyond and I will give them equity to incentivize them so that I also can reduce my fees, but not at the very beginning. Unless you know the firm and you trust them, I almost always say test, test, test first and don't give away, like, it's just too expensive of a proposition to be.

Totally agree. Totally agree with you on there. And thank you again for sticking with us a little bit over time, Nelly. I know you got a lot going on, but the The crowd loves it. I'm glad we got to get the chat going back up. Tell us again, I know a lot of you didn't know, we have so many people in the room today. There's plenty of questions we didn't even get a chance to get to, but I know you got some stuff coming up. So share with us other ways to connect with you. You mentioned this Clubhouse that you got on Friday. Tell us a little bit about that.

Yeah, so I have a Clubhouse that I do on a regular basis. I'm gonna drop the link again. I'm gonna stream it to all my social channels. So I'm Digital Woman Everywhere. So just go find me somewhere If you— the Clubhouse is Q&A. So if you have a question that I didn't answer, you can come up to the stage, ask it, and I'm happy to support you. I also do free webinars on my website, techspeak.co. And of course, if this training is what you want and you want to get the step-by-step knowledge of, you know, instead of going to Google and trying to learn on your own and get the shorter path, I'd love to work with you and support you on your journey as well.

Awesome. Thank you again, Nelly. Any final thoughts? I always like to wrap it up with just one more question. You know, if there was a founder that you're meeting right now, an aspiring entrepreneur that wants to start a company, become a founder, they don't know where to begin, what's the first and only piece of advice you give them if that's all you can do?

The only thing that I think is really important in startups is understanding customer pain points. And I think Way too many people solve level 5 or 6 problems. And if you spend the extra time to really understanding and refining the problems and find those level 12 out of 10 problems, you're going to have such a much easier time. I'm not going to say easy, right? A much easier time selling your product. You already know who the customers are and how to sell it to them way before you build anything. So, and it's funny coming from a tech person, right? Like, this is what I'm telling you, like, don't build technology. But it is the most important thing. I've discovered this in my own career when we spend 9 months building this perfect solution that I thought was going to completely change everything for the business. And we launched and nobody cared. And I was just like, well, that's— what did we do wrong? We spent so many resources on this. And so as a technologist, I really understand the value of understanding Specifically, like, what are we building? What problems are we solving for? Because that will also help you make product decisions as well. And of course, will, as a team, will allow you to increase your product philosophy because you're not wasting a lot of time and money building the wrong things. So validate.

Validate, validate, validate. I love it. Thank you so much again for this lovely hour. Thank you again to the audience for being such great sports. For your reports and doing such great discussion and questions. Definitely follow some of those links that Nellie dropped in, join her for Clubhouse coming up on Friday or across the internet. But we'll bid you adieu for now. I know we're going to bring you back soon for a follow-up to this in the next couple months, so we'll, we'll be talking more about that. But otherwise, thank you again, ladies and gentlemen, just for one more time. Applications are open for all of our upcoming coming spring and summer cohorts around the world. We're in over 200 cities and 100 countries globally for the Founder Institute program. So if you're ready to turn this idea into a company, come to us. We're— applications are open for our Texas programs where you're going to get to work with me and all of our Texas mentors and leaders. So definitely get those applications in. And please come to these events. We love them. We love hosting these, providing this great content for you so that you can build future that you need to see for your community. So wherever it is we find you, we hope we find you safe and well. Take care of yourself, take care of each other, build that future that we all want to see in the world, and we'll see you next time.