Coach Mike: How to Succeed as a Non-tech Founder

Alright, and we're live with another Coach Mike episode here. I'm Drew Zayas, your producer, joined in the studio by Mike Supravici. Mike, I'll let you introduce yourself.

Hello everyone, my name is Mike and I lead the graduate or alumni success group here at the Founder Institute.

Awesome. So today we're gonna be tackling a pretty cool subject, which is how to start a startup as a non-tech founder. What steps you need to take, how do you get it done? It's a question that a lot of people have because a lot of the really good founders we see in the world are non-tech founders. So let's dive right in. Do you have to have technical proficiency to start a tech company?

Um, it depends. And I hate this answer, but if you're, if you're building a very, very, very, very technical company, yes, 100%, right? So if like the entire business is basically like, because of this algorithm or this very specific type of like product that requires deep technical, like, you know, machine learning, artificial intelligence, of course. Like, there's just no other way. Like, there's no way a person that doesn't have that will have a— will be able to build this type of product. However, for a lot of products that have tech involved, that's not the case. So let's say you're building a marketplace. Most marketplaces don't require a lot of tech. Basically, if you think about what a marketplace is, is, is a place where people can facilitate transactions or things like that. You can do that even manually, just like they used to do in the olden days where people would just go to the market and barter for things and stuff like that, whatever, right? And then you can add a little bit of a website to do so. And in that case, like, the, the technical component is just not as important. It's more about like how you acquire people and things like that. So It really depends on the business, but if you're not a technical person and have experience in a place that requires pretty good tech or has a vision for a tech product, then don't— you shouldn't let that hold you back. You should just be in a position to just recruit people to do so, and we can talk about that, I'm sure.

Yeah, so do you think in that case it'd be a good idea to get a tech co-founder?

I don't really believe you should get a tech co-founder because some publication or some fund out there says that you should do that. Finding a co-founder, as I've mentioned in previous podcasts, is kind of like getting married, and you want to make sure that that's a good person. You're almost better off being a solo founder than marrying a bad co-founder, and ultimately that will lead to divorce, which will kill the company. So no, but you should be recruiting technical people to join your company. And these are people that join your company and your mission, and maybe at some point they become co-founders. That's, that's also obviously a potential opportunity. But, you know, it's, it's just, you know, these are people that believe in the mission, that are there working with you and iterating. We're not— I'm not talking about like consultants here, right, that are like purely transactional. Hey, I pay you for this, you give me this. I'm talking about people people that believe in, in you, believe in the vision, and they wanna make this happen. Yeah.

So I kind of wanted to dive into first steps for, uh, non-technical founders. So let's say I'm a non-technical founder. I have this really cool idea. It's gonna take some tech to build cuz most things do. Uh, and what should I do? How should I approach building an MVP for this? Outlining an MVP that like I could achieve as an individual. Should I bring in outsourcers for my MVP? Is that too early? What are your thoughts?

Yeah, I mean, I'm a big believer in, in the Founder Institute model here about the way that we kind of like try to help companies think this, think through this. Look, I mean, before you even go out and build code, and this is for technical and non-technical people, you really should think through kind of like the business and how you acquire customers and things like that, because that's going to influence the product that you build, right? Like if you're going to acquire customers you know, virally, let's say, that means that the product needs viral features and things like that to be able to do it, right? So, you know, the first thing you want to kind of think about is kind of what the pain point is of the customer and go through that entire exercise, figure out who the customer is, what their needs are. Then eventually you can, you know, figure out how to go out and build the product. Once you have that, you know, what are the next steps? So maybe we can start— okay, yeah, we can put that in as kind of like the baseline, right? So you know what to build now, basically, you know, like, at least what you should build initially, right? If— and you're not a technical person. Well, a couple things.

You—

