structured-problem-solvinglisted

# Structured Problem Solving A leader asks a vague question. Three weeks later a document arrives that describes the situation in careful detail, sizes four things nobody asked about, and stops short of an answer. The decision is then taken in the meeting anyway, on instinct, by whoever speaks with most confidence. The three weeks bought nothing except the feeling that the question had been taken seriously. The cost is rarely the analyst time, though that is real. The cost is that the next vague question goes to someone else, or to nobody, and the organisation quietly learns that asking for analysis delays decisions rather than improving them. The opposite failure is cheaper to spot and just as expensive: an answer produced in an afternoon with no structure behind it, confidently delivered, which nobody can check and which falls apart the first time a chief financial officer asks how the number was built. This skill is the thinking layer the rest of the operating work sits on. The craft is not the frameworks. It is the sequence: find the real decision, structure the problem before touching data, commit to an answer early so the work has something to attack, and then spend effort only where the result would change what you recommend. ## When to use this, and when not to Use it when the question is open and the answer matters: why a metric moved, whether to enter a market, whether a cost line is fixable, what to do about a competitor, how big something could be, whether a