The Product SystemThe Vault
The 6 Brutal Laws of Product (And the Question Each One Asks), the infographic in this PDF

Product decision-making

The 6 Brutal Laws of Product (And the Question Each One Asks)

Pareto, Goodhart, Sturgeon, Conway, Kidlin and Brooks. Six laws that weren't written for product teams, and the planning question each one forces.

Want this as a PDF?

You'll also get The Product System, my weekly note on leading product in the AI era. Unsubscribe anytime, and I'll never sell your email. How I handle your details

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

Six laws that weren't written for product teams. But they explain why most features fail.

They come from two economists, two authors, a computer scientist and a software engineer. None of them are about execution. They're about judgement: what to build, what to measure, what to leave alone. The laws didn't change. The cost of ignoring them did.

Each one below turns into a single question for your next planning session. Ask them before the sprint, not in the retro.

Pareto's law: a few features carry the product

Vilfredo Pareto was an Italian economist, and his law is usually put as "80% of the results come from 20% of the causes."

In product, the default is to treat every feature on the roadmap as if it matters equally. It doesn't. A few features carry the product. The rest is noise you maintain forever.

The question: what would we keep if we could only ship 20% of this roadmap? It forces a ranking that a full roadmap lets everyone avoid. Find the 20% that matters. Cut the rest before it cuts you.

Goodhart's law: the metric that stops meaning anything

Charles Goodhart was a British economist. His law is usually quoted as "When a measure becomes a target, it ceases to be a good measure."

The trap is the number that's easy to win. Story points, AI adoption, features shipped. All easy to push up. None of them prove the product got better. Once a team is rewarded for moving a proxy, it moves the proxy. The dashboard looks healthy while the thing it was meant to track stands still.

The question: is our metric the outcome, or a proxy we can game? Measure what changed for the user, not what left the factory.

Sturgeon's law: most of everything is noise

Theodore Sturgeon was an American author, and his law is blunt: "90% of everything is crap."

The default is to assume that more output means more value. It rarely does. AI just makes the 90% cheaper to produce. The hard part was never making things. It's knowing what not to build.

The question: what are we deciding NOT to build this quarter? The cost of building has come down. The cost of being wrong hasn't.

Conway's law: you ship your org chart

Melvin Conway was an American computer scientist. His law has a well known short form: "You ship your org chart."

Your product copies your company. Disconnected teams build a disconnected product. The seams users trip over in the interface are often the seams between two teams that don't talk. No roadmap fixes a structure that pulls the product apart.

The question: does our team structure match the product we want? Fix the org chart before you fix the roadmap.

Kidlin's law: write the problem down first

Kidlin's law is credited to the British author James Clavell: "If you can write the problem down clearly, you're halfway to solving it."

The default is to start building before anyone can name the problem, or who even has it. The work looks fast right up to the moment someone asks what it was for.

The question: can we write this problem in one sentence before we scope it? Write the problem before the solution. Clarity beats cleverness.

Brooks's law: more hands can make it slower

Fred Brooks was an American software engineer, and his law is the one every late project learns the hard way: "Adding people to a late project makes it later."

The instinct under pressure is to add capacity. More people, another tool, and now an AI agent. Each one brings coordination cost before it brings speed. Add AI to a messy process and all you get is a faster mess.

The question: will adding this person, tool or AI agent actually speed us up? AI amplifies your operating system. It doesn't replace it.

The laws didn't change, the cost did

Read the six together and they point the same way. Each one is a warning about a decision that gets made by default when nobody makes it on purpose. Pareto says most of the roadmap won't matter. Goodhart says your metric might be lying. Sturgeon says most output is noise. Conway says your structure shapes the product. Kidlin says the unclear problem is the real blocker. Brooks says more hands won't save a late plan.

What changed is how fast you can ignore them. AI lets you ship the wrong thing faster than ever, which makes the questions more valuable, not less. Moore's Law made compute cheap. It never made judgement cheap.

If you could enforce only one of these six in your next planning session, pick the one your team skips most often.

Download the one-page version and bring it to your next planning session.

Questions people ask

What are the laws of product management?
There's no official set, but six laws from outside product explain a lot about why features fail. Pareto's law (a few features carry the product), Goodhart's law (a target stops being a good measure), Sturgeon's law (90% of everything is noise), Conway's law (you ship your org chart), Kidlin's law (write the problem down clearly first) and Brooks's law (adding people to a late project makes it later).
What is Goodhart's law in product management?
Goodhart's law says that when a measure becomes a target, it ceases to be a good measure. In product, it shows up when teams chase story points, features shipped or tool adoption. Those numbers are easy to move and prove nothing about whether the product got better, so measure what changed for the user instead.
How does Conway's law affect product teams?
Conway's law says a product mirrors the structure of the organisation that builds it, often summed up as "you ship your org chart." Disconnected teams build a disconnected product. If the product you want needs teams to work as one, the structure has to change before the roadmap can deliver it.
What is Brooks's law and does it apply to AI tools?
Brooks's law says adding people to a late project makes it later, because every new person adds coordination cost before they add speed. The same logic applies to new tools and AI agents. Added to a messy process, they give you a faster mess, so fix the operating system first.
What questions should product teams ask in planning?
Six useful ones: what would we keep if we could only ship 20% of this roadmap, is our metric the outcome or a proxy we can game, what are we deciding not to build this quarter, does our team structure match the product we want, can we write the problem in one sentence, and will adding this person, tool or agent actually speed us up. Ask them before the sprint, not in the retro.