The first one hurt the most. Not because the stakes were highest — they weren’t — but because I didn’t yet have the scar tissue that makes the next failure survivable.
I was 24. Fresh out of engineering school. Convinced that building a better product was enough. It wasn’t. The product worked perfectly. The business around it collapsed in eleven months.
Over the next two decades, I failed four more times. Each failure left a different mark. Each one crystallized into a framework I still use today. Here they are, in order, with the lessons stripped of the ego protection I used to wrap around them.
Failure #1: The Product That Nobody Asked For
The year was 2005. I had just finished a degree in engineering and I was certain — the way only someone in their early twenties can be certain — that I understood what the market needed. The product was a specialized tool for a niche manufacturing process. Technically sophisticated. Beautifully engineered. I spent nine months building it.
Nobody bought it.
Not nobody in the exaggerated sense. I mean literally nobody. Zero sales in the first three months after launch. Two pity purchases from people who knew me in month four. Then silence.
The problem wasn’t the product. The problem was that I built it in a vacuum. I talked to engineers. I talked to professors. I talked to other people who found the technical challenge interesting. I did not talk to a single person who would actually pay money to solve the problem I was solving, because I assumed the problem was obvious.
It wasn’t obvious. The people I imagined as customers had already built workarounds. Ugly, inefficient workarounds — but workarounds that were free and familiar. My elegant solution would have required changing their process, retraining their teams, and spending money they hadn’t budgeted. The switching cost was invisible to me and enormous to them.
The framework: Problem-first validation. Before building anything, talk to twenty people who have the problem. Not people who might have it. People who are currently spending money, time, or frustration dealing with it. If you can’t find twenty, the market isn’t there. At Startup Burgenland, I later tracked this across the startups we supported. The ones that started with a validated problem had a dramatically higher rate of reaching market entry. The ones that started with a product idea and worked backward to find a customer rarely made it.
Failure #2: The Partnership That Poisoned Everything
- A consulting engagement that was supposed to be a six-month project turned into a partnership. My collaborator was charismatic, well-connected, and had a client list that made mine look thin. On paper, we were complementary. In practice, we were combustible.
The problem was values alignment — or rather, the complete absence of it. He wanted growth at any cost. I wanted quality at any speed. He saw client relationships as transactions. I saw them as reputations. Every strategic decision became a conflict, and because we’d never defined decision-making authority, every conflict became a power struggle.
We dissolved the partnership after fourteen months. It cost me a year of income, three client relationships, and a significant portion of my confidence.
The framework: The values interview. Before entering any partnership, co-founding arrangement, or close business relationship, spend three hours talking about three things — not business strategy, not growth plans, not market opportunity. Talk about: What does a successful Tuesday look like for you? What would make you walk away from a profitable project? What are the three things you refuse to compromise on? If the answers diverge significantly, no amount of complementary skills will save the relationship. I used this years later when Adam and I started Vulpine, and it’s one of the reasons that partnership succeeded where the earlier one failed.
Failure #3: The Scale That Broke the Machine
- My consulting practice was thriving. I had more clients than I could handle, which sounds like a good problem. It isn’t. It’s the problem that kills more small businesses than any lack of demand ever could.
I hired three people in four months. I didn’t have systems. I didn’t have documented processes. I didn’t have a clear delegation framework. I just had too much work and not enough hours, so I threw bodies at the problem.
Revenue went up 60%. Profit went down 40%. The math was brutal: I was paying three salaries while spending half my time managing three people instead of doing billable work. The quality of our output dropped because my new team was learning while delivering, and clients noticed. Two major accounts left. The revenue spike became a revenue cliff.
I let all three go within six months. It was the worst professional experience of my life up to that point. Not because firing is hard — though it is — but because I knew the failure was entirely mine. They were capable people put into an impossible situation by a founder who confused “busy” with “ready to scale.”
The framework: The systems-first scale test. Before hiring anyone, document the process they’ll be doing. Every step. Every decision point. Every quality check. If you can’t write it down, you can’t delegate it. If you can’t delegate it, a new hire will be learning by osmosis while your clients pay the tuition. I wrote about this principle in how to think in systems, and it remains the single most practical thing I teach founders who are approaching their first hire.
Failure #4: The Side Project That Didn’t Survive a Market Shift
I was building a side project — a digital product targeting a specific professional niche. The market research looked solid. The early interest was encouraging. I invested months and a meaningful amount of capital into building it.
Then the market conditions shifted. The external landscape changed in a way that made my product significantly less relevant. Not slightly outdated — fundamentally misaligned with the new reality. Rebuilding to match the new conditions would have required essentially starting over.
I could have rebuilt. The underlying demand was still there. But the economics no longer worked. What was originally a manageable build had become a much larger commitment, and the revenue projections no longer justified the investment.
I shut it down.
This was the failure that taught me the most, because it wasn’t caused by a mistake. I had done the research. I had validated the market. I had built a quality product. The external environment simply changed in a way I couldn’t have predicted or controlled.
The framework: The adaptability margin. Every business plan should have a buffer — not just in cash, but in time and structural flexibility. If your entire model depends on one supplier, one platform, one regulation, or one market condition remaining stable, you’re building on sand. The question to ask before committing resources: if this one thing changed, could we adapt in under 90 days? If the answer is no, you need a wider foundation. This is why the velocity principle became so central to my approach — speed isn’t just about growth. It’s about the ability to change direction before you run out of road.
Failure #5: The Exit That Almost Wasn’t
This one is more recent. 2023. Vulpine was successful by every external measure. Twelve products, 4.9 stars, global distribution. But internally, we had a problem: the business was too dependent on me.
I had built myself into the center of every critical process. Quality control ran through my hands. Supplier relationships depended on my personal connections. Product development required my approval at every stage. The owner dependency score I now teach other founders to calculate? I would have scored a terrifying 9 out of 10.
When we first explored winding down the production side, it became clear that the business’s dependency on me was a liability. The business was profitable but not easily transferable. It was a good business that was also a bad asset.
We spent months systematically documenting processes and preparing the product lines for transfer. It was tedious, unglamorous work. And it was the work that made the exit possible in 2024 — selling the IP and inventory to respected companies in the magic industry.
The framework: Build for transfer from day one. Even if you never plan to sell, build as if you will. A business that can run without you is a business that can grow beyond you. A business that depends on you is a ceiling dressed up as a company. Every process you’re personally doing that could be documented and delegated is a link in the chain that ties you to the building. Cut the links as you build them.
The Meta-Lesson
Five failures. Five frameworks. But the overarching pattern is simpler than any individual lesson.
Every failure I had was caused by something I refused to look at. The product nobody asked for — I refused to look at whether anyone wanted it. The partnership — I refused to look at our value differences. The premature scaling — I refused to look at whether I was ready. The vanishing market — I refused to look at my dependency on a single external condition. The exit crisis — I refused to look at how central I was.
The refusal was never conscious. I wasn’t choosing to ignore these things. I was simply too close to see them, too invested to question them, and too busy to slow down long enough to check.
That’s why the subtraction audit exists. That’s why the weekly review exists. That’s why accountability partners and pre-mortems and honest conversations with people who aren’t invested in your success exist. They’re all mechanisms for seeing the thing you’re refusing to look at before it becomes the thing that takes you down.
I don’t celebrate failure. I don’t think it’s romantic or necessary or “the best teacher.” The best teacher is success. Failure is the expensive, painful, time-consuming backup teacher you get when you didn’t learn the lesson the easy way.
But if you’re going to fail — and you will, because building anything real guarantees it — you might as well extract the framework. Write it down. Name it. And use it to make the next failure cheaper.
