Created from a single voice note with Agent Craft
For a long time, I treated failure like a verdict. Something goes…
For a long time, I treated failure like a verdict. Something goes wrong, you file it under "didn't work," and you move on. Clean. Final. That's how I operated for years and I genuinely thought that was the mature, unsentimental approach. It wasn't. It was just avoidance with better branding. The thing I've noticed over the last couple of years, building and making mistakes in a very public way, is that the bits and pieces come together differently when you stop treating failure as a closed file. Some of the clearest signals I've ever received about what actually matters came dressed up as things going badly wrong. I remember a specific period, not that long ago, where a project I had poured real energy into just flatlined. Not dramatically. It didn't explode. It just quietly stopped working and I had to sit with that. My instinct was to explain it away fast, find the external cause, the bad timing, the market conditions, whatever story made it feel like something that happened to me rather than something I contributed to. That instinct is almost always wrong. The real reason I rushed past it was because sitting with failure long enough to actually understand it is uncomfortable in a way that's hard to describe. It's not painful like an injury. It's more like having to slow down even more when everything in you wants to speed up and get to the next thing. Here's what changed for me. I started treating those moments the way I now treat a piece of content that didn't land, or a voice note that captured the thought badly. You don't delete it and pretend you never had the idea. You play with it. You look at what the signal actually is underneath the surface result. Because that's the move. Not the failure story. The signal inside it. I look back now and I can see this before and after effect quite clearly. There's the version of me who filed the losses quickly and kept sprinting. And there's the version who learned to sit in the discomfort long enough to ask what it was actually pointing at. Those two versions made very different decisions and built very different things. One bad launch I had years back. I thought it was a pricing problem, then a distribution problem, then a messaging problem. I burned months cycling through surface explanations. When I finally slowed down and looked at it honestly, the actual problem was that I hadn't spoken to enough people before I built the thing. The failure wasn't telling me to fix my pricing. It was telling me my process was broken at the foundation. If I'd filed it away fast the way I used to, I'd have carried that broken process into the next thing and the thing after that. The bits and pieces only come together in hindsight if you actually preserved them. If you file it under "didn't work" and close the tab, you lose the data. There's also something worth sitting with about timing. The failures I've learned the most from weren't the dramatic ones. They were the slow, quiet ones. The projects that just sort of faded. Those are the ones where the signal is hardest to read because there's no obvious moment of rupture. You have to look at the full arc, the before and the after, and ask what actually changed and when. I think that's why the long arc matters here. In the day-to-day lives of people building something, failure tends to get compressed into a short window. It happened, it hurt, move on. But the reframe almost never comes in that window. It comes six months later, or eighteen months later, when you're building the next thing and you suddenly recognise the shape of a mistake you made before. That recognition is worth protecting. Which means you have to keep the memory of the failure legible enough to recognise it when it shows up again in a different outfit. I don't think failure is a gift. I'm not interested in that framing. But I do think it's often a better information source than success, because success can mean you did the right thing or it can mean you got lucky, and it's genuinely hard to tell the difference in the moment. Failure is usually clearer about what it's pointing at, if you give it enough time and enough honest attention. The question I sit with now, and I'd be curious whether it lands for anyone else who's building or has been building for a while: What's one thing you wrote off as a failed project or a bad call that you've never actually gone back to look at properly?
More content from Agent Craft
- TikTokDon't optimize what shouldn't exist. If nobody's using that feature, cut it, you'll build something better without it. #softwaredevelopment #buildinpublic #productthinking #agentcraft #devtips #engineering
- X (Twitter)Working on something for weeks doesn't make it good. I've been building my app for a while now. Careful architecture. Real testing. Work I genuinely put time and thought into. And I just made the call to delete a lot of it. Not because it was bad work. Because the place I'm in now is different from where I started. And not everything that made sense at the beginning still makes sense today. There's a name for the trap I had to avoid. The sunk cost fallacy. The idea that because you invested in something, you have to keep it. That the hours justify the output. They don't. The work doesn't become valuable just because it was hard. So I cut it. And here's the thing: simplicity is almost always better. Not sometimes. Almost always. Complexity creeps in quietly, feature by feature, decision by decision, until you look up and realize you've built something that nobody, including you, fully understands anymore. The clean version is harder to ship because it feels like you're leaving something on the table. You're not. You're leaving the table clear enough to actually eat at. Simplicity is almost always better.
- BlogReal-Time Decision Engines vs. Traditional CRMs: How to Compare Real-Time Decision Engines for Email Segmentation Versus Traditional CRMs (And Why It Actually Matters)
- TikTokYour marketing team isn't your biggest asset, you are. The founder's voice is what people actually want to follow and buy from. #founderpersona #businessmarketing #personalbranding #entrepreneurmindset #marketingstrategy #contentmarketing
- X (Twitter)Nobody wants to follow your company. Nobody wants to read your brand's content. Nobody cares about your logo. That's not a hot take. That's just how people actually behave online.
- BlogWhat Tools Connect CRM and Ad Platforms for Unified Attribution This Year (And Why Most SMBs Still Can't Answer That Question)