Lean By Design
Lean by Design delves into the dynamic world of biotech, pharma, and life sciences, focusing on operational excellence through effective workflow and process optimization. Join hosts Oscar Gonzalez and Lawrence Wong as they engage with industry leaders who share their insights, innovative strategies, and real-world experiences in transforming complex challenges into streamlined, efficient solutions. Through thought-provoking conversations, you’ll gain practical tips and inspiration to drive continuous improvement and success in your organization. Produced by Sigma Lab Consulting, Lean by Design empowers you to enhance productivity and innovation, one process at a time. Listen on Spotify, iTunes, Apple Podcasts, or wherever you get your podcasts.
Lean By Design
0205. Before You Scale: Designing Workflows That Set Teams Up for Success with David Hirschfeld
In this episode, we sit down with David Hirschfeld, 35-year software veteran and founder of Tekyz, to talk about why designing workflows before you start building is critical for sustainable growth.
We explore how the speed of modern tools and AI can create a dangerous illusion of progress, causing teams to skip planning and discovery. David challenges the common “build while flying” mindset and explains why taking time to think first actually speeds you up.
You’ll also hear his contrarian, but highly practical, "Launch First" approach, where sales and marketing happen before building. It’s a powerful method for validating product-market fit early, avoiding wasted development cycles, and moving fast without flying blind.
Whether you’re launching a startup, building internal platforms, or scaling R&D, this episode will reshape how you approach planning, execution, and risk.
Learn more about the Launch 1st Method at https://launch1st.tekyz.com/
Connect with David at https://www.linkedin.com/in/dhirschfeld/
Ready to assess your organization’s efficiency? Connect with us at leanbydesign@sigmalabconsulting.com to uncover high-impact improvement opportunities. 🚀
Learn more about us by visiting: https://sigmalabconsulting.com/
Want our thoughts on a specific topic? Looking to sponsor this podcast to continue to generate content? Or maybe you have an idea and want to be on our show. Fill out our Interest Form and share your thoughts.
Welcome back to another episode of Lean by Design Podcast. I'm your host, oscar Gonzalez. Alongside with me is my co-host and friend, lawrence Wong.
Speaker 1:There's a couple things that we've talked about quite routinely with the work that we do and that is really pulling these frameworks and these theories from adjacent industries and domains that are really at the essence and the core of operational excellence and process improvement. You know, one of the main questions that we want to talk about today really comes, I think, in a few anecdotes or sort of phrases building the plane as we're flying it or laying down the track while we're driving the train. And what we're talking about is, regardless of whether you are developing an internal platform or scaling R&D operations, there's just too many teams that are building without designing workflows that are going to lead to that solution, and what you're doing is you're leaving out the essence of what is going to generate sustainable success. So I'm excited today, leaving out the essence of what is going to generate sustainable success. So I'm excited today we have David Hirschfeld, veteran software designer, founder of Techies, with over 35 years of experience in tech innovation, ai-driven workflow design and startup strategy.
Speaker 1:His perspective really on how to use AI smart workflow design lean methods, reducing your overall risk and increasing the clarity from the beginning how to Use AI's Smart Workflow. Design Lean Methods, reducing your Overall Risk and Increasing the Clarity from the Beginning, launching your Efforts and your Initiative with Confidence. So I think this is a great episode, whether you're a startup founder or an enterprise leader planning on building the next thing. David, thank you for joining us today.
Speaker 2:Thank you, guys for having me. I'm really looking forward to the conversation.
Speaker 1:So I guess, as I alluded to when I first started talking, building the plane as we're flying it, laying down track while we're driving the train, why do we find, why are we finding, so many teams that jump into building before designing, before drawing or sketching out a map of the way to get there? What do we actually see when people are trying to launch products or assets?
Speaker 2:So I think there's a few reasons why that happens, why people rush into the development too quickly.
Speaker 2:One of them is just the familiarity with automation internally. One of them is that they're excited to get a product built and tools have become so consumable. You can build stuff so much more quickly Even two or three or four years ago you could, and today it's like orders of magnitude much faster with AI and so they think, okay, I can just get it out there and have something and start building what I believe is going to be successful. And the third is missing the philosophy that says go slow to speed up, that you have all the pieces in place first and you have a methodology for validating that you've got the right pieces in the right places and a way of testing that. Then the difference that will make in terms of your level of success and the speed at which you can actually grow and build. People that don't have that philosophy don't understand the you know, don't understand why it's so important. There's so much enticing us to move quickly now because of the speed that the tools work in.
Speaker 1:That's a great point. I think even in our own work, lawrence and I, just the things that we're able to do now would not have been possible three, four years ago. You know, in just this short time span. You know, your description of it really makes me think of a street race of vehicles when you're trying to lay on the gas.
Speaker 1:If you hit the gas too hard, right away you're just spinning your wheels, and I think that's something that we end up seeing is sort of this false start where we have everything, we think we have a vision, but we didn't really paint the road for anyone within a given team. It was again whether it's that familiarity or that excitement which is great understanding that there's still a journey here, no matter how short, providing the right product for the right market space. When we talk about these teams that are moving too fast, in the beginning usually things seem very good. Everyone has tasks, everyone has the things that they need to be doing. When do we start seeing those signs that they might be moving too fast or that they don't have the right structure or clarity to where they're going? What are some of those things that?
Speaker 2:we start to recognize. Oh, that's an interesting question because we can break that down from a couple different perspectives. One is, let's say you've got an immature team in terms of their experience level and skill set for developing anything. So teams like that, they just don't know what they don't know, it's the evidence that they're moving too quickly. Developing things is pretty obvious, like right from the beginning. Not necessarily obvious to them because they don't have anything to compare it to, but obvious to anybody with a real decent level of experience. Now let's say you're dealing with a team that has a lot of individual experience, not tribal experience in terms of the team working together, but individual experience I've been developing for 10 or 15 years or as a individual contributor.
Speaker 2:It seems like that moved too quick because there isn't political will for the people that are driving the project in terms of making sure that they understand what it is they need to build and for whom they're building it before they launch into building it. And usually that comes from a philosophical problem related to belief in what you're doing. So when people come to me and they want to build a product and they say I believe I've hit on something really big, I know that it's going to be wildly successful. It's very likely this could become a unicorn. Those are like code words, for I'm going to fail. Red flag Right, exactly. And if your development team is being driven by that non-technical visionary, for example, then they're just trying to satisfy the requirements that they're given, which is to deliver something quickly based on what this person believes. They may even put internal automation in place for how they deliver the functionality, but then they deliver something nobody wants to buy. So that's the other side of that equation. So teams that are really mature, that understand the planning part, put all the systems and automations together in terms of how they deliver and I can talk about that from a lot of different perspectives and we probably don't have enough time, but you can tell teams that work really well in that way because they'll do many builds a week.
Speaker 2:Very often they get pushed to production and there's usually have decent quality for every single build. They push Production being, while it's in development, the testing phase. Once it's in production, they can add new features and capabilities daily if it's required, without risking the architecture, and that's a mature team with a very automated pipeline for delivery, right? So, because testing happens automatically, as well as code review, vulnerability tests, and everything happens as soon as you do a check-in of the code and then you can just push it to production. When somebody touches it and says, yeah, this is the feature I wanted Now, but on the other side they may just be pushing into production the wrong product because nobody spent the time to do all of that slow down, to speed up stuff in the beginning.
Speaker 2:So I always say to new founders if they don't have this perspective which most don't probably 90 or 95 out of 100, don't just naturally do this where they step back and they say what is it I'm assuming in the delivery of building this new business or this new product, and if they're really honest with themselves, they're probably assuming everything. So now how do I take the black robe off and put on a white coat and say I'm a clinician now and I have a hypothesis. I have a way of testing all these assumptions and some of them are going to prove out wrong. And then I have to have a way of pivoting and understanding what that means in the context of a business that I may be wanting to build and some of them may be right, and then so I can pursue those and put a plan in place to implement that.
Speaker 2:If you're able to test it and there's different levels of testing your assumptions when you're talking about building a business what you're ultimately going after is product market fit in the earliest stage of your company, and product market fit for anybody that doesn't know what that means simply means that I've got a product and it's at a price that people will buy in a high enough volume that whatever it costs me to acquire a customer is roughly assuming this is a classic SaaS model is roughly one third of what the lifetime value of that customer is, and that one third may vary depending on how we were calculating lifetime value. But that's product market fit, which you don't get until you actually start to generate revenue from sales. Everything prior to that is trying to prove that you've probably got product market fit, but probably is not definitely so, which is why launch first. The whole concept is to do pre-launch sales as a way of validating your market, validating the early adopter, because it's not just product market fit in general, but it's who is the early adopter?
Speaker 2:What are their top two or three problems that they are really suffering with that you're attempting to solve and, out of those problems. How much do those problems personally impact them? You need to know that because you can't get their attention if they don't feel personally impacted by those problems at a high level. And how much does it actually cost them? Because it needs to cost them enough so that you can charge enough to reach that three-to-one ratio. And so how do you find that early adopter? And then how do you validate them? So these are the things that almost no startup does, which is why the failure rate for SaaS startups is so crazy high.
Speaker 1:There are so many threads that we could pull from there. Lawrence, Please go ahead.
Speaker 3:Your point about product market fit is spot on, because I think a lot of times, even beyond just companies developing a software solution, we have, you know, from internally in the company, when we start to do these improvement projects to help other departments, there's not enough discovery done to really figure out what is the actual problem, that you're building the solution for understanding what they're struggling with, and there needs to be more of an emphasis on digging out what are those mechanics around the problem that we're looking to solve.
Speaker 3:And then you mentioned initially about this whole idea of the team structure and dynamics, which is, I think, a really underrated point, because you can have a really good problem to solve, but if your team isn't really structured in a way to debate or work towards a certain goal, the whole thing's going to fall apart and you really need to have a mixture of. It may help to have people that are not as experienced, but your benefit from having a mixture of experience levels on the team to just see things differently. And sometimes, when you have a bunch of people that are too experienced, you run into that, like you said, political situation where, oh, I know best because I've done this X number of times but they have not been exposed to some of these newer, maybe, methods of creating a product or service Right.
Speaker 2:Yeah, of creating a product or service. Right, yeah, and when I said a lot of experience, I meant a lot of broad experience, not just in one direction. Right, because you're right, that's exactly what happens. People get entrenched. Why do you do it that way? Because we've always done it that way. Right, you know, that's like the kiss of death. I've always done it that way and it's always worked. And I said, okay, fine, you know, I've got stories that really bring that out when somebody says that to me, how to get them off that position very quickly.
Speaker 2:But what you need to know is who's responsible for what in this project? Right, the RACI matrix or whatever you use in terms of mapping out level of responsibility. And you need to have that. You need to have a general understanding of repositioning that your focus is about the problem, your focus isn't about the solution. So what happens very often is, as soon as somebody identifies a problem and they think I know how to solve that, they get all excited about the solution, forgetting all about the problem, and those kinds of founders fail at very high numbers. Right, I'll ask a founder so what problem does this solve? And they'll say, oh, this makes it much easier for a real estate investor. To da-da-da-da I say, oh, that sounds like a benefit to me, but what's the problem that's solving? Oh, oh well, we're building this really cool search engine that gives you all of this capability around real estate property attributes and things. I said, okay, that's a nice feature, but I don't hear a problem statement. And then they start scratching their head because they're like what is the problem? Because they frog, got all about it. They got all excited about solution, and that's a surefire way to build the wrong product.
Speaker 2:Founders that love the problem and want to spend their time talking to customers about their problems. Those types of founders often, if not most of the time, find a path to success where the solution is nothing more than just a natural conclusion of the mitigating process to solve that problem. Right, not the thing to be in love with. Be in love with the problem because that problem will shift and change and have nuance, and you only get that because you're spending all your time talking about the problem. So, and the way you do that is so.
Speaker 2:What is that problem? Are there other problems related to that? How has that problem affected you in the past? What kind of personal impact does it create for you. What's the actual cost of that problem? Have you found ways of solving it in the past? Why didn't you stick with that? Have you tried other software solutions? Never talk about the solution, because the solution doesn't matter. The only thing that matters is the problem and if you really understand it at that level, a 360 degree, fourth dimensional kind of understanding of the problem and its nuances and the people it affects and the impacts it has and things like that. The solution is just sort of the natural consequence. It's really simple and the solution has very tangible value. That's easy to articulate because you can articulate from the standpoint of articulating the problem.
Speaker 1:I think that's a really great point, david, where you know, having to focus on that core problem that you're trying to solve really brings alignment across everyone.
Speaker 1:That's a part of the team, because now you're not thinking about what is that special thing that we can create. You're focusing every move that you make on resolving this issue that has this level of pain, that costs this much annually, that has this psychological effect on people, you know, et cetera, and the list goes on. It's really a way to have an empathetic design to your product, because you're starting to now understand that potential client or customer at such a deep level. You know this takes me back to my design thinking day, where you talk about human-centered design, what is at the center of this problem and who is impacted, and really using that as a driver. When we talk about designing the end-to-end and recognizing differences between immature and experienced teams and that challenge that a lot of folks might have where they're, you know we have all that philosophy and then what does that actually mean? What are those major milestones that would take us to this philosophical view of the problem that we're solving for the patients and the clients, the customer at the end?
Speaker 2:In the process of doing this, you very often not always, but very often find out that the problem that they articulated is not the problem they need to solve. A good example is I was working with a guy who had a really successful business network thousands of people and millions of dollars of revenue and he had been doing this for 10 years running. This huge network and it just was building. And so he wanted a mobile app that was going to help people consume, be able to connect with people in the network better. And so we were talking about it and came up with a prototype based on our original conversation, and he said, okay, that's fine, but it cannot add any more time to our Monday prep time. And I said, well, this won't. And he wouldn't let go of that. He kept saying, yes, but if it does, there's no way I can consider moving forward on this now. And then I just pushed the mock-ups aside and say tell me about your Monday prep time, because that was the big problem.
Speaker 2:The whole project ended up being a workflow automation for that Monday prep time and changed the Monday prep time from an eight-hour exercise to 15 minutes by doing this workflow automation. It took a few months to tease out every nuance. Imagine, every single week, getting back seven hours every single week and you're the guy that runs the organization. Listening to the problem and understanding the problem does not always end up driving you into a solution for that problem. Very often you end up uncovering way more important problems that really need to be addressed earlier because they have bigger value and bigger impact. That's right.
Speaker 1:And I think those are some of the challenges to be addressed earlier, because they have bigger value and bigger impact. That's right, and I think those are some of the challenges. You know, when we start digging into solving a challenge or a problem, it just blooms into this sort of unwieldy beast and then you have to go back again to that core problem and ask yourself is this the right problem that we're asking? Is this the right question that we're asking? The more time that we've spent in this consulting organization, it's been eye-opening to recognize the power of the right question, and it's not just about asking questions. It's about asking the right question, the context, the scope, who's involved, what it really means to them, how painful these things are. Because that's the only thing that you're going to be able to focus with and I think you pointed that out where this is the thing that we're trying to solve or this is what we want to do.
Speaker 1:In some cases, you lead with a solution. I need reports and a dashboard. Wow, that was very direct. What's going on here? And it could be something that is a simple workflow change that, to your point, could change something that takes a full day into just a couple of moments. So I think that there's a combination of humility that we have to have, especially when we're doing even for ourselves, where our job is to solve problems. We have to have the humility to go in and continue to ask very naive questions, because we don't know their history, we don't know the intricacies of this company. Sure, it is R&D, it is a product, it's a SaaS tool, whatever the case is, but you have to really embed yourself into the problem to truly find possible solutions that will solve that.
Speaker 2:Well, and very often, like you said, that was a good example. So why do you need those reports? How are you going to use those reports? Well, my CEO asked me for the reports because he needs them.
Speaker 3:You know how he's going to use them.
Speaker 2:Well, I don't really know. Is there any chance we can have your CEO as part of this conversation, because it may not be reports he needs, right. So it may be something completely different. If they ask you for something, you just deliver it. You can bill for that, they'll pay you for it. And then they're not happy, but not because of anything you did wrong, but because the thing you built for them didn't actually create any value, because they didn't understand the problem they were trying to solve.
Speaker 1:Absolutely.
Speaker 3:And the other thing I'll point out is both of you guys have been talking about it is not every problem needs to be solved, not every nail needs to be hammered. Sometimes I think leaders are too in front of the tree, they can't see the forest, and so they end up solving for something that is really minor in comparison to all the other things that are happening. I'm interested, david when you come across founders that are in that situation, or come across enterprise teams that are developing some sort of solution, how do you step back and kind of pull them away from that thinking to really look at the bigger picture? Okay, is this the right problem to solve? You know, how do you prioritize all the different features that you might want to consider for a particular product? How do you guide them through that thinking?
Speaker 2:That one is a little tricky, depending on who you're dealing with. But you try to build a matrix of all the various things that they believe impact their business in a negative way. That needs some kind of automation or workflow or whatever, right? And then try to understand how much each one costs them and who's impacted by each of the problems. The cost may be because of market opportunity, maybe because of physical costs, right, because people have to manually do something. Or we end up paying a lot more shipping because it takes us longer to get this out.
Speaker 2:Well, how much more shipping do you pay? Then you can start to get an idea. And then how much will it cost to mitigate this problem? How much are people impacted and how many? How much is it actually costing your organization? How much will it cost you to implement this change? And from a cost perspective, what's the value of this thing? And from an opportunity perspective, what's the value of this thing? And when you start to build a metric around all this from a matrix and priority perspective, it's much easier to start to prioritize what's more important and what's less important.
Speaker 1:I think one of the things that you're also pointing out is that this process is semi-qualitative. There are some discrete numbers that you can pull out, but there's also costs associated with some of these things. You know, if you're going to try to implement something internally, is there a cost to the slowdown? Because now your teams have to learn a new framework, they have to learn a new system, they have to learn a new technology. If you're not able to use the same workflows that we've been using, which have been really stored in the top of people's minds, how is that going to impact our feeling of unity, because this is all new to us? You know recognizing that some of these solutions may not be as expensive quote unquote. You know that comes on your balance sheet, but when you look at the impact of the people on the teams that are going to be executing these projects, then you can really understand the value, and one of the things that Lawrence and I have constantly been revisiting is the idea of value and also the recognition that you can't really make someone else understand the value that you put into there.
Speaker 1:It's a dialogue. You need to understand what becomes valuable to the patient, the client or, in some cases, your leadership. What is actually valuable to them? What do they really want? Is it time back that they want? Is it things that are more streamlined, rather than having them give you their prescription? Hey, I need you to fill this for me, because then they get filled with it and they go nah, this is crap, that was a bad engagement. Well, you know, it just happened to go that way.
Speaker 2:Right. You should have told me there was something more important that I should focus on, right. Not that you didn't do it right, it's that you didn't tell them to do the right thing.
Speaker 1:Exactly. I didn't get the happy feelings that you know I was expecting to at the end of this.
Speaker 2:Right, yeah. So that example is kind of like okay, we're a hospital and we want to replace Cerner with Epic, what's the risk to your staff? What's the risk to the patients? That's part of that matrix, right, because there's always a risk factor to this whole thing. But very often these changes can be implemented. Maybe not that one, but many of these changes can be implemented in a staged fashion so that it doesn't have a huge impact on the organization. If they have to learn something new, it's something small. Some small piece of the bigger picture that they have to learn's going to have a big impact, and so that's why we have to have you learn that first, because it'll de-risk the bigger implementation later on, because you'll already be up to date on a piece of it. That's important step in learning the bigger thing. So it really depends. This is very contextual in terms of where the company is. Michael Dell I think he said it best in a Forbes interview, I think 20 years ago or so.
Speaker 2:The interviewer asked him what's your secret to your success? He says well, it's not that big a secret. I just focus on whatever the biggest bottleneck is, because as soon as we fix that bottleneck, I know that everything will flow much more freely, which will illuminate the next bottleneck and I just keep following the bottlenecks. That's a very oversimplified way of saying how you prioritize that list, but that does point out the fact that that priority list, the priorities, will shift and change as you start to implement automation, because some things that seemed like a bigger impact and higher on the list once you've solved for a couple of problems, all of a sudden they're not that big a problem anymore because other things start to address or relieve the impact of a particular issue.
Speaker 1:And I think that touches on. You know the outcomes that this sort of effort allows for. It really enables not just the development of the people, but just the outcomes on the other end are cleaner, they are right on track with what's happening. It could sound like a lot of anecdotes like, oh yeah, you know the team is working well cross-functionally, etc. But you really do end up with a different product at the end that is more thoughtful, that has considerations outside of to your point, before its features. You know it's very easy to say like well, it does these things. That's not what we're talking about.
Speaker 1:What are you actually solving? Is it peace of mind? Is it something physical? How are you actually solving? Is it peace of mind? Is it something physical? How are you changing the work that we do? It's going to touch somebody's life. It could touch their life from a work perspective. That now I come into work and everybody knows what they're doing and we just go pow, pow, pow pow. We have a discussion, boom, we execute. It can have impact on the people's lives at the end, where you are designing the right product because it answered the right question. I think that challenge really is what's at the forefront of your framework is really putting you in a position to put pen to pad or digitally, however you want to put it, but really express what is it that you care about. Put it, but really express. What is it that you care about? What is the thing that is really bogging down the potential for your development?
Speaker 2:And not just what you care about it. But why do you care about that? Because sometimes they care about something just because they don't really understand what really matters. Not that you're trying to school them, but you just draw out the things that really matter. They come to the natural conclusion what the most important things are when they understand them better. Um, uh, what you were saying about solving the right problem. If you're focused on the problem and that's all you do is a is think through the problem and when you're coming, you're trying to solve the problem, you're working on software that mitigates the problem, you're still focused on the problem, not the feature. Is the problem solved yet? Do we need to take this further? No, it's not solved. Is it solved enough? Yeah, probably solved enough for now, because we have other fish to fry. Okay, just focus on the problem. And then the solution isn't a set of features that you're trying to sell people, just like you said. The solution is a way you've mitigated the problem with just not a problem anymore, because now you've got something in place that has eliminated the problem. It's not about selling the solution.
Speaker 2:People only buy things, whether it's internally or externally, because they have a problem. They want that problem to go away. There's no other reason that motivates people to spend money on something or do something. I know it sounds weird and it sounds very pessimistic, and I fought this idea for years. Even if you want to go on a vacation, the reason you do that is because you're afraid you're going to miss out and going to live a crummy life, and you want to mitigate that life where I'm not living the best life I could live, and so I need to create memories or do something, and that's what vacations go after. If you felt great and everything was perfect, why would you want to leave and change?
Speaker 1:it. There's a lot in here that I'm sort of I'm pulling from and I'm inclined to agree that there is in some cases there's a selfish tendency that we have to recognize as well. Like I'm looking around now, my computer, the light, the camera, the hub I have to connect to monitors All of these things are to solve specific problems I had, as we were trying to build a podcast, trying to continue our marketing outreach and things like that. So I'm living proof here. But you know, I think what is the outcome of these, of these, these workflows and really understanding that beginning part and becoming empathetic to that end goal? What is that North Star? What does that end look like?
Speaker 1:You hear it sometimes beginning with the end in mind, human centered design, putting somebody else at the center of that. That, regardless of your skill set, of your potential. I see it often with incest, where there's a sell to a client and I might be on the phone call with a partner, with a client at that time, representing them or helping them through this conversation, and we can also do all these things and there's features just getting splashed in your face. Those things are great long-term, but you're not listening to the conversation. You're already creating an upsell without understanding what's going on here with the client.
Speaker 1:So when we see that these things are working and we do take that time in the beginning, there's just that alignment to your point it starts to make things more boring because they're not really interesting. It's not a fire in a trash can ready to burst into flames. It is moving as expected. And it's funny because you talk to your leadership and they go okay, any problems? Well, why do we have to have a conversation just to talk about problems when things are moving smoothly? These are those opportunities where you can start to elevate your work, you can start to upscale, you can start to take on additional projects, because these once burdensome initiatives that were the result of a lack of clarity and understanding of what the real problems are is gone and now you can focus on the actual work and the delivery.
Speaker 2:So this is why it's so critical to distinguish between what's the personal impact that somebody perceives that problem causes them and what's the actual cost, because those are very distinct numbers. Right, you can have a really high personal impact because this just drives me crazy. I have to do it every day at two o'clock. If I forget, somebody's going to yell at me. What does it cost as a result of doing that? Yeah, it costs me, maybe personally, but the company is really not costing us anything. It's just a small thing, but it drives me nuts.
Speaker 2:So I would do almost anything other than pay money for it, because it doesn't really cost anything, and so you're not going to be able to sell it for very much to that person, right? The opposite is true too, which you just talked about. Everything is running smoothly. If we automated this workflow, we could save a gargantuan amount of money, but nobody cares, because we're trying to grow our business, not just make it more efficient. That's where management is right now. Yeah, it would cost a lot, but everybody struggles with this in our industry. Nobody's going to get all excited about making this thing happen more efficiently, even though it'll save us a lot of money. We could charge a lot for it, but we can't get anybody's attention when we go out to start to market it internally or externally. So you have to understand both of those factors the personal impact and who is personally impacted and what's the actual cost associated with that problem.
Speaker 3:The other side of it. You know we've been talking a lot about designing the right solution and solving specific problems, and I think one of the things that gets lost sometimes is, once you solve that particular problem where you've improved the process, there's a bunch of people that come in that have to manage that process. There's a bunch of people that come in that have to manage that process. And so if you build a beautiful app or piece of software for a team, there's a group of people that have to come in and start managing any future changes to it. And sometimes that isn't the most beautifully designed user experience and you have to really understand all the intricacies within that configuration to be able to, you know, build an improvement in and so it right. You know there's a lot of benefit that could come from selecting the right tools, right for the automation and then the workflow design.
Speaker 2:And then the other thing is is just considering how are you documenting all this and if somebody's going to pick it up and go to fix it? Yeah, documentation's huge and that's a philosophical thing. Do you document things in a detailed way and is it part of your DNA to do this right? The other one just is part of the cost of the solution. When you talk about building something that has to be maintained, when you're factoring, what's the cost to mitigate this problem? That's part of the cost that you have to factor in right is the maintenance cost, if there's going to be maintenance.
Speaker 3:Yeah, I know. For us, we usually have one of the extra columns in addition to this is the cost of doing nothing, because usually that being able to measure the cost of doing nothing, the pain really is a multiplier to any of the prioritization that you have for the table that you come up with any of the prioritization that you have for the table that you come up with.
Speaker 2:Yeah, I completely agree. The cost of doing nothing is part of that. Let's say it doesn't have a huge personal impact, but it's very expensive. So what's the cost if we just don't do anything and you extrapolate that out over time and it ends up being significant and even though it doesn't really change your business in any way, nobody cares. But it's other than just from a cost perspective. What would that financially do? How could we change our business as a result of having that saved cost? Is that going to delay us doing other things? Do we have to make a choice of working on this thing that nobody cares about, even though it's really expensive, or working on this other thing that people really want to see happen, for whatever reason? Right, Personal impact is high. Personal impact is low. Can't we do both? If we can do both, then let's keep the conversation going on, the one that nobody cares about, because it's going to give us a lot more money to invest in other areas.
Speaker 1:Absolutely.
Speaker 1:There's so many little nuggets in here, and the good thing is that now we have systems like AI that can help us pull out key features of this conversation. There's so many pieces to think about and considerations that are outside of whatever product or asset you're preparing, and I think that's really what we're trying to hit home here. When it comes to doing things the right way, when it comes to doing things efficiently and things that allow you to scale, either in your size of your portfolio and your projects or scaling into new initiatives, there's a really key moment that happens at the very beginning, and it's not building right away. It's really taking these considerations. You know, looking at programs like Launch First to really get down to the first principles of what you're trying to do and who you're trying to help here. So, as we wrap up, what is one piece of advice that you would give to somebody who's looking to launch, to scale a new initiative, so that Build has a mind, has a path and isn't just this overwhelming, unwieldy beast of people just doing work and doing?
Speaker 2:things. The one piece of advice is your chance, if you're going to launch a SaaS company, is that you're probably going to fail. And if you approach it like that with the idea, okay, all us founders have to have vision, right, we have to have vision and have a belief system that this is worth pursuing. And then it needs to stop there and turn it into a clinical process. So the goal is to turn every opportunity to do a science experiment and try to make it fail as fast and as cheap as possible. And if you're unable to make it fail fast and cheap, then you probably have proven product market fit and now you know you have a business and and you can continue to generate revenue which will help you fund the development, and you can build the product actually after you've created your revenue engine. That's why it's called launch first. You literally launch the sales and marketing engine before you build the product, forcing you to get out there really quick to ask the hardest questions of your customers, which which is will you buy this now? And most of us founders are afraid to do that, especially when we don't even have anything yet. I see founders come out with their MVPs after nine or 10 months and they're still not charging. And they go through three or four beta releases and extend it two years, two and a half years, or they build way too big a product. I've even had some founders that never went to market, one that went almost three years and never put it out to test the market and went bankrupt. It's not it's the rare case that does that right. But this failure to pull the trigger syndrome is because you're afraid that it's not perfect and it's gonna give you the wrong impression. You don't want it to get out early and these are all backwards. Get it out as quick as you can. Being perfect is not important. What's important is that you find out who the customer is and are they willing to pay enough for it and can you sell it at a high enough closing rate that you can get to that three to one ratio and if you do it right, you can do that before you ever build the product. I know it sounds backwards, but there are lots of examples. I'll give you a very famous example of this. It's not software and regardless of what you think of the guy, elon Musk, when he first came out with Tesla, he had a prototype sports car. It didn't run, it wasn't real. But he sold thousands of them to prove that there was a market for something cool that was electric and a sports car, and he generated a lot of money from that prototype. So that's an example of doing pre-launch sale.
Speaker 2:You have to have something to show people. They're not going to buy just because you have a pretty face. But it doesn't have to be a product that works. It can be a design prototype as long as it's realistic enough. And you're not going to sell if you haven't really correctly identified the early adopter.
Speaker 2:Because you have to find that person who is willing to spend money early on a product because it's a big enough problem. It impacts them big enough personally. They know they have to get this when it comes out to mitigate this problem. So they'll be given a big enough value opportunity up front. They'll buy now in enough numbers. You can prove you got product market fit.
Speaker 2:And now and then raising money if you decide you're going to raise money later is a whole different animal because you're showing traction, you're showing revenue for a product you haven't even built yet and investors are going to really care about that. The idea of launching first just makes so much sense from so many perspectives. And if you can't find the path even after many pivots which can be done very quickly then you can say, okay, I failed fast and cheap. It's only been five or six months, I can move on with my life. I haven't spent that much money yet. And I've got another great idea I want to pursue, instead of three or four years later, you know, a failed marriage, bankrupt, 401k is gone. Yeah, just saying I like one better than the other.
Speaker 1:I have to agree with you, david, there you know, that's something core to what we've done is really just experiment as quickly as we can, get as much information as we can on the problem. We find ourselves asking other people about the problems that they're having, asking people about the real situations that they're dealing with at their current places of work or in their recent experience, and so this is right in line with the philosophies that we hold at Sigma Lab Consulting. David, thank you so much for talking to us about LaunchVerse. Tell us how can folks learn more about techies and the LaunchVerse? Tell us how can folks learn more about Techies and the LaunchVerse program.
Speaker 2:Anybody that made it to the end of the show. I'll give you my email. It won't be in the show notes but it's david at techiescom. Techies is spelled T-E-K-Y-Z, so you can reach me david at T-E-K-Y-Zcom. You can find me on LinkedIn or just go to the contact us form at techies dot com on my website and reach out to me that way.
Speaker 1:Awesome. David Lawrence, thanks for having you guys on the show and we'll catch you next time.
Speaker 2:Great and thank you guys. Really fun conversation.
Speaker 3:Yeah, great conversation.