I did— this goes hand in hand with recruiting people, by the way. So in my opinion, you need to really educate yourself on how to build stuff. That doesn't mean you should be good at building, but at the very minimum, you should do some Codecademy to understand how code works. I think you should do, at a very minimum, play around with mockup software and stuff like that to really model out how this product works in detail. You know, definitely, definitely should create like some sort of a spec for your own sake, right? Just you could really understand, like, if I select this button, it goes to here, and if it goes to here, it goes to here. And thinking through all these different workflows to your product, and obviously be like, oh wow, this is way too complicated, shouldn't be this way. You need to familiarize yourself with that so that you can actually speak with various other potential people that may join you and really truly explain how the product works and why this is so important. And also understanding it end to end, like what are the different parts, like this is what the database does, this is what the frontend does, all these different things. And it's important for you to at least familiarize yourself on a high level with those concepts.

Yeah, and I think we're touching kind of on the tip of the iceberg of like where you actually run into problems, which is in the product development phase.

Sure.

And, and I kind of wanted to talk about how to, how to mitigate some of that and how to work around not having a lot of technical skills beyond just learning, you know, like very basic coding. First up is you're going to have to bring someone on at some point. Uh, should that be in-house or outsourced if you're turning an MVP into a product?

Yeah, it's at the earliest stages is always better to have somebody in-house just because it's difficult to, to iterate quickly with with the contractor. So the way a contractor or an outsourcer works is like this: you create a spec, you give the spec to the contractor, and the contractor develops that for you. Then you launch it, then, uh, you see if it works or it doesn't. Most likely it won't work. Then you fix something, then you go back to the outsourcer, then you give them the spec again, rebuild, right? So I know we're looking at like, you know, iteration cycle of months, in the best case scenario, weeks, right? And ideally what you want to be at is weeks, you know, it's like weekly. So when I have— when our companies have teams of people working on stuff, I'm getting like, you know, betas and alphas on TestFlight, you know, on a regular basis, right? So, you know, I just— I literally just got one the other day from one of our portfolio companies, Tempugo, right? Like just working on this product called Wadix, which kind of saves time from waiting in lines, right? It's just like bing, bing, bing. It's like, it's like every week they're just like notification, notification, and it's even faster, right? So, you know, like those things are, those things are important. Like the faster you can iterate, the faster you can move. So the better it's, but you're better off trying to find people in-house. Now, you know, that goes, you've got, you got to balance that against the fact that you might not have anybody. Right. And so you want to try to, you do want to try to make progress on your business while you're recruiting people, which can take some time. So, you know, in some cases it may, it may help for you to validate some of your assumptions with like a very raw MVP that requires very little code and things like that so that you can really like de-risk the value prop even more. Hmm.

If you do end up going with this kind of like outsourced route or maybe remote work route, How do you manage those technical projects as the founder?

Yeah, I think I want to separate the remote with the outsourced. Okay. So let me start with outsourced and then we can go to like the remote.

Okay.

There's quite a bit difference. So with outsourcing, everything is built based on the spec. So you need to create a very detailed spec. The more detailed your spec is, the more accurate the quote is. I can't tell you how many times founders send us like a quote that they got from like some outsourced developer and it's like, wow, your product's like $3,000. And then I look at their spec and it's like super vague, right? It's like, nah, there's no way. Like this person is clearly like, you know, like not understanding what you're trying to build, right?

It's all like front-end stuff.

