Product Work: Laws, Effects & Principles

...that Shape What Product Teams Build

Every time a product team makes a decision, they:

🧭 Navigate ambiguity without a clear right answer.
👥 Coordinate with people who think differently than they do.
📐 Plan work that will take longer than expected.
⚙️ Build systems that behave in ways nobody predicted.
🌍 Operate inside a culture that shapes every choice invisibly.
🔀 Cross the line between engineering and product without a map.

So to make better product decisions, you need to understand the laws, effects, and principles that affect those six realities.

Below is a list of named principles (expanding weekly) for each category.

Product Thinking
Decisions
People
Context
Delivery
Tech
Empty space, drag to resize

Patterns that shape how product people and teams make choices

Occam's Razor

When two solutions solve the same problem, the simpler one is usually better
Empty space, drag to resize

Patterns about roles, teams, culture, and how humans coordinate

Brooks's Law

Adding people to a late project makes it later
Empty space, drag to resize

Patterns about sharing knowledge, framing problems, and making information visible

The Feynman Technique

If you cannot explain something simply, you do not understand it well enough to build it.

The Sapir-Whorf Hypothesis

The language people use shapes the concepts they can easily think and communicate about

The Default Bias

People tend to keep whatever option is set as the default, even when changing it costs nothing.

The Boiling Frog Syndrome

Gradual slow changes go unnoticed until the problem is critical
Empty space, drag to resize

Patterns about planning, estimation, execution, and shipping

Parkinson's Law

Work expands to fill the time available for its completion.

Hofstadter's Law

It always takes longer than you expect, even when you account for Hofstadter's Law.
Empty space, drag to resize

Patterns that help non-engineers understand how technical systems behave

The Principle of Least Astonishment

A system should behave in a way that least surprises the person using it.

Postel's Law

Accept inputs flexibly, but produce outputs strictly and predictably.
Empty space, drag to resize

Patterns that help engineers understand what working in product means

Wicked Problems

Some problems cannot be fully defined before you start solving them, and every attempt to solve them changes the problem itself.
  • Horst Rittel & Melvin Webber, Dilemmas in a General Theory of Planning (1973).

The Map Is Not the Territory

A model, spec, or diagram is always a simplification of reality, and reality will surprise you.
  • Alfred Korzybski (1931); applied to product thinking broadly.

The Kano Model

User needs fall into three types: basic expectations (must-haves), performance features (more is better), and delighters (unexpected value).
  • Noriaki Kano, Attractive Quality and Must-Be Quality (1984).

The Einstellung Effect

Having a solution in mind blocks you from seeing a better one.
  • Abraham Luchins, Mechanization in Problem Solving (1942); applied to engineering and product work.

Keep learning

Copyright © 2026
Created with