Sturgeon's Law

In the tech sphere, Sturgeon’s Law implies that most code or features are not necessary. Perhaps 90% of experiments or features don’t pan out, and only 10% drive real value.

As an engineer, not every line of code you write is gold; as a product manager, many features don’t delight users.

It pairs with the idea of the 10x engineer not as someone who writes 10x more code, but as someone who identifies the 10% of work that delivers 10x value. The risk isn’t the lower quality of the 90%, it’s the pretense that it isn’t. When a team considers all work to have the same value, it introduces more complexity and slows down.

In practice, Sturgeon’s Law encourages continuous refinement, assumes there’s a lot of “noise,” and focuses on finding the “signal.”

• It's like an extreme form of the Pareto Principle (80/20 rule). The bulk of what's being put out just isn't good, and the good stuff is the exception
• In software, there are often many features or code paths that add very little value, and the critical challenge is to find a way to maximize the high-impact 10%.
• Most new concepts or technologies fail to deliver, while the exceptional ones stand out.