Impossible. Yeah, basically. But mostly, but also even with like really good like contractors that actually kind of understand that you don't know the back-end work that's involved and you try to spec that out. It's still not detailed enough to where I understand. Like, so it starts with the design, right? Like in your case, like if you're technical, if you're not technical, you need to be a good product person. You need to become a good product person as a part of this. So a good product person can set schedules really well, starts to consent, can start to understand kind of when things go, are going in the wrong direction. We'll cover that later. And then also as a non-technical person, you probably need to be pretty good with mockups. Right? So you should be able to design mockups, do a very, very detailed spec, and then what you want to do is start like talking to contractors, getting bids and things like that to ensure that like the timelines and everything kind of like match up, right? And then you ideally want to create some sort of payment structure with those contractors to ensure that they're basically delivering on time. So, you know, obviously you don't want to give them the full amount right away. Right? You probably want to give that in some sort of installments until they reach this build. The most important thing that you should remember is that a contractor needs to show you that this works in production. If you don't understand what that means, don't worry about it. Just say you— everything that they show you needs to be shown in production, right? So what ends up happening is, is that sometimes the code works really well on someone's own computer, for example, or laptop, whatever. But, you know, it might not actually work well on the live server or wherever the application is hosted, right? And so sometimes what happens with, you know, contractors is like, look, look, it's working, the demo is working great, but it's like working live on their, on their own laptop or something like that. What you want to be able to do is show it that it's actually like working live in the way it's supposed to work live, which is hosted somewhere. So, you know, you want to have milestones around this, around actual delivery, right? Otherwise there's— because there's a big time between like, uh, you know, the amount of the— when showing something in kind of a demo format and then doing all the things necessary in order for that application to actually work in a live environment. So a lot of the milestones that you create around, uh, with contractors need to be around basically shipping something into production and having very clear understanding. Once you give somebody that spec, okay, that spec needs to basically be locked down. This is also how founders run into trouble. They start with a spec and then they're like, well, can we add this feature? And we add this other feature and we add this feature and this other feature. And then all of a sudden the, the, the, you know, the, the project gets delayed by 6 months and the cost goes up exponentially. They get all upset with the contractor because they're like, well, the contractor didn't say this or that. But it's like really more— a lot of it is just bad like management, right, on the founder in many cases. Right. And so this is kind of where things run into trouble. Then, you know, you got to basically make sure that it's in the contract and how you talk about that. There's clear communication, meaning that every single day we talk at 9:00 AM, we're going to talk about this. We're going to have a daily standup on Monday. And we're gonna do a demo on Friday, right? Like classic, like agile is what I'm suggesting here. But like whatever that is, you need to have daily conversations that way the schedule doesn't slip. So that's contractors, you know, as far as like remote workers. So remote is the future, and this is probably where a lot, if not all companies are gonna go. The key to remote is that you need to overcommunicate. If you don't forget, if you don't, if you remember anything about what I'm about to say, is just overcommunicate with remote employees, meaning that you need to overexplain things on Slack or Skype, whatever tool you use. Don't, don't assume somebody's going to interpret that, right? So that means you have to write more. That means you have to write things every single day. That means you can't say, oh well, I just assumed that this person understood it because I understood it. That means you didn't explain it in enough detail. So that's number one. Number two, Always try to get that person to be on video, okay, at some point. Like, you cannot build a culture over like text, right? And so you want to try to have multiple meetings on video all the time in order to be able to ensure that the culture of the company that you're building is, you know, something that's scalable. So you want to try to do that right away. And then you need to use tools. Right? You need to use tools like Asana or Trello or whatever project management tools to ensure that basically everybody is aligned. So, you know, if you're going to create a product, you probably should look, look into agile methodology and create like a sprint. So what I like to do is like weekly sprints, you know, and we kind of set up the sprint every Monday. And usually on Thursday or Friday, we'll do like a kind of like a demo or we'll evaluate kind of what's happening and things like that. And then, you know, push things to production or fix some things and push them to production the next week, right? So basically, if you can create some sort of cadence and a sprint, that way everybody's kind of like doing— knows what they have to do. And in every single one of these tasks, they're like very detailed and they're explained in detail so that everybody knows what they're doing. But don't write paragraphs, okay? Just bullets, right? Bullets so that people can understand and skim it. Yeah.

How do you know if you're, you're asking too much or too little of your remote employees?

