Part 1 · 1 chapters · ~8 min

Understanding the Problem Before Solving It

Restating the problem, separating the unknown, the data and the constraints, asking clarifying questions, finding the real requirement behind the stated one, defining done, and the cost of solving the wrong problem well.

3

Restate, question, define done

before solving anything
  1. Restate the problem in your own words and confirm it with whoever asked.
  2. Separate what is unknown, what is given, and what constrains the answer.
  3. Ask the questions whose answers would change your approach (scale, deadlines, who uses it, what must never happen).
  4. Find examples: two or three concrete inputs and expected outputs, including an edge case.
  5. Define done: how will we know it is solved?
code
stated problem   "The reconciliation job is too slow."
restated         "The nightly reconciliation must finish before 06:00 so operations can work breaks;
                  it now finishes at 09:30 on month-end nights and 04:00 otherwise."
unknown          why month-end takes 5.5 hours longer
given            job logs, input sizes, the matching rules
constraint       must match the same results; finance signs off any rule change
done             finishes before 06:00 on the next three month-end nights, results identical

Notice how the restatement changed the problem: it is not "make it fast", it is "make month-end nights finish by 06:00 without changing results", which points straight at what is different about month-end.