Error Title

This is a notice message, displayed at the top of the browser, informing the user of something useful.

Continue with LinkedIn
Recover my Password
Submit your Tekpon Account E-mail address and you will receive an email with instructions to reset your password.

Why the majority of software products fail

Why the majority of software products fail | Jeff Zigman - the business engineer

Who is Jeff Zigman?

Jeff: I have an engineering background; I’ve been in the tech startup space for about ten years. I’ve been a CTO for eight years. I started doing software testing about 15 years ago and became a business analyst. So that was my first, I guess, real professional job ten years ago. And since then, I’ve done in detail all parts of the software cycle in a lot of depth. There are times when I was doing eight, six to eight technical roles that are normally full-time positions, all simultaneously while running a company of CTOs I’ve gone to.

The more you know, the more you do adjacent skills simultaneously. And the more your brain starts to think in multiple dimensions simultaneously. And you start thinking much quicker in different ways. So I’ve designed and built a few hundred software systems, modules, and a few dozen businesses.

Projects have then led to multimillion-dollar enterprise software from the ground. Something depending either on my own or leading a team. And I’ve been able to lead a team for under half a million dollars in four years, while competitors on the market took ten years with 15 developers and over 20 million to build. So, I’ve accumulated a good amount of experience relatively quickly.

What is the software cycle?

Jeff: The software cycle is often misunderstood by non-tech people. And even tech people don’t fully see the full picture until years. Even some people who’ve been working for ten years don’t fully get it. Because they don’t see all the parts of it in depth. So most non-tech people who think about software think, okay, you have an idea. You explain it to a developer, and then they build it, and everything turns out magically.

The software requires about ten different technical disciplines to right. Coding is roughly the seventh one if you think about it sequentially. And it’s the least important of all 10 of them, which is why most software projects fail. So if you are trying to embark on something and think that the seventh thing in the process, which is the least important thing, is the only thing in the process, you’ll neglect everything else. And the chance of you getting it right is extremely, extremely low.

What is the solution?

Jeff: Things are difficult when you’re unclear on how to solve them, right? As soon as anything is clear to you, it’s not hard to solve. The thing about software is that there are so many different pieces to it that if you’re unclear on any parts, that creates ambiguity. It creates a lack of clarity, right?

So the first step is gathering business requirements. I write a lot about that because it’s the first step in the process. It’s the most important step of the entire process. It’s the part often done wrong, skipped, or incomplete. And every single other thing that happens throughout the rest of the process completely depends on what you do there. So if that part’s done wrong, it ripples throughout the entire, all the other steps, and it goes, it goes wrong.

If you need that, you have to assemble specifications, use cases, mockups, etc. Then you need to translate that into technical specifications. And there’s this translation gap, a communication gap there between the business side and the technical side. I would say that about 30% of the message there is lost, on average. The specific gathering requirements are extremely rare and rarely happen. Then if you get it to that point, unless you have someone who can translate it over that gap, I call it the broken telephone of software development.

From the business to the tech side, you, on average, lose about 30% of the message. And then, it goes over to the database. Start the design, and it goes over to programming logic design, and then you have front-end development, back-end development, project management, and testing. So you could divide it a bit more like you, UX optimization, UI design, etc. You have ten different desk disciplines involved in doing this. So the more you know and clearly understand. So if you can see if you worked in and done a lot of projects and did all ten dimensions repeatedly, you can see how all of them will play out and mix. And how, one little thing at the beginning. Propagate throughout all the other ones.

My LinkedIn tagline says I can solve any business tech challenge for $10 to $20,000 monthly. It’s because when I hear what the thing is at the beginning because I’ve done it so many times like that, and I’ve done all parts of it, I can see what it looks like in my head throughout that entire thing.

And then, by making some quick notes, I can see which parts are a little unclear to me or potentially unclear. And then I might have to do some research. Or I could see if everything seems pretty straightforward here. So I can tell, okay, I know that I’m going to be able to solve this, and here’s what I would charge, and here is roughly what it would cost if you were trying to develop it. People have spent $350,000 to get something that’s still not market. I’ve seen $150,000 in a year and a half. I’ve seen millions of dollars. Also, I’ve heard stories of people spending half a million dollars multiple times trying to get something done, and it’s still not working. So, there are countless stories like that.

But, you can do the software product development perfectly, but if the thing you then. It doesn’t solve a problem for people with the target market, so who cares how well you can build a thing? So, you’re not solving something people care about, and I also made that mistake. So, it’s part of the consequence of being able to build things so quickly is that it takes time to research to find something.

But it’s like, oh, but I can build that whole thing that would normally take six months, and I could build it in a week. So, I’m going to try to, I’m going to build it, and then I’m going to have a solution I could present to people. But if you do that, it’s not the smart way of doing it because you might be building something nobody cares about, which doesn’t help you.

People skip or don’t know how to do the business requirement gathering phase. So if I were to tell you what you want, what do you think about the idea of building a house without a blueprint?

What is your current company?

Jeff: I am currently working as a fractional CTO and business analyst. So with either company that needs help with fractional CTO stuff or established companies who need help with automation, scaling business process automation stuff, process improvement, process automation, and stuff like that.

Also, I have my own company, Skill Builder, which is essentially like virtual remote employee training. So I’ve been doing martial arts for about 20 years also. And I took the principles I learned from martial arts about how people learn new skills and absorb new skills, and, um, basically took those principles and built the software platform around.

