Storytelling Structure Rules

A story works when the reader is made to want something before they're given information — establish what's at stake first, then let detail land against that stake. Detail delivered before the reader has a reason to care is just data; the same detail delivered after stakes are set is a story.

Stakes before details

• Establish what's at risk, wanted, or uncertain in the first few lines before piling on background, context, or setup. A reader tolerates ambiguity about details far longer than ambiguity about why they should keep reading.
• Cut any setup that doesn't change what the reader expects to happen next — a fact that doesn't raise a question or a stake is backstory, and backstory belongs later, doled out only when the story needs it, not up front.

Concrete specifics over abstraction

• Use a specific detail (an exact number, a named object, a precise moment) instead of the abstract category it belongs to. "She'd read the email four times before hitting send" carries more than "she was nervous about the decision" — the specific detail lets the reader infer the abstraction themselves, which lands harder than being told it.
• Prefer one vivid, telling detail over five generic ones. A single well-chosen specific does more work than a paragraph of general description and keeps the pace moving.
• Avoid abstract nouns doing the emotional work a scene should do ("it was a challenging time," "the team felt frustrated") — replace them with the specific moment or action that shows the challenge or the frustration.

One protagonist per story

• Give every story a single clear protagonist whose perspective and stakes the reader tracks — even in an account with many participants, choose one throughline character (a person, a team framed as a unit, a product) the reader follows.
• Introduce secondary figures only as they serve the protagonist's throughline; a story that keeps shifting whose perspective matters loses the reader's investment because there's no single stake to track.

Conflict is the engine

• Identify the actual obstacle, tension, or unresolved question driving the story before writing it — a sequence of events with no obstacle is a timeline, not a story, no matter how well-written the sentences are.
• State the conflict early enough that everything after it reads as movement toward or away from resolving it. A story that reveals its conflict late has spent its early real estate on nothing.
• Real conflict is specific: a resource constraint, a wrong assumption, a disagreement, a deadline, a technical limit — not vague "challenges" gestured at without naming what actually made the situation hard.

Show, then tell

• Render the concrete scene or moment first — action, dialogue, specific detail — and only then, if needed, state the takeaway explicitly. Reversing the order (stating the lesson, then illustrating it) drains the illustration of its work, since the reader already knows what conclusion to draw before seeing the evidence.
• Trust a well-rendered scene to carry its own meaning; add an explicit takeaway only when the piece's context genuinely requires spelling it out (e.g., a business case study where the lesson must be unambiguous for a skimming reader), and keep that sentence short when it's added.

The shape

• Hook: open on the moment of highest tension or the sharpest specific detail available — not chronologically first, but narratively most compelling. Start as close to the interesting part as the material allows.
• Tension: establish the obstacle, stakes, or question clearly enough that the reader has something to want resolved.
• Turn: the moment something changes — a decision, a discovery, a failure, a shift in understanding. This is the structural center of the piece; everything before builds to it and everything after flows from it.
• Resolution: what actually happened as a direct result of the turn — concrete outcome, not a vague sense of things working out.
• Meaning: what the resolution means beyond the specific instance, stated briefly and only once the concrete story has already made it evident. This goes last, never first.

Finding the story in dry material

• In a case study: find the moment before the solution existed — what was actually broken, what had been tried and failed, what was specifically at stake for the people involved — and use that as the tension, not the finished-product description.
• In a launch or announcement: find the specific problem or gap that made the launch necessary, told through one concrete example or one user's situation, rather than opening with the feature list.
• In data or research: find the surprising or counterintuitive number and ask what specific real-world situation produced it — a story needs a human or concrete stake, and raw data has to be traced back to one before it reads as a story rather than a report.

What kills a story

• Hedging: qualifying every claim ("in some cases," "results may vary," "arguably") drains tension and confidence; save precision caveats for material that genuinely needs them, and keep the narrative line direct elsewhere.
• Chronology as structure: listing events in the order they happened, with no shaping toward a turn, is the single most common way a true story fails to read as one — chronology is raw material, not structure, and needs to be reordered around tension and turn.
• Moral stated upfront: announcing the lesson before telling the story ("This taught me the importance of X. Here's what happened...") removes the reason to read the rest, since the conclusion has already been given away.