Well, you can tell when you're asking too much because the schedule starts to slip, and you're— so that's one, one way, possibly. You know, if a lot of tasks don't get done for some reason, you can, you can kind of start to see— this is why I think it's important to have a tool, right, where you kind of see the tasks like visually. Personally, I like that. So that, that's one thing. However, with engineers, one of the things that you want to make sure that you understand— like, the engineer has to give you a good explanation for why the schedule is slipping, right? Because once the schedule slips one week, that means that the next week is going to be delayed, which means that the week after that is going to be delayed. So it's like, you're like not going to be delayed once, you're gonna be delayed across the whole series of sprints that you're setting up. So, you know, if a developer constantly misses the forecast that they make, then that's usually a warning signal that the developer is not working hard or doesn't understand what they're doing, or that they just simply can't like estimate things very well, right? One of the things I do in order to help our developers is that usually when they give me an estimate, I usually double it, right? And so that way like there's plenty of leeway there to ensure like if something didn't go right or wrong. So if somebody tells me I think that that's gonna take like 4 hours to do that feature, okay, I think it's gonna take like a day, right? And so I— that's— those are some of the things that I do all the time to try to kind of buffer everything. And you as the product manager needs to do— needs to create some sort of buffering system. But if the schedule is still slipping after you've already buffered it by like double, right, then— and, and the person's constantly missing their forecast, right, then that's usually like a problem, right? And so then that's something you're gonna have to address.

Yeah, so I know you have a lot of experience managing remote devs. You also have experience hiring them and kind of like knowing where to look. So where do you look to hire good remote devs and how do you onboard them?

Yeah, well, there's a lot of services out there that are actually quite good. So, you know, I want to give— I guess I've got to give a plug to Toptal, right? Like, I've had a lot of good experience with Toptal personally. They do a really good job at like screening like developers and they force developers to take like a test. So that's a really good one to to look for so that, you know, the other thing is like a personal network. So for example, during, in the, in the Founder Institute, there's the, the network is so large that we have a pretty good idea who's good and who's not, particularly as a remote contractor, you know, building out your team remotely, that's a whole different thing where you're like trying to have somebody join you as a potential co-founder or something like that, or a potential employee. That's, that's more like running like a job search process versus like, you know, trying to hire a consultant. Consultant.

Yeah, so this, this almost seems like a full-time job itself, like between the, the onboarding, the hiring, the management, uh, of all these processes. Should you just hire a project manager?

No. Um, and you know, as a founder, you're running multiple full-time jobs at the same time, and your workload is really high. And you know, that's the part— that's part of the way this goes, you know, like this is this is one of the trade-offs, right? Like, it's like you, you have, you know, it's, it's funny. That's why it's such a myth when people say, oh well, you know, I want to, I want to go and start my own business because, you know, I set my own hours. Exactly, set my own hours, be my own boss. And it's like, first of all, you're definitely not your own boss because everybody's your boss. Your employees are your bosses, your customers are your bosses. Like, everybody, basically everybody's your boss, right? Right? So you have more bosses than you ever have. And, uh, you know, it's like, as far as the time commitment, it's like, yeah, well, pick whichever one of these 80 hours, uh, a week you want to work, right? It's like, this is part of the game, right? So this is— but again, that's why your vision is really important. Like, this has to be something that you care so deeply about that it's worth making this type of sacrifice for, right? So that's something that's more like a philosophical thing to think about, but You know, definitely don't believe that you should necessarily hire a project manager or something like that. It definitely helps if you can, you know, flank your team or yourself with like a technical person that, you know, has some experience with managing projects. Or, you know, if you are going to use a consultant, make sure that that consultant has worked with lots of startups and you interview their startup clients and you figure out at what stage exactly they engage with them, right? Did they engage when they were large and they were just kind of like flanking their own team, or was it like the first, you know, it was just them by themselves and they're one other person and that's it, and that's when they do it. So you gotta get some references there, right? And so that's also like really important when you kind of think about this.

Yeah, I also wanted to touch on, um, going back to kind of like the both like moving from MVP to product stages. As somebody who like doesn't have a lot of technical experience, how would I pick the right technology for whatever I'm building? Like what criteria should I use? How could I identify things that don't work?

