In this episode of The CEO Project Podcast, host Jim Schleckser talks with software veteran David Hirschfeld about his “launch-first” approach to building software that reduces risk and accelerates success. Aimed at CEOs frustrated by costly, delayed projects, the conversation highlights how realistic prototypes, customer-driven validation, and pre-launch sales can create early traction and smarter development. From agile practices to hiring the right dev team, this episode is packed with actionable insights for leaders navigating the software development journey.
Key Takeaways:
- Traditional software development often fails due to lack of product-market fit and delayed revenue.
- The “launch-first” approach emphasizes solving real customer problems before building solutions.
- High-fidelity prototypes can be used to secure pre-launch sales and validate demand early.
- Kanban is preferred over Scrum for flexible, iterative development with faster feedback loops.
- CEOs should evaluate outsourced dev teams based on detailed estimation, clear artifacts, and progress tracking.
- Success comes from aligning product development with real-world needs and customer validation — not just vision.
Transcript
[0:00–0:15] Jim Schlexer: Welcome to the CEO Project Podcast, where Jim Schlexer, author of the best-selling book, Great CEOs Are Lazy, and the founder of the CEO Project, provides ideas and tools to help CEOs of mid- to large-sized companies grow and optimize their businesses.
[0:15–0:29] Jim Schlexer: Now, let’s get started with the show. Welcome, everybody, to the CEO Project Podcast. My name is Jim Schlexer. I am your host and the founder of the CEO Project.
[0:29–0:41] Jim Schlexer: Well, software is something that is confusing to a lot of CEOs. You know, they don’t know how to develop it. It’s mysterious. They pay a lot of money for these crazy people that eat popsicles and develop code, and they don’t know how to do it.
[0:41–0:53] Jim Schlexer: And then the worst problem is, you know, when we design our software, we try to design what I used to call the God Box, you know, the all-knowing, all-seeing, all-doing product. It’s only going to take a million and a half dollars and two years to develop.
[0:53–1:10] Jim Schlexer: And, you know, in the meanwhile, we would really love to have some revenue. Well, our guest today has a completely different look at it, and some of you will be familiar with some of the approaches, but David Hirschfield is a 35-year software development veteran with a unique perspective on innovation and business growth.
[1:10–1:32] Jim Schlexer: His career spans leadership roles at Computer Associates, Tech Systems, Intel, Motorola, launched his first startup, and sold that successfully in 2000. He founded TechEase in 2007, and he has become an advisor for AI-driven workflow transformation for startups in the design and development of their software and their startups.
[1:33–1:47] Jim Schlexer: He’s collaborated with over 70 of them. He’s developed a launch-first method. I think that’s going to have some familiarity to some other methodologies that are out there. A systematic approach that minimizes risk and accelerates success with reduced reliance on investor funding.
[1:48–2:00] Jim Schlexer: He bridges cutting-edge AI technologies, workflow optimization, startup ecosystem dynamics. When he’s not having fun doing that, he woodworks, golfs, and raises four boys.
[2:00–2:04] Jim Schlexer: You know, like me, God knew you couldn’t handle girls, so he gave you all boys. Is that what happened?
[2:05–2:10] David Hirschfield: Yeah, exactly. Raised four boys. Yeah, they all have their own families now.
[2:10–2:17] Jim Schlexer: Yeah, nice. Yeah, mine are off on their own, too. And I have two boys, and I joke, God knew I wouldn’t have been able to handle a girl.
[2:17–2:24] David Hirschfield: But now I have four granddaughters. Oh, my God. They got me back.
[2:24–2:35] Jim Schlexer: Oh, my God, yeah. Grandpa, can I have this? Yeah, awesome. Well, how did you get into software development? And maybe more importantly, how did you develop this sort of methodology that you’re talking about?
[2:36–2:52] David Hirschfield: Okay, well, let me start with the software development. Yeah. I was a physics major at UCLA, and I was always interested in technology. and then I went to work for software companies where I was in the sales department of, like, computer associates and Texas Instruments.
[2:52–3:12] David Hirschfield: And because I’m really technical and because I always had to schedule a week ahead of time to get systems engineers to come and support me in these sales calls to do demos of product, and I ended up learning how to do the demos myself and even got Texas Instruments to send me to their school to learn how to use their case engineering software.
[3:12–3:17] David Hirschfield: Oh, cool. Which was an act of God because they never, ever had sent a salesperson to that.
[3:18–3:21] Jim Schlexer: Because sales guys weren’t smart enough to figure it out, right?
[3:21–3:44] David Hirschfield: Texas Vince is a pure engineering company. Yeah, I have friends who were there. Yeah, the necessary evil, you were in sales. Yeah. So as a result, I ended up, when I left Texas Vince, I ended up being a consultant for their case engineering software, and I did projects, mostly project managed at Intel, Motorola, Allied Signal, Arizona Service.
[3:45–3:57] David Hirschfield: And then I started my own software company. And that one was kind of started on a lark with a friend of mine who was at Texas Instruments. And we did it kind of like a mini ERP system back then when Windows 3.
[3:57–4:09] David Hirschfield: One had just come out. It was the first version of Windows that people could actually use. And there was nothing on the market that was Windows enabled. So we built logistics inventory management, route distribution product for a particular niche.
[4:09–4:14] David Hirschfield: And despite every effort on both our parts, we ended up growing it anyway.
[4:14–4:17] Jim Schlexer: Yes, despite our level of competency, right? Exactly.
[4:18–4:31] David Hirschfield: We grew it to 800 customers in 22 countries and sold it in 2000 to a publicly traded firm. I was VP of products for the acquiring company for a few years and then went out again and tried to create another software company.
[4:31–4:42] David Hirschfield: And this one I failed because I didn’t follow the same playbook that made me successful the first time. And I wasn’t sure what that actual playbook was until I started Tekyz.
[4:42–4:53] David Hirschfield: So out of the asses of that failure, 2007, I started Tekyz. And that was 18 years ago. And we’ve been doing software development for small to medium-sized businesses, some large companies, and a lot of startups.
[4:54–5:09] David Hirschfield: And I’ve watched a lot of failures of these startups. And now I understand why I failed the second time and why I was successful the first time. because the pattern started to really emerge on the things that founders who are successful do or existing companies that are launching new products.
[5:09–5:16] David Hirschfield: Because some companies are successful, and then they launch a new product, and it fails, and they’re not sure why. Well, don’t keep us waiting.
[5:16–5:18] Jim Schlexer: What shouldn’t we do, and what should we do?
[5:20–5:31] David Hirschfield: So the classic founder, you know, is struggling with some kind of problem, sees a solution to it, and then falls in love with the solution. Yeah. and forgets about the problem.
[5:31–5:44] David Hirschfield: And this is the classic and spends all their time, and basically they’re wearing a black robe because they believe in themselves, they believe in the solution, and they’re telling everybody how great this is. Obviously, I’m oversimplifying, but this is a trap.
[5:44–5:50] David Hirschfield: Those are code words for I’m going to fail, or this is going to become the next unicorn. You know, all code words for I’m going to fail.
[5:51–5:55] Jim Schlexer: Well, what I’m hearing is no voice of the customer in that conversation. Exactly.
[5:56–6:09] David Hirschfield: And they’ve been not talking about the problem. In fact, you ask founders, most founders, you ask them, what problem are you solving? And they say, they give you a feature of the product. And I say, well, that’s a nice feature, but that’s not a problem statement.
[6:09–6:13] David Hirschfield: I don’t hear a problem statement. They say, oh, yeah, yeah. Then they tell you why it’s such a good feature.
[6:15–6:18] Jim Schlexer: I’m going to double down, right?
[6:19–6:34] David Hirschfield: Yeah. So I spend a lot of time kind of peeling that black robe off founders and try to wrap them in a white coat, turn them into clinicians, and make them understand that everything they believe are just assumptions because they don’t have any proof.
[6:35–6:48] David Hirschfield: And then so founders who are really consistently successful love the problem and spend their time talking with customers about their problems and about what have they done to mitigate that problem in the past.
[6:48–7:10] David Hirschfield: Why don’t they keep doing that? Have they tried other products? Have they found products that worked? Why aren’t they still using them? That’s the conversation that successful founders have with lots and lots of customers, and they continually have them, even after they launch their product, not talking about their product, just talking about the problem, understanding how much that problem is really costing them, how much does it personally impact them.
[7:10–7:22] David Hirschfield: Those are two independent measures, things like that. So when I realized this, I created this methodology come launch first. The other thing that we do is we create these realistic prototypes.
[7:22–7:32] David Hirschfield: They call them design prototypes or high-fidelity prototypes. When you demo it to somebody, they think you finished the product, and there’s no software behind it, but it looks like it’s a real product.
[7:33–7:46] David Hirschfield: And then we go out and demo these to potential prospects and see if we can’t get early sales. We offer them some high-value option to buy in early, and if they won’t buy in early, why not?
[7:47–7:58] David Hirschfield: Is there a problem with the business model? Do we have the wrong product, the wrong market? Are we the wrong early adopter? What is it we’re not doing right that we’re not getting any pre-launch sales?
[7:59–8:13] David Hirschfield: And the reason that’s so important is most people that fail end up failing because they lack product market fit. You know, they build the wrong product for the wrong person, and they spend way too much money and time building the wrong product for the wrong person.
[8:13–8:44] David Hirschfield: And then pivoting is costly and time-consuming once you’ve built your product. But pivoting a design prototype is quick and easy and inexpensive, as well as building the design prototype as opposed to building the product So the idea being that you want to confirm product market fit in the only way that you can absolutely confirm it and that’s you get sales from customers in enough numbers that you’ve got a three-to-one ratio between the lifetime value of your customer versus the cost to acquire that customer.
[8:44–8:54] David Hirschfield: Three-to-one is your ratio? Yeah, that’s sort of a kind of a SaaS golden ratio. A lot has to do with what period of time you’re calculating that lifetime value over.
[8:55–9:06] Jim Schlexer: I mean, the problem is when you’re starting up, I really don’t know the lifetime value because I don’t know my retention. So you’re kind of guessing at it. I always say 60% of your first year margin is also a pretty useful number to fool around with.
[9:06–9:10] David Hirschfield: That’s a good number, too. I will add that to my…
[9:10–9:20] Jim Schlexer: Feel free. By the way, it works in almost any industry. Even a low margin industry, 60% of your first year margin, as long as there’s recurrence in it, can get you home.
[9:21–9:25] David Hirschfield: I like that. Okay. Interesting. Okay. I’ll do some calculations around that.
[9:25–9:29] Jim Schlexer: Yeah, please feel free. I did some of my own, but check me. That’d be great.
[9:29–9:36] David Hirschfield: I’d just like to see how those numbers work out the same way so that when I talk about 60%, I can explain why that matters. Yeah, yeah.
[9:36–9:49] Jim Schlexer: Well, it goes to not needing additional capital, right? That’s where. Exactly. How do I do it without needing more capital is the question. I love what you’ve done is people talk about fail fast and fail cheap. You really put a face on fail fast and fail cheap here.
[9:50–10:00] David Hirschfield: Yeah. In fact, that’s part of my mantra is fail fast and fail cheap, right? The idea is, you know, fail fast and fail cheap, and maybe you’ve pivoted two or three times, you’re still failing.
[10:00–10:14] David Hirschfield: So you truly fail fast and cheap, right? Be happy that you’re out of it very quickly for very little money as compared to what a lot of founders go through, which is many years and hundreds of thousands or millions of dollars spent before they fail.
[10:14–10:25] David Hirschfield: And not all that uncommon like marriages and life, you know, so many things about life gets all messed up because of this terrible long-term failure in a big portion of your life.
[10:26–10:28] David Hirschfield: So, yeah, it doesn’t make sense.
[10:28–10:42] Jim Schlexer: It’s funny you talk about entrepreneurs and startups, but I think the same idea is appropriate for software and product development in larger companies, And even more so there because you’re running a $100, $200 million company.
[10:42–10:56] Jim Schlexer: It’s not unusual to see a $1 million, $2 million product development effort. And we’ll know after we spend all this money if we got something or not. Boy, oh, boy, I would really rather spend $50,000 and know if I’ve got something and then spend another $50,000 and another.
[10:56–11:00] Jim Schlexer: And by the time I spend $200,000, I’m sure I’ve got something and now I’ll spend $1 million.
[11:01–11:12] David Hirschfield: Exactly. And that doesn’t mean a company can’t fail even if they do have product market fit. But that’s a small — then it’s a matter of just not knowing how to operate a company in the proper way, right?
[11:12–11:23] David Hirschfield: So I think most of the companies that fail, you know, they say 42% fail because of lack of product market fit. And like 40% fail because they run out of money.
[11:23–11:33] David Hirschfield: I think that running out of money is they run out because they don’t have enough profit. They didn’t really have product market fit the way they measured it. So in my mind, about 80% of failures are –
[11:33–11:47] Jim Schlexer: Well, I think it’s 100. I had a friend who started a business not that long ago, and he goes, Jim, what do I need to know? I’m starting a business. What do I need to know? So there’s three things. Number one, you can’t run out of money because if you run out of money, the music stops, and you don’t get to solve any more problems.
[11:47–11:58] Jim Schlexer: As long as you have money, you can solve all the problems. It’s just a matter of time. Got it. Don’t run out of money. What’s number two? Number two is don’t run out of money, and number three is don’t run out of money. It’s the only one that matters.
[11:59–12:10] Jim Schlexer: Everything else is optional. So, yeah, I’m going to run out of money. So how do you get this sort of looks like it’s real but it isn’t real demo together? Like that seems a skill set that most people don’t think about.
[12:11–12:20] Jim Schlexer: They’re like, I’m wasting time building this thing that looks like it’s real and then I’m going to have to go to build a real thing. It feels like engineers will freak a little bit at this idea.
[12:20–12:42] David Hirschfield: So we used to use Aksure, which is a prototyping tool, where you could build in a lot of logic in terms of the workflows and user experience and all that. We’re using Figma a lot more in the last few years because Figma’s evolved enough where you can do the simulations, on-screen simulations of how the application behaves when you select certain things and when you’re typing.
[12:42–12:58] David Hirschfield: And that’s important. It’s got to look real. And the reason it has to look real, not just represent a real app but actually look like a real app, is because if they ask you the question, how do I know you can build this, you can’t get them to buy in early.
[12:58–13:28] David Hirschfield: but if it looks like you’ve already built it even though you tell them this is not the actual application first version won’t be out for a few months and it won’t have all these features but you’re getting to see what you’re buying into from a vision perspective they make up a story in their head about they hear that but they don’t actually hear it in the way you say it they think oh you must be in QA or you’ve already developed it but there’s some additional features you’re adding to it they just don’t hear it and so that question never happens and that’s a critical success factor in doing pre-lawn sales.
[13:28–13:34] Jim Schlexer: So that’s actually with live data then or a static database sitting behind it, no feeds?
[13:35–13:38] David Hirschfield: No, not even a database. No, it’s just built into the logic.
[13:38–13:43] Jim Schlexer: Oh, wow, this is really like one-inch deep kind of stuff. This is one-inch deep.
[13:44–14:07] David Hirschfield: Okay. We don’t want to have to spend any time in building any kind of logic scaffolding behind it, right? Yeah. Because that raises your cost and it doesn’t provide any additional value. So we just figure out what those user experience scenarios are that you need to be able to walk through and demo, and do you need to be able to back out, you know, click back button and show that functionality, and then we’ll build it all in, and it looks real, right?
[14:07–14:21] David Hirschfield: Even edit maintenance screens, and all the menus are functional, and the error messages pop up and things like that. But it has to look real. And there’s a lot more to building that kind of a design than just doing a normal UI design.
[14:21–14:34] David Hirschfield: But the reason we started doing that 12 years ago is because when we were just doing mock-ups and wireframes, we found that the founders or the client would commit to what we were doing.
[14:34–14:44] David Hirschfield: And then when we gave them the software to start to use, they’d realize that’s not going to work and it’s not going to really support the user experience they need. And so we’d go back and we’d have lots of changes in iteration.
[14:44–14:55] David Hirschfield: So I said, why don’t we just model all this up front and do all that iteration in the design? And then once we’re done, we’ve got a design that represents the actual application’s user experience in living color.
[14:55–15:09] David Hirschfield: Got it. And then when we did that, and the developer knows exactly how it’s supposed to behave when they deliver it, not just both in terms of animation and user screen behavior and things like that, so they’re not delivering something that the founder was expecting something different.
[15:10–15:22] David Hirschfield: And all that iteration went down once we started doing that. And then, of course, in these realistic prototypes, we thought, why don’t we do pre-launch sales? Yeah. It seems like a smart thing to try to do to validate that it’s worth building.
[15:23–15:39] Jim Schlexer: Got it. So this is a real hardcore UI UX before we do all the back-end stuff, basically. Get all the UI UX right, which is really everything the customer is going to touch anyway. You know, almost we could have magic hamsters in the back as far as they’re concerned, as long as it works, right?
[15:39–15:50] Jim Schlexer: But the UI UX I’m happy with and I’m good to go. So that’s really what you’re doing is your customer will see what they’re going to see and do what they, if they’re happy with that, then we can build the whole backside as a separate conversation.
[15:51–16:02] David Hirschfield: Yeah, the backside and the front side. Well, you haven’t really built it, I realize that, yeah. Yeah, yeah. But, and that’s just, we’ve been doing this now for a long time, you know, doing it this way.
[16:03–16:17] David Hirschfield: And we build the whole vision out. We don’t just build the MVP in this design prototype. We build out the year-and-a-half to two-year roadmap. Yeah. So that you can see that all the pieces hold together properly and that there’s a clear path.
[16:17–16:23] David Hirschfield: And we may end up never building some of those things and building other things because the MVP gets out and you start to get real feedback from the market.
[16:25–16:36] Jim Schlexer: Now, if you do that. By the way, I think that’s really interesting because, you know, when you’re a software salesperson, you’re always selling off the roadmap, right? You’re like, well, here’s the PowerPoint that shows what you’re getting in Q3 next year.
[16:37–16:58] Jim Schlexer: Very different to let me show you what it’s going to be and how it’s going to interface and what it’s going to do in Q3 next year. Right. You’re not saying that, but you said this is the product. This is a 1.0 product. We going to release 0 0 0 and then you get 1 but that be a little ways down the road So the fact that you showing an evolved roadmap is a very different move to anything I heard before
[16:59–17:13] David Hirschfield: Yeah. So we showed the evolved roadmap, but we’ve done our niche analysis. We know who that early adopter is because it’s part of the Launch First methodology. Yep. And we craft the demo to focus on their number one and two problems.
[17:13–17:24] David Hirschfield: Got it. And we demo those things, and then we say, but look what else you’re getting. So they can see the big vision that they’re buying into, but we have nailed their problems that are high cost and high impact.
[17:24–17:28] David Hirschfield: And we craft the demo and the language around that.
[17:28–17:43] Jim Schlexer: And I love the selling into this because we talked to us when we were dealing with startups. We go, look, two things you need to do is one is find your seam where you can solve that. You call it product market fit, but find your seam and be greedy for revenue.
[17:43–17:55] Jim Schlexer: A lot of times you’re like, we’ll give it away for a while. and then I’m like greedy for revenue. You want revenue as early as you humanly can get it. Back to your point about minimizing reliance on investors.
[17:55–18:05] Jim Schlexer: Otherwise, you’re back to the well, back to the we’re getting close. We’re getting really, really close. We’re getting really, really, really, really close. Don’t worry. It’s a horrible conversation. I’ve had it. It’s really painful.
[18:05–18:17] David Hirschfield: I love that. It’s very hard to make that transition to actually asking customers for money when you’ve been giving it away. And the ones that you’ve been giving it away to may not want to buy it, And they may or may not be using it because they’re not invested in it.
[18:18–18:29] David Hirschfield: Whereas if you get people to buy in early, then when the beta comes out, they’re invested in that beta. That’s why they bought in because it solves a really specific problem that they need solved or they wouldn’t have bought in.
[18:29–18:40] Jim Schlexer: I used to call this like a cockroach problem. I’m giving away for free the minute I charge money. It’s like turning the lights on in the kitchen and the cockroaches scatter, you know. Exactly. Your point.
[18:40–18:43] David Hirschfield: I love that. That’s a great metaphor. It’s a perfect metaphor.
[18:43–18:45] Jim Schlexer: It’s a little disgusting, but, you know, you get the point, right?
[18:46–19:01] David Hirschfield: Right. Well, it also changes if you do the pre-launch sales. It changes the concept of your MVP from this idea that it’s going to help you establish product market fit, which is not what an MVP should be for, to focusing on product solution fit.
[19:01–19:26] David Hirschfield: Because now you’ve got a product and you need to make sure it’s delivering the value to the client in the way they were expecting it and that what they thought they needed is what they actually need, right? And if it’s not, then now you’ve got time to make those adjustments so that you’re getting engagement in the application the way you believe you need to have that engagement, right, so that you can continue to sell more and then get the kind of feedback and referrals as a result of people using it and getting value out of it.
[19:27–19:32] David Hirschfield: So product market fits about sales. Product solution fits about usage. Yes.
[19:32–19:43] Jim Schlexer: And stability and security and all the other things you’ve got to worry about. When you get into the full-blown development, I think I got my UI, UX, my one-inch deep demo. Everybody says, yeah, that looks awesome.
[19:43–19:54] Jim Schlexer: If we could do that, we’d be super happy. We’ve given you a little bit of money to support it. Now we’re into the hardcore development. How do you approach software development? Do you use Agile?
[19:54–20:00] Jim Schlexer: What methodology do you use? Or have you found is high performance for your organization?
[20:01–20:12] David Hirschfield: Since so many of the products that we’re building are new products, we use Kanban. So pure Scrum is just too restrictive in a new product development environment.
[20:13–20:16] Jim Schlexer: And by the way, could you just describe Kanban for those that have not been familiar with that briefly?
[20:17–20:28] David Hirschfield: It’s all agile development. These are just sort of different nature type of agile. Where Scrum, Scrum development is where you have very fixed time boxes.
[20:28–20:45] David Hirschfield: And the team is a mature team that’s been working together on this product for a long time. And so they are, every two weeks when the time box starts, they’re pulling out from the priority list all of the various items that are, you know, to-do items in the application.
[20:45–21:06] David Hirschfield: and they independently in the scrum team pick who’s going to do which piece, how much effort it’s going to take, until they’ve got about 85% of their planned time filled, which leaves a little bit of extra time for them for things that they didn’t expect to happen so they can complete these items in that two-week period.
[21:06–21:17] David Hirschfield: And when the two weeks is up, they’re done. If they didn’t finish it, then they didn’t finish it, right? And they stop and they deliver what they can in that two weeks and start the next Scrum the following Monday.
[21:18–21:29] David Hirschfield: That’s okay in existing company structures and existing software that’s being maintained and enhanced, and the team’s been really well. It doesn’t work for new development because it’s too restrictive.
[21:29–21:36] David Hirschfield: So Kanban is similar in how we pull things off and how we manage the states of each item.
[21:36–21:41] Jim Schlexer: So basically cards with stories, and I’m going to fulfill that particular element of my story, right?
[21:42–21:54] David Hirschfield: Right, exactly, right. But it’s not so restrictive from a time boxing period. That’s the big difference in terms of how we use Kanban versus how we would. And we used to do Scrum and found that it just didn’t work for new development.
[21:54–21:55] David Hirschfield: Got it.
[21:55–22:07] Jim Schlexer: And what I always liked about it is it’s highly visual. I’m not the software person, but I can walk in and kind of see where things were, see how they moved from two weeks ago, three weeks ago, a month ago, see if we’re progressing towards conclusion.
[22:07–22:11] Jim Schlexer: So I love the visual element of the Kanban system personally.
[22:11–22:24] David Hirschfield: Right. And we’re building new stuff. We’re also building, enhancing things and doing bug fixes in production releases. Sure. With Kanban, we may have two or three releases a week, depending on where we are with a project, right?
[22:24–22:31] David Hirschfield: We may not release anything for a couple weeks, right? And so there’s that flexibility in a Kanban mode.
[22:31–22:46] Jim Schlexer: By the way, just for those that are kind of learning on the software side, that’s a monstrous difference from the traditional old school development of software where we get 1.0 is going out June 30, 1.1 is going out October 30, right?
[22:46–23:04] Jim Schlexer: I mean, like three or four releases, monster drops every year. You know what Dave is talking about is you could have a couple of releases a week, potentially, in some scenarios, which is much more approximating the curve of need and use, so forth, as opposed to these big blocks that drop, and are probably wrong.
[23:04–23:06] Jim Schlexer: Then you find out they’re wrong, and now you’ve got to go fix them.
[23:06–23:24] David Hirschfield: Right. Yeah, we want lots of releases, the small pieces of functionality that are not disruptive. Obviously, if it’s more of a new functionality that’s a major capability that would be disruptive to how the application works, and that’s going to come out in a big release.
[23:25–23:43] David Hirschfield: And there’s going to be scaffolding around it in terms of data transformation and maybe workflow transformation and some education with clients and all that. These other things are small features, bug fixes, just constantly releasing functionality as soon as we validate that it’s working.
[23:44–23:57] David Hirschfield: And we have our automated pipelines for automated testing and automated deployment so that it’s easy to do this, right? And it happens with the right security and the right version management and all of that’s just built into the process.
[23:58–24:15] David Hirschfield: I talk a lot about competence. of what’s a highly competent team versus a typical team. That’s something I talk a lot about because if you go to my website, Tekyz.com, it’s right at the top, hyper-exceptional software development team.
[24:16–24:31] Jim Schlexer: I actually want to go there. Let’s say you’re a CEO and I’m going to outsource some all portion of my software development. how do I hire and how do I know I’m actually getting a decent firm?
[24:31–24:42] Jim Schlexer: Because I’ve got a lot of people we’ve worked with the CEO project that they’ve hired what ostensibly were very high-quality teams, and they turned out, you know, not so much. So they obviously didn’t ask whatever the right questions are.
[24:42–24:51] Jim Schlexer: So help us with how do we hire, how do we suss good, average, great, you know, from the rest. Okay, yeah.
[24:51–25:01] David Hirschfield: And it’s tricky if you don’t know, really tricky if you don’t know what to look for. And so I always lead when I’m talking with somebody for the first time.
[25:01–25:13] David Hirschfield: I said, here’s evidence that you would get from a team that works in an exceptional manner that you won’t see. And you should ask other teams, any other team you talk to, to see how they work in this way.
[25:13–25:30] David Hirschfield: And you have a lot of trouble finding that they will have the artifacts that exceptional teams produce as a natural output of what they do And like yeah like what what Let say that would be like the level of detail that they produce any time they estimate That’s a starting point.
[25:30–25:42] David Hirschfield: So when you get an estimate, whether it’s for the initial project or some enhancement that they’re doing, what level of detail goes into that estimate? How accurate can they claim they are with those estimates?
[25:42–26:06] David Hirschfield: Do they have any history they can show you about how accurate they are with estimates with other clients? And most teams won’t have any of this. And I know that because I talk with a lot of other CEOs of software development teams, and we, you know, shoot the information around, and we talk about estimates, and they say, yeah, we do a pretty good job with estimates.
[26:06–26:15] David Hirschfield: And I say, yeah, I think we do too, and I say, would you like to see what we’re doing? And they say, sure, and I show them our estimates, and they go, oh, no, we don’t do estimates like that.
[26:15–26:26] Jim Schlexer: Yeah, I mean, overrun feels like the middle name of most software companies. You know, they just overrun. Or they scope change it on you. Yeah, I can still hit the number, but I’ve got to change the scope.
[26:26–26:27] Jim Schlexer: Oh, my God.
[26:27–26:39] David Hirschfield: And that can be valid. I don’t want to run people down for that reason because clients change scope. But a lot of that has to do because you didn’t spend enough time in the design prototype to sniff out all the scope and all the issues.
[26:39–26:50] David Hirschfield: A lot of times clients, so I assume that was there, but that would have been obvious if you had really sussed out the prototype, right? So we spent a lot of time in the prototyping. Again, this is why, right?
[26:50–27:04] David Hirschfield: Because we learned that when we do it, then all this iteration goes down and scope management becomes a lot easier, right? And then we do these very detailed estimates that break everything down to modules.
[27:04–27:17] David Hirschfield: We use T-shirt sizing. So basically every module has to fit within a certain size T-shirt from extra small to XXL. XXL is nine days of development effort.
[27:17–27:32] David Hirschfield: That’s a really big module. Very few things are X. Anything bigger than that, then we know it’s got to be broken down more. Extra small is a half day of effort. And nothing is shorter than a half day, or it needs to be wrapped up along with something else.
[27:33–27:38] Jim Schlexer: What other questions should we be asking? I heard artifacts to prove estimation quality is key.
[27:38–28:04] David Hirschfield: Do they track actuals? How do they report actuals? Do they show the actuals? Again, so we have a weekly status report, so that’s the next thing I typically show. And our status report shows what we did last week in a lot of detail, what we’re working on right now, what the plan is going forward, our build plan, what builds are coming out when, what is included in those builds, all the team members, what their vacation schedules are, what the plan is, right?
[28:04–28:18] David Hirschfield: All this has to be factored in if you’re going to be inaccurate at all. And in the week, in the current week, we show month to day in terms of actual hours by specialty like DevOps or development or QA.
[28:19–28:30] David Hirschfield: You know, we break it down like that. And then we show what the estimated hours were for the month. And we show what the build schedule was and what the estimated build schedule was and what’s the variance.
[28:30–28:41] David Hirschfield: We’re always showing variances. And our goal is to always be within 10% of what we estimate. And with our largest customer last year, we were 6.5% variance for the whole company.
[28:41–28:42] David Hirschfield: Nice.
[28:43–28:50] Jim Schlexer: All right, so let’s finish up on a success story. Somebody who’s worked with you and had massive success as a result of it. We’ll give you a chance to brag here a little bit.
[28:51–28:54] David Hirschfield: Okay, sure. Well, I can give you a couple. One is…
[28:54–28:59] Jim Schlexer: No, you give me one. You don’t get to give me a couple. It’s a half-hour show, man.
[29:00–29:26] David Hirschfield: All right, all right, all right. Well, I was just going to say because there’s so different ones in entertainment, ones in healthcare. Okay, go ahead. Do two. Okay, it’ll be quick. It’ll be quick. One of my clients from 10 or 11 years ago came to me as a Broadway producer, choreographer, and he wanted to create an iPad app that basically took his whole planning and staging, which usually is like a 2,000-page tome that they produce.
[29:26–29:36] David Hirschfield: with every 30 seconds it shows the actors and all the stage settings on the left side and the score or the script on the right side, right? Wow. Right?
[29:36–29:51] David Hirschfield: So every 30 seconds. And they do this before they start to actually produce the play. This is an exercise they go through so that they know who’s going to be doing what, where do things hold together. And we turned that into an iPad app, which I tried to convince him not to do it because I didn’t think he’d be able to recover.
[29:52–30:23] David Hirschfield: He was going to sell it in the app store for $199, and this was right when the iPad came out and I couldn’t imagine he’s going to sell enough of these to be able to recoup his investment but he said no I’m going to do this you don’t want to do it I’ll find somebody else I said no we’ll do it and that’s when I learned that I didn’t understand all the reasons why people are successful and failure anyway his app has gone on to basically produce every single play on Broadway for the last 7 or 8 years now the Olympic opening games, the Tonys, the Emmys most cruise lines use it for all their
[30:23–30:39] David Hirschfield: stage shows, college games I mean, it’s a wild success. Yeah, he knew his market, right? He knew his market. He knew his market. He had reach. He was solving a problem that he understood really well. I mean, there’s a lot of things I learned from him about what makes somebody really successful versus some of the failures.
[30:39–30:53] David Hirschfield: The other one is a recent client who we actually, I call these recovery projects, which are some of my favorite, and that’s where they were working with another firm and struggling with another firm for some period of time and then found us through referral or whatever.
[30:53–31:25] David Hirschfield: and then they recognize the difference right away between how we work and how this other firm was working. Anyway, so they’re an AI nurse, and they have contracts with, like, the state of Illinois for Medicaid for all their indigent patients who don’t fill prescriptions or don’t take their medications, things like that, or for big hospital systems where somebody’s transitioning from being in there after surgery to long-term care, right, And they need nurses to help with that transition process.
[31:26–31:38] David Hirschfield: So this is a voice-enabled AI nurse that knows the patient’s medical history, knows everything about medicine, right, and can call the patient and intercede and help them through that transition.
[31:38–32:01] David Hirschfield: And there’s a phone number the patient can call to talk to the nurse and schedule things and get information, right. And it’s a very empathetic, natural conversation that they’re having. Or they can call them to remind them about taking their medication, Anyway, the idea is a state that can save 5% to 10% of emergency room visits just by getting their patients to take their medication.
[32:01–32:01] David Hirschfield: Oh, yeah.
[32:01–32:13] Jim Schlexer: No, I mean, we’ve dealt with clients in the healthcare space, and compliance with the protocol is massive. Just imagine a diabetic that wasn’t being compliant to their insulin and their testing.
[32:14–32:18] Jim Schlexer: I mean, they could be in big, big trouble. So, yeah, this is tremendous.
[32:18–32:28] David Hirschfield: And this client just closed a big raise and also did a big deal with Google, who’s like 100% behind them. Wow. Very cool.
[32:28–32:39] Jim Schlexer: Awesome. Well, David, this was fascinating, and I think you and I could talk for three hours about software development. But we don’t have three hours. If people wanted to engage with you or your firm, what’s the best way to get a hold of you?
[32:40–32:51] David Hirschfield: Well, if anybody makes it to the end of this, please email me at david at Tekyz.com. That email won’t be in the show links, but I’ll give it to you right now.
[32:51–33:12] David Hirschfield: Tech use is spelled T-E-K-Y-Z for anybody that’s listening but not watching the video, T-E-K-Y-Z.com. And you can reach me at my website by just going to the Contact Us form, and I’d be happy to talk with you about your project, your possible needs, or if you’re struggling with a firm, I can give you some tips on how you might be able to make it a little bit easier to work with them.
[33:13–33:24] Jim Schlexer: Tremendous. Well, thank you so much. This is an area that a lot of people lose hair, get gray hair, get white hair. And so thank you. Some really good ideas for people on this one. So thank you, David. I appreciate your time.
[33:24–33:35] Jim Schlexer: Thank you, Jim, for having me on. And for everybody that joined us, thanks for joining us on the CEO Project Podcast. We will see you next time. Thanks for listening to the CEO Project Podcast.
[33:35–33:44] Jim Schlexer: We’ll see you next time. Be sure to subscribe to get all the future episodes and check out our website, www.theceoproject.com.
David Hirschfeld founded Tekyz, a company dedicated to transforming business software development. With over 30 years of experience, his journey began with a physics degree from UCLA and a successful sales career at Computer Associates. After launching and selling his first software company in 2000, David found his passion for empowering entrepreneurs.
He developed the Launch 1st™ methodology, which focuses on generating revenue before coding begins. This helps startups gain traction while minimizing risks. With a commitment to innovation and collaboration, David leads Tekyz in providing AI-powered development and SaaS solutions, making a meaningful impact in the tech world.
Tekyz is set to launch two new AI applications: one for automating the Launch 1st Methodology Niche Analysis and Estimiz, an AI-based project estimation tool. Outside of work, David enjoys golfing and woodworking.
You can learn more about David Hirschfeld and Tekyz by following his LinkedIn profile — David Hirschfeld LinkedIn Profile.
For more information about Tekyz’s services and how they can help you harness the power of AI in healthcare, visit tekyz.com or contact the founder directly at [email protected].
Discover the Winning Tactics for Crafting Successful Software Solutions was originally published in Tekyz Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
