so-what-test

The "So What?" Test

Concept

Most analyses fail at the last step. People surface findings, lay out data, and stop — leaving the reader to figure out what it means and what to do. The "So What?" test forces you to close the loop: every finding must lead to an action specific enough to assign.

A finding without a "so what" is trivia. A finding with a "so what" is a recommendation.

Required output format

Three explicitly labeled sections, in this order:

**Process:** [What specific data, workflow, or factor was analyzed.]

**Result:** [The objective outcome — numbers, signals, observations.]

**Insight:** [The underlying reason this matters + the immediate action. Specific enough to assign to a person with a deadline.]

Defaults & flex points

Default	When to flex
Process is one or two clauses	Don't flex — long preamble buries the answer.
Result has numbers or specific observations	Don't flex — vague Results undermine the Insight.
One Insight per block	If multiple actions are warranted, write multiple So What blocks rather than one Insight with three bullets.
Insight names who, what, and by when	Don't flex — that's the test.

The assignability test: could you copy your Insight into an assignment to a named person with a deadline, and would they know what to do? If not, rewrite it.

Example — HR / people analytics

Problem: Mid-level engineering attrition has risen for three consecutive quarters. The VP of Engineering wants to know why and what to do.

Bad

Process: Looked at attrition data.

Result: Attrition went up.

Insight: We should focus on retention.

(Process is too vague. Result has no number. Insight is unassignable. Three failures.)

Better

Process: Joined exit-interview transcripts (n=24) with promotion-cycle data, comp-band placement, and manager-tenure data for all mid-level engineers (L4–L5) who left between Q2 of last year and Q1 of this year. Compared to a control cohort of L4–L5 engineers who stayed.