The 4S Method: State, Structure, Solve, Sell

Watch a smart team attack a hard problem and you'll usually see the same failure: they start solving immediately. Within minutes someone proposes an answer, the group debates it, and the actual problem—what's really broken, for whom, by when—never gets defined. Weeks later the work is rigorous, the deck is polished, and the recommendation lands on the wrong question.

The 4S method, formalized by Bernard Garrette, Corey Phelps, and Olivier Sibony in Cracked It!, is the antidote. It sequences problem-solving into four distinct stages—State, Structure, Solve, Sell—and refuses to let you skip ahead. Each stage produces a concrete artifact, and each artifact becomes the input to the next stage.

The first stage is the one everyone skips. Stating the problem means converting vague trouble—'margins are eroding,' 'we're losing to a competitor'—into a precise, agreed statement of what needs to be solved, for whom, and what success looks like.

A useful discipline here is TOSCA: name the Trouble that triggered the work, the Owner whose problem it is, the Success criteria, the Constraints you must respect, and the Actors involved. A problem statement that answers all five is short, sharp, and surprisingly hard to write. If two stakeholders would state the problem differently, you haven't finished stating it.

With the problem stated, structuring breaks it into parts you can actually investigate. This is issue-tree territory: decompose the core question into MECE branches, then into sub-questions concrete enough that each one implies an analysis.

The test of a good structure is not elegance—it's coverage and testability. Somewhere in your tree, the answer must live; and every leaf should be a hypothesis someone could confirm or kill with data. Structure is also where you commit to a hypothesis or remain exploratory: a hypothesis-driven tree moves faster but hardens your blind spots, so choose deliberately.

Solving is where most people want to start—and where the earlier stages pay off. Instead of analyzing everything, you rank the branches of your tree by likely impact and ease of testing, then run the critical analyses first. An 80/20 workplan beats a complete one: the goal is to kill or confirm the hypotheses that swing the answer.

The output of Solve is not a pile of exhibits. It's a set of findings—each one a sentence someone could act on, backed by the analysis that supports it. If a workstream produced no finding that changes the answer, it wasn't analysis; it was activity.

The final stage is the one analysts resent and executives remember. A correct answer that isn't adopted is a failed project. Selling means re-organizing your work into the audience's logic: lead with the recommendation, support it with a small set of key arguments, and hold the detail in reserve.

This is the Pyramid Principle applied to your findings: the storyline comes first, the exhibits serve the storyline, and the journey you took to get there—the dead ends, the clever analyses that didn't matter—gets cut. The reader should be able to stop at any level of depth and still walk away with the answer.

The most common failure is jumping from a half-stated problem straight to Solve—analysis as displacement activity. The second is treating the stages as one-way: 4S is a sequence, but not a straitjacket. A finding in Solve can reveal that the problem was mis-stated; the right move is to loop back and restate, not to push forward on a broken foundation.

The subtler failure is saving Sell for the end. Strong problem-solvers draft the storyline early—a ghost deck of what the answer might look like—and let it sharpen the analysis plan. Selling isn't a phase you enter in the last week; it's a pressure the work should feel from the start.

The method is simple to describe and hard to practice, because every stage fights a natural instinct: State fights the urge to answer, Structure fights the urge to explore, Solve fights the urge to be complete, and Sell fights the urge to show your work. Habit beats willpower here—run every problem, however small, through the same four gates.

This is also how Razn is built: every project starts as a 4S sequence—State, Structure, Solve, Sell—with the problem statement, the issue tree, the workplan, and the storyline as first-class artifacts. Whether you use software or a whiteboard, the discipline is the same: don't start solving until you've stated, and don't stop at the answer—sell it.