Yeah, in my opinion, um, you want to use technology that a lot of people use, right? So just remember that if you don't remember anything else, right? Programming languages where there's lots of people that use them are really important, and the reason for that is because when a lot of people use this stuff, there's a lot of documentation on this stuff. So when there's a lot of documentation, that means that, you know, an engineer can find the answers that they need faster you know, and therefore your— the, the, the product gets built faster. It also helps you find more engineers that know this stuff because a lot of people use it, right? So if you're doing like web development, right, like, you know, using like Ruby on Rails is, is probably a decent idea. Same thing with like, you know, uh, you know, like, like JavaScript and stuff like that, just because, you know, like, it's— they're just very commonly used. They're very robust as well because they've used so much right now. So it's like really important that you do that and look for very large communities.

So what do you have against Visual Basic?

Nah, I don't have that much against it. It's all good. You know, the other thing I was gonna say too is like also work with whoever your engineer and lead developers, whatever they really want, as long as they're not using like some super obscure thing that they're using just because they think it's cool, is, is, is, is, then I would say just, you know, whatever makes them happy too, is that's also important.

Okay. And so I kind of wanted to go back to like vetting for remote employees. So if they do have like a good score on whatever hiring platform you're using, what could you assign them that would like show that they'd be a good fit for the technology that you're building? Specifically?

Yeah, that's, that's a, that's a good one for sure. So there's services that help you create tests for, uh, potential developers, right? So TestDome is, uh, is a service that I use quite a bit where I can create like several problems that I know, and then I can kind of see how they score against other people. So that at least gives you— it's like, okay, this person kind of knows what they're doing, and that's like a first screener, right? And then You know, that, that I would say that's the first step, right? But honestly, like, the best thing you can do is to do like some sort of a project together, not only for you but really for them, particularly if you're onboarding people that want to just join the mission. We're not talking contractors here, we're talking like somebody that wants to kind of like join you. You want to ensure that this is a good fit for them so that there's like alignment, right? So I would position it only for almost from their perspective. Let's see if we can do a test project together. Maybe we can go to a hackathon together or something and build, build something. Let's see how each of us reacts under stress and see if this is someone that you want to work with, or if I'm someone that you want to work with personally, right? Because if this does end up working out and we end up choosing to kind of work together, we might be working together for like 10 years, right? And this is a big— this is a big deal. So we just might as well just be safe, be safe right now, try to do some couple test projects and build it and things like that. And if you're a complete like noob, like non-technical founder, then always use that advice I gave you earlier where it's like, are they basically like reaching the milestones that they forecasted? Right. And if they continue to slip on a regular basis and, you know, like the excuses are kind of the same or not as great, then, you know, you probably have a problem, especially if you've doubled the amount of time, right? Because that means that you have a really hard time forecasting what you're going to build, in which case it's going to be very difficult for you to meet your forecasts.

Yeah. And so we've touched a lot on the, like, the programming side of this for, like, software products. Uh, how does this play out for hardware?

Um, I mean, I don't, I don't know that— yeah, I mean, hardware is a whole, a whole other can of worms, right? I mean, it's, it's building the, the thing initially is not necessarily easy, but it's not like the hardest part. The hardest part is building the thing at scale.

Yeah, and getting inventory.

Yeah, which means that you need to like— a lot of people need to have, um, or find people that can help them, for example, in China and other places like that where they can actually go and develop and build a factory and things like that. So you do end up spending a lot of time overseas setting things up and all this, right? So It's different mostly because you need more money. Your iteration cycles are a lot slower, which is why people say hardware is hard, you know. But it still starts first with like kind of like building some sort of a prototype with off-the-shelf tools if you can. You know, what's happening right now is that there's a lot more spaces where there's like, you know, maker spaces, right, with like tools and like 3D printers and stuff like that. And that's usually where the first thing happens, right? And then once the first thing happens, then what you do is you generally take that thing, plus the— which is part of the spec that we talked about— and then you go to like various like providers. And there's like service providers like Source Select and things like that where basically you just go out and like, like they can maybe help you actually bring this to reality. And they have connections overseas and things like that where they can help you manufacture a first batch, right? Um, and so then, you know, that's, that's a different process, right? But it's still, um, you still need some people to help you. And so you're better off understanding as much as possible about how to do this in order for you to be able to speak somewhat intelligently with a person that, you know, may be able to join you, right? So you should probably learn about like what the supply chain could look like, what are the parts of this thing, what they do, and all that.

