Rule 2 of 38 · Chapter I — Start With the Problem

Question the requirement

Why this rule exists

Requirements arrive dressed as facts but are usually someone's guess at a solution. Taken at face value, they lock in work nobody actually needs and hide the real goal behind it. Asking why a requirement exists often reveals a simpler path, a smaller scope, or that the requirement was a proxy for something else entirely.

In practice

For each requirement, ask what problem it solves and what happens if you skip it. Trace it back to a user outcome or a business constraint. If nobody can name the outcome, treat the requirement as a hypothesis, not a mandate, and push back with the cheaper alternative you found by asking.

When it doesn't apply

Regulatory, legal, and safety requirements are not yours to negotiate away, though you may still question how they are met. When trust is high and the requester has clearly done the thinking, take it and move.