Why Most Frameworks Expire

Every startup framework started as someone's hard-won insight. They built something, it worked, they figured out why, and they wrote it down. Lean startup came from Steve Blank and Eric Ries watching what actually worked in early-stage companies. "Move fast and break things" came from Facebook when speed was genuinely more important than stability. Growth hacking emerged when a handful of companies discovered distribution advantages that nobody else was exploiting yet.

These were good ideas, tightly fitted to specific conditions. The problem is what happens next.

The insight gets turned into a book, then a blog post, then a conference talk, then a best practice. Somewhere along the way, the conditions that made it true get separated from the advice itself. People start following the framework because it's the framework – not because they've evaluated whether the conditions still hold.

I wrote about startup first principles as a way to think underneath frameworks. But there's a step before that: recognizing that the framework you're following might have already expired.

Lean startup is the clearest example, and one I've thought about a lot. The entire methodology was a rational response to one constraint: building software was expensive. When every feature costs months of engineering time, you validate before you build. You run cheap experiments. You treat building as the last resort, not the first instinct. That made perfect sense when the constraint was real.

AI collapsed that constraint. Building a working product now costs days, not quarters. But the framework is still being taught as gospel. I still see founders running weeks of customer discovery interviews before writing a line of code – not because the math supports it, but because that's what you're supposed to do. The reasoning expired but the ritual didn't.

Growth hacking followed a similar arc. When digital channels were new and attention was cheap, clever distribution tactics created real advantages. First-mover effects were strong. Viral loops worked because users hadn't been conditioned to ignore them yet. Ten years later, every channel is saturated, every tactic is commoditized, and "growth hacking" mostly means doing what everyone else is doing with a slightly different landing page. The conditions that made it powerful are gone. The conference circuit hasn't noticed.

"Move fast and break things" is maybe the most obvious case. It was a defensible strategy for a social network in 2006 when the cost of a bug was a few irritated college students. It's a catastrophic strategy for a company handling financial data, medical records, or critical infrastructure. Facebook itself eventually abandoned the motto. But it lives on as received wisdom for startups that operate in completely different contexts.

Here's what I think makes this genuinely dangerous: it's socially safer to fail while following a framework than to succeed by going against one. If you do what the books say and it doesn't work, you can point to the process. You did the right things. The market wasn't ready. The timing was off. Nobody blames you for following best practices.

But if you break from convention – skip the MVP, ignore the lean playbook, build something big before validating – you're out on a limb. If it works, you're a visionary. If it fails, you're the founder who didn't listen. The social risk of being contrarian is real, and it keeps people following frameworks long past their expiration date.

The useful skill isn't memorizing frameworks. It's developing a sense for when they've expired. That requires understanding why they worked in the first place, tracking whether those conditions still hold, and having the nerve to act on your own reasoning when they don't.

Most frameworks are fine. Some are genuinely useful. But none of them are permanent. The conditions that created them are always shifting – technology changes, markets mature, tactics get commoditized. I've learned to treat every piece of startup advice as having an implicit expiration date, and to keep checking whether the conditions that made it true are still in place.