Okay, it sounds a little like there's, uh, there's like less moving parts than in software in terms of like, you know, iterative development? Because like once you have your CAD, you can kind of like turn it out.

Yeah, I mean, there's more moving parts actually physically, right? But, uh, but, uh, you, you can say that the, the development cycles are just slower. Okay. There's just no way to do it that quickly. Um, but that's what's cool about what's happening right now with all these makerspaces. You can actually build a little prototype. If it's a consumer product, you can put in front of people. If you're doing B2B stuff that's much more involved, you know, and you need to go through the approval process. But the benefit of the B2B stuff versus like the B2C stuff— so for those of you out there that are building hardware for like, I don't know, like a factory or something like that— if the pain point is so acute for that company, they may actually want to pre-buy the thing, and then you can use that to go around your first batch of things. And then you've got some little bit of revenue that kind of works. Then you're like, oh well, I got a customer, I could maybe even raise some money off that, or you know, maybe there's enough margin there where I can go and build another batch, right? Um, or something like that, right? So it's, you know, so it's, it's helpful, right, to have that.

That's super enlightening. I kind of want to dive back to software, changing lanes back again. Yeah, I wanted to discuss the future of software development for startups. Are there any up-and-coming tools, or do you think there's a possibility for tools to make this process even easier for non-tech founders in the future?

Well, I mean, I can give you my personal opinion on this one. My personal opinion is that we are gonna have more one-person, like, no-code startups, right? We're kind of already seeing this a little bit with Airtable and some of the integrations. Like, if you think about what Airtable is at its core, it's basically like a database, right? And so the future, I think, will be where you start to see people basically hack together things based on off-the-shelf tools that are available and you can basically make them work together. If you're looking at like just the design tools right now, and like, you know, Figma is like this new design tool that's like really useful that helps you build like various like prototypes. I'm sure that, you know, that that can be part of this process as well. What's happening with like Squarespace, what's happening with Shopify, right? Like you can just go out and like, what's her name, like the Kardashian, right? Like, uh, it I don't know which one.

I can't help it.

Yeah, yeah, yeah, right. She's got like a $10 billion business, right? And it's literally built on top of Shopify. It's crazy, right? Like, it's just wild, right? So I think that for a lot of you founders out there that are building companies that do require some tech component, but that's not the core value prop, like, there's already a lot of tools and that's only going to continue to improve. I also think that moving forward, that a lot of this front-end stuff that's being developed will continue to get easier to develop for like non-technical people, certainly to get to a prototype, certainly get to revenue, certainly to get to a point where like, okay, I can maybe hire somebody or bring somebody on board. So I think that that's, that's really important. On the other hand, I also think that the domain expertise on the other side is much more important now, right? Like machine learning, uh, Artificial intelligence, like, we haven't even scratched the surface on what we can do on that right now. It's just kind of like this overused buzzword, but it's like there's so much there, right? A lot of blockchain—

it's just a bunch of if statements.

Yeah, maybe. Yeah, kind of in a way, right? Like, that's— there's the— there's very few companies that, uh, are truly doing like artificial intelligence. If anything, it's mostly like machine learning, um, branded as— but anyway, that's, that's a tangent, but different podcast. That's a different podcast, right? But then Right. All the blockchain stuff requires pretty deep, like, technical expertise, right? So like, there's still a huge need for all this stuff. I just think that for like some certain products, like, you're going to start to be able to see like a one-person thing where they basically built this thing on their own. They used Instagram to go make it go viral and crazy, and then becomes like, you know, a billion-dollar business. It's just like, you know, some, some lady in, in some random place to, you know.

Yeah, yeah. Silicon Valley will be dead.

Yeah, maybe, maybe. I don't know about that. I think the network effects here are really strong, but ultimately I do think that we're probably gonna see, see that happening.

Cool. So we kind of touched briefly on specs when we were talking about outsourcing and like how to deal with outsourcers. Could you define that on, on like a, actually, you know what, better yet, can you give us an example of what like a perfect spec looks like?