Those learning principles are needed to build new skills effectively, and most people don’t know how to build new skills quickly. So take any online learning with the best instructor. If the person learning it has not learned how to learn or pick up new skills, they will see it. They’re going to watch it, and then they’re going to take away a very small percentage of it, and they’re not going to be able to execute effectively on it. So this takes those principles.

Why should people follow you on social media?

Jeff: The way I define that is where somebody knows something is repeated repeatedly to produce successful, positive results. They’ve reached the point where they can do it and repeatedly produce successful results quickly. So that’s how I define when somebody knows their thing.

There are a lot of experts out there in different areas that have not necessarily done things effectively themselves or achieved results. The things that I talk about a lot are the importance of requirements gathering in software. Different parts of how to design and build software properly to avoid months or years of pain happen to see all the time.

All the time, I talk about the process and how to improve. Process improvements. How to accomplish more every single day just by analyzing the inefficient things you’re doing? How to leverage? I don’t talk as much about this. Still, I incorporate automation into your business processes for basic things a human shouldn’t spend time doing.

If you’re interested in startups, if you’re interested in software, and if you’re interested in trying to do software and avoiding a lot of the pitfalls that people commonly experience and suffer through, spend long periods going through and dumping a lot of money into. Then those are the kind of things that I, that you probably get some good insights around. And I also have a YouTube channel; I post some stuff here and there. Uh, on that. On it, Yeah.

What is your story, Jeff?

Jeff: I wouldn’t even classify myself as a developer; my expertise, the thing that I can do without thinking about it, is business analysis. I’ve done it so much. And it’s like, oh, what about this case, or what about this condition, and that leads to these five branches of things that can happen. And if this happens, it will lead to these four things that will happen and which will lead to this. So that’s going to happen. So what about this case and those 17 cases that pop up and that scenario under the, like all that stuff just kind of pops into my, my mind cause I’ve done it so much.

I got a job as a business analyst. It’s not a role in the startup world; I did it in more of a corporate setting. Once I realized how you start the design process for software, the same time as doing that job, I started a startup company and failed miserably. I made a whole bunch of mistakes, like everyone. But I started doing that. And then, over the years, I started noticing how business analysts do things in the industry.

Do you have any advice for people who want to follow your journey?

Jeff: They don’t need to follow the path I went through to be very successful. The reason why I’m suggesting not to follow the path that I took – there was a point when I was CTO of a company where I was making very little money as a part owner, part one of the owners. I made very little money for four years and was simultaneously CTO, business analyst, and Head of Quality Assurance. This is for multimillion-dollar enterprise software. And the only tester of it, designing the database and doing the back-end, programming logic for it, and project management.

I was taking on six to eight technical roles, working 80 hours a week, and it was a great learning experience, but I would not recommend people do that because it’s extremely hard to do. And even that, I could only do it because of the background I had before that. So it depends on what people are looking for.

If people want to be business analysts, find a job as a business analyst or a junior business analyst, and try to do it. Offer to work for free initially, get it, and get your foot in the door. That’s something that people often overlook. They think it’s crazy. People will pay $150,000 for an education that won’t get them a job, and then they’re not willing to work for free for a month to show what they can do and then actually get the jobs. It’s a crazy mindset that people have.

What’s your favorite software?

Jeff: I use Trello for project management, managing tasks, and keeping things in order. And I use Xmind as a mind map of everything I’m doing, and I use Xmind as a mind mapping for planning everything I use. My two key things, and for any visuals I need to do, I’ve been using Omni Raffle. It’s a Mac thing. I know people use Figma a lot. But I would probably need to put a little bit of time into learning Figma since it seems to be a good tool, but I haven’t used it much myself.

A piece of advice for founders

Jeff: People who have a lot of pe a lot of founders, once you get money, they tend to blow money and like them because it’s there and, like, if you have money, use it wisely. Especially now, I heard that VCs are not funding things too easily now, and some money is in a much shorter supply. So people tend to hire more developers. A developer, as mentioned, is one of many skill sets.

And if you’re hiring more developers to try to solve problems, that’s not your problem, then that will be a problem. You’re probably missing the business analysis, and you’re probably missing the requirements gathering since almost nobody does that properly. And that’s the kind of thing where you could spend six months doing something that should have taken you three or two months. Imagine you’re spending $200,000 a month because you’re funded, and you’re doing that for six months instead of three months. You just wasted $600,000 for nothing.

Hire somebody fractionally who has the expertise to do that. You might spend a thousand dollars or 2000, but you’re going to prevent yourself from wasting hundreds of thousands of dollars by doing that, doing the wrong thing, and then wasting all your investor. Just because you raised $10 million, you can still go broke. Companies are doing that if you don’t use your money wisely.

Every single salesperson in tech has a problem dealing with development and providing proper value to customers. They promise features that they shouldn’t be doing, and then they get cut down by the tech team all the time. They get frustrated, it creates friction, and they don’t know how to manage those relationships. If you don’t know how to manage those relationships and be that intermediary, You’re going home frustrated every day. You’ll feel like your tech team won’t want you to talk to the customer.

I had a partner like that who did that. I told him, you’re never allowed to talk to another customer about features ever again. You’re killing us. Like I told him, never talk with anyone ever again. And that’s horrible because that was someone with more than 20 years of sales experience who had run a sales floor of 92 people. And he was still making those mistakes.

Connect with Jeff