🔄

Systems Laws

Brooks's, Gall's, and Goodhart's Laws — three fundamental systems thinking laws for product teams

15 minFramework

Systems thinking is the ability to see the world as a collection of interconnected systems and understand their behavior over time. Three laws - Brooks's, Gall's, and Goodhart's - describe fundamental constraints that operate in any organization and product team.

Why Systems Thinking Is Critical

Humans are poor at predicting system behavior over time. In experiments with inflow and outflow graphs (installs vs. uninstalls), only about 4% of people correctly identify the peak of the install base. Even among MIT freshmen, only 40-45% get the right answer. Systems thinking is a toolkit that compensates for this weakness.

Brooks's Law: People Don't Speed Up Projects

The Law

"Adding manpower to a late software project makes it later" - Frederick Brooks, "The Mythical Man-Month" (1975)

Brooks's Law operates for three reasons:

  • Ramp-up time: newcomers need to be brought up to speed on the project, pulling experienced team members away from their work
  • Non-parallelizable tasks: not all tasks can be divided among people. Nine women cannot give birth to a baby in one month
  • Growing coordination overhead: the number of communication channels grows as n(n-1)/2. A team of 5 has 10 channels; a team of 10 has 45

Context Collapses

As the number of people grows, the probability of context collapsesincreases exponentially - situations where relevant information does not reach the right people. Someone makes a decision without knowing about a critical constraint that another team member is aware of.

When a project starts falling behind, delays compound and reinforce each other: the team gets stressed, the client increases pressure, people get sick and take vacations. The more components in a project, the less controllable the outcome.

Brooks's Law in the AI Era

AI tools change the equation: instead of adding people, you can increase the autonomy of the existing team. A frontend engineer with Claude Code can write backend features themselves. One person can cover functions that previously required several specialists. This circumvents Brooks's Law - not through headcount, but by expanding each person's capabilities.

Gall's Law: Complex Systems Evolve from Simple Ones

The Law

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system" - John Gall (1975)

This was one of the earliest posts on the Telegram channel @ProductsAndStartups (2017) - that is how fundamental it is to product thinking. Gall's Law explains why:

  • Iterative development is more effective than trying to build a perfect product from the start
  • MVP works: start with a simple end-to-end solution, then add complexity
  • Big "from scratch" system rewrites usually fail
  • Microservice architecture should grow out of a monolith, not be designed upfront

Practical Corollary: Risks Live at the Seams

The biggest risks and bugs arise at the interfaces between modules, not inside them. This is a practical reformulation of Gall's Law for engineering teams. Each module may work perfectly in isolation, but integration reveals incompatibilities, unexpected interactions, and edge cases.

Therefore, the first thing to do is build a simple end-to-end solution that passes through all the seams. Let each component do the minimum, but make the entire chain work. After that, you can safely add complexity to individual components.

Goodhart's Law: Metrics Stop Working

The Law

"Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes" - Charles Goodhart (1975). Or in Goldratt's version: "Tell me how you measure me, and I will tell you how I will behave."

The problem is not with people, but with the fact that measurement changes what is being measured. As soon as a metric becomes a target, people start optimizing for the metric itself rather than what it is supposed to reflect.

Examples from Product Management

  • NPS as a KPI: the team starts asking users to give high scores instead of improving the product
  • Feature count: developers ship many small changes instead of solving complex problems
  • Lines of code: programmers write verbose code instead of elegant solutions
  • Support response time: agents give quick but superficial answers

Connection to Attention Tunneling

Goodhart's Law is closely related to attention tunneling: focusing on a single metric creates a literal cognitive tunnel where other important aspects of the product become invisible. A strategically correct focus on retention can make the team blind to degradation in acquisition.

Systems Thinking: Three Core Principles

All three laws are consequences of deeper systems thinking principles:

1. The World Is Made of Systems

Any organization, product, or market can be represented as a system of stocks and flows. Install base is a stock. Installs are the inflow. Uninstalls are the outflow. The state of a stock can only change through changes in flows.

2. Behavior Over Time Matters More Than Snapshots

Systems thinking focuses on dynamics: how a system behaves over time. This helps you "see the forest for the trees." A product manager should analyze the product systemically, looking at the trunk of the tree rather than individual leaves.

3. Feedback Determines Behavior

In systems, effects often influence causes, forming feedback loops. There are reinforcing loops (more users lead to more viral growth, leading to more users) and balancing loops (increased marketing spend leads to channel fatigue and rising acquisition costs).

A Common Logic Error

"We will increase the install base by spending more on marketing" - this sentence hides a logical leap. In reality: we will increase the inflow of installs. Whether the install base grows depends on what happens with the outflow (uninstalls). Phrasings where we skip intermediate steps lead to flawed mental models and wrong decisions.

Practical Tools

  • Book: Donella Meadows, "Thinking in Systems"
  • Method: Goldratt's Logical Trees (Theory of Constraints)
  • Method: 5 Whys (Toyota) for finding root causes
  • Framework: Altshuller's TRIZ for finding solutions within constraints
  • Practice: Zoom in / Zoom out - regularly switching between details and the big picture

Want to put this into practice?

In the "AI Founder" course, you'll not only learn these frameworks but apply them to your own idea with guidance from a mentor with 3+ years of AI startup experience.