Structured Problem Solving

Defining the problem well enough that the work of solving it becomes tractable.

Structured problem solving is the discipline of doing the boring parts in order: state precisely what the problem is and whose problem it is, break it into pieces small enough to investigate independently, work out which piece actually carries the weight, and only then start solving. Almost all of the value sits in the first two steps, and almost all of the time gets spent in the last one. A problem stated as "the deploys are slow" is not yet workable; a problem stated as "the test stage takes eleven of the fourteen minutes, and eight of those are one suite" is nearly solved. The method matters less than the habit of not skipping to the part that feels like progress.

Scenarios

An incident recurs monthly and each occurrence is fixed within the hour. What would you do — keep fixing it, since the fix is fast and reliable, or spend one of those hours instead on why it recurs?

You're asked why a report is late and can see six contributing causes. What would you do — present all six, or find out which one accounts for most of the delay and lead with that?

Three weeks into an approach, you can tell it won't work. What would you do — push on, since so much is already invested, or stop now while the investment is only three weeks?

Takeaway

Write the problem down in one sentence, with a number in it. If you can't, you don't have it yet.
Break it into pieces that can be checked separately, and check which piece carries the weight before solving any of them.
Notice when the problem has been framed to suit a tool you already like — including by you.
Distinguish "fixed" from "won't happen again." A fast reliable workaround can hide a problem for years.
Judge whether to continue on what remains to be spent, not on what has already gone. The past investment is gone either way.