Entrepreneurship as Theory Building

Originally published on my LinkedIn.

Entrepreneurship is, at its core, the act of building an empirical theory about the world - a theory that is falsifiable in one of the most meaningful ways possible. If your theory is wrong, if you have built the wrong thing, the market will tell you so through a lack of users, outcomes, or success.

Execution matters, of course, but even there, the entrepreneur's greatest contribution is epistemological i.e. knowledge work. It is about discovering what the world truly needs, forming a coherent theory around that need, and positioning yourself so that you benefit if and when your theory turns out to be correct.

These are necessarily empirical theories, grounded in how the world actually is, not how you wish it to be. You cannot sit in an ivory tower and speculate. You have to come down into the real world, observe how it behaves, form a coherent theory of those observations, and then test that theory in reality.

This process of observing and testing mirrors the logical cycle of induction and deduction. Induction moves from specific instances to general conclusions: you observe concrete needs in the real world and generalize them into a theory, such as "the world needs this product." Deduction moves in the opposite direction, from the general to the specific: you take your theory (your product) and test it through specific instances such as sales, adoption, and feedback.

Entrepreneurship, then, is a continual induction–deduction loop. You build theories from observation, test them against reality, and refine or abandon them as evidence demands. Since our time is finite, we want this loop to be as short and tight as possible - correct the theory when we can, and discard it when we must.

In that sense, entrepreneurship is the iterative refinement of a living theory about the world - about what people need and how best to meet that need.

This pattern should be familiar to those of us who build software. We observe the changing requirements of the real world, construct a syntactic structure of computation in the world of code, interpret that structure back into reality, and verify that the results match our expectations. Because we are human, both our code and our theories need elegance, efficiency, and parsimony- which, if you squint enough, are really the same thing. From time to time, we refactor both our code and our theories, since smaller, cleaner structures are easier to reason about and evolve than large, messy ones.

Once you notice this pattern - the act of building up a structure (whether a theory or a piece of syntax) only to evaluate it back into the real world - you begin to see it everywhere. The same thing happens at the organizational level. The structure of an organization gets evaluated into the products it creates. This is precisely the logic behind Conway's Law: "organizations that design systems are constrained to produce designs that mirror their communication structures".