Yeah, I can't give you an example of like a perfect spec without like showing you kind of some, some things that I've seen, but I can talk about maybe like some things that a perfect spec includes right away, right? So number one, you definitely want to have like an objective, like why are we doing this, like a section, like why are we doing this, to try to really understand this. Also, really good specs tend to have what are called user stories. So Customer A, her name is Nancy, she is the R&D manager for this type of company. What she does is this, this, this, and that. And then, you know, this is how, how she will use this product. You know, step 1, she goes here using a mockup. Step 2, she does this. Step 3, she does this. Step 4, she does this. And then you walk through all these different workflows, and then you start to really understand from their perspective kind of how to use it. Now, if you're doing a B2B product where that has multiple, like, people that touch the product, then you need multiple customer personas, right? So same thing with like social networks and things like that, like how they interact, games and stuff like that if they're multiplayer games, right? That's a place to start, right? So that's number one. Number two, a lot of people like to put this as number two, actually is like definitions. Like, you know, I generally like to start with a persona, but it doesn't matter, right? So you want to have definitions, right? Because you want to have to ensure that we all talk about the same thing, right? So what does a user even mean, right? They could be be multiple things, right? Um, you know, what does, you know, this action mean or whatever. So then you set these up and then the rest of the document basically references these things, right? And then you basically define each feature in as much detail as possible. So I like to do it visually first because that helps me kind of get it out there. So if I'm going to go and create a mockup of something, I'm going to create the mockup. It's going to have this button, it's going to do this. And then I explained that in text, like, right below.

So it's almost like a pretty poor illustration of, like, what your app or site would look like.

Yeah, you can do this on paper if you like. There's also really good tools out there, you know, like, you know, I mentioned Figma earlier, but there's also tools like Balsamiq and other stuff like that that are literally designed for this, where it's just like all drag and drop and things like that. And I find that to be really helpful too. So we definitely put— I definitely like putting that into a spec as well. And then I have something, right? So this is kind of like the ideal spec. Once you get to know a person and you've worked with that person for a very long time, like for example with, uh, you know, the, the engineering team that, that I, I work with and I lead, our specs are not as detailed anymore because we all know what we're talking about because we've been working together for 3 or 4 years, right?

Probably like worked on the same feature.

They're a little bit less, a little bit less sophisticated. But initially, once you're onboarding somebody, you need be as over-communicate rather than under-communicate.

All right, well, it's been awesome, Mike. Do you have any parting advice for some of our non-tech founders out there?

Yeah, I mean, really educate yourself. There's just like a— there's so much information now, it's great. So like, pick like the resources in that space that make the most sense. Get your hands dirty, okay? Like, you know, for example, if you're building an app, Apple provides a very extensive like user interface, like guideline on how to build stuff. And, you know, download, for example, Xcode and play around with how they, with how they work. They literally teach you how to build an app, and it enables anybody, like, I mean anybody, like, there's no— to build, like, their first app using mostly drag and drop and limited amount of code, just so you can understand how it works. So this is just that, but you can do the same thing with, like, websites and stuff like that. Hardware— if you're a hardware person, just go to, like, the local maker place or try to kind of put, bring some things together on your, at your house to kind of make this thing kind of work by, you know, taking apart toys or whatever and building it out, you know, just so you can understand end to end what's going on. And so you can basically communicate better and over-communicate rather than under-communicate with everybody. Just force yourself, right? Like it may be clear to you, but if somebody, if you're talking to somebody over Slack, it might not be clear. So you just gotta like make sure that it's clear, make sure that you get people to understand what's going on and do that. And, uh, just stay on top of the schedule. If things start to slip, you cannot allow the schedule to slip too much because then a month delay will cause an actual 3 months of delay from launch, right? So just make sure you stay on top of that.

All right. Well, thank you so much for joining us, Mike. Ben, awesome, awesome. fi.co/podcast for more episodes. /subscribe for our newsletter. Thanks so much, everyone.

All right, bye-bye.