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

Name the problem before the solution

Why this rule exists

Most wasted effort comes from solving the wrong problem well. When you jump to a solution, you smuggle in unexamined assumptions about what actually hurts and who it hurts. Stating the problem in plain language, separate from any implementation, exposes those assumptions early and gives the team a shared target to check the work against.

In practice

Before designing, write one or two sentences describing the problem: who has it, when it bites, and what a fixed world looks like. Keep the wording free of solution nouns like cache, queue, or service. Circulate it and watch for disagreement, because that disagreement is cheaper to resolve now than in code.

When it doesn't apply

For truly trivial or reversible changes, a formal problem statement is overhead. And in a genuine outage you act first and articulate later, though even then a one-line problem note keeps the response focused.