Startup First Principles

Every startup framework started as someone's insight based on real experience. Then it's written about in books and blogs, and eventually followed like a recipe. People mistake frameworks for maps, but they are not. They're navigation tools that made sense in a specific context, and context changes.

I've watched founders follow the lean startup playbook into walls. Not because the playbook is wrong, but because they never asked why it works. They skipped the reasoning and jumped straight to the ritual. Interview users. Build an MVP. Iterate. The words become liturgy, detached from the thinking that produced them.

Here's what I think is more useful: forget the frameworks for a moment and look at the raw materials underneath them. A small set of primitives you can use to reason about any startup decision from scratch. This is first principles thinking, and it wins over any established framework, and enables you to navigate the unknown. Exactly what early-stage startup life is.

The primitives

Seven building blocks. Every framework, methodology, and piece of startup advice can be expressed as some combination of these.

Time. Your only real resource. Everything else is derived from it. Money is stored time – you trade hours for dollars, then trade dollars back for someone else's hours. When I say "spend resources," I mean spend time, directly or through its proxies.

Risk. The probability that something you believe is wrong, or that something you haven't anticipated will hit you. Risk is the reason you validate before building. It's also the reason you sometimes shouldn't – if the risk is already low enough, validation is waste.

Facts. Things that are objectively true, as opposed to things you merely believe. The gap between facts and beliefs is where risk lives. Closing that gap – through evidence, experiments, conversations – is most of what early-stage work actually is.

Objectives. Future states you're working toward. The destinations you can articulate and communicate to a team. Without clear objectives, time gets spent in every direction, which is the same as spending it in no direction.

Assets. Anything you own or have built: product, equity, IP, brand, data, relationships. Ownership is a property of assets, not a separate concept. What matters is what you have and what it's worth.

Obstacles. External forces that consume time with zero return. Regulatory blockers, technical debt, team conflicts, market shifts. They don't advance your objectives – they just burn your scarcest resource.

Leverage. Anything that multiplies the impact of time spent. A great hire is leverage. A distribution channel is leverage. So is morale – a motivated team gets more from every hour than a demoralized one. Leverage is why some startups move ten times faster than others on the same resources.

Frameworks in terms of primitives

Once you see the primitives, you can decompose any framework into its moving parts.

Pivoting: Changing to a new objective using the same assets, based on acquiring new facts that shifted your understanding of risk.

Fundraising: Exchanging a portion of your assets (equity) for time (via money) and often leverage (the investor's network, credibility, advice).

A hypothesis: A believed fact combined with the risk that you're wrong.

These aren't academic exercises. When you can see a framework as a combination of primitives, you can decide whether it actually applies to your situation – or whether a different combination would serve you better.

The MVP, decomposed

This is where it gets practical. Building an MVP is fundamentally:

Spending time on a short-term objective (the MVP) designed to gather facts and lower risk, in service of a bigger objective (the real product).

Strip away everything you've read about MVPs in books and blogs, and that's what's left. A formula. And once you have the formula, you can actually think about it.

Should you build an MVP? Start with the risk. What's your current level of understanding? What evidence do you already have? What assumption, if wrong, would kill you?

Then: is an MVP the best way to answer those questions? Maybe you could lower your risk faster by doing something else entirely. Maybe the risk isn't in whether people want the product – maybe it's a technical risk, or a regulatory one, or a distribution problem that no amount of user interviews will solve.

If you decide yes, build the MVP, the formula keeps working. What do you build and not build? Whatever most effectively converts time into facts that lower your highest risk. Nothing more.

Swimming against the current

Drew Houston walked into a crowded, commoditized market to build Dropbox. VCs told him it was a terrible idea. Every framework said don't enter a market with dozens of incumbents. He did it anyway - because he understood the primitives well enough to see what the frameworks missed.

That's what first-principles thinking buys you. Not a license to ignore advice, but the ability to evaluate it. Everyone might be telling you to interview more users (and most of the time they're right) but if your biggest risk is something user interviews can't touch, spending time on them isn't just unhelpful; it could be harmful, because of the opportunity cost and the false sense of progress.

There is no single correct answer to any startup question. The right move depends on your specific combination of time, risk, facts, objectives, assets, obstacles, and leverage. Startups are inherently resource-constrained. Sometimes you have to swim against the current to do what's right for you, in that moment.

That takes judgment. And judgment comes from thinking in primitives, not following playbooks.