Pixar Story Spine

The Story Spine is a narrative template so simple it looks trivial — and so powerful it has shaped every Pixar film from Toy Story to Inside Out. Originally developed by playwright Kenn Adams in 1991 for improvisation, the Story Spine was adopted and popularized by Pixar's story team as a tool for structuring narratives that feel emotionally complete. In tech and company contexts, it's a lightweight way to turn a project update, pitch, or user story into something that resonates.

Origin

Kenn Adams, an improviser and playwright, created the Story Spine in 1991 as a tool for teaching improvisers how to structure narratives on the fly. The template — "Once upon a time... Every day... Until one day... Because of that... Because of that... Until finally... Ever since that day..." — was designed to give performers a skeleton flexible enough to fit any story but rigid enough to produce emotional satisfaction.

Emma Coats, a former Pixar story artist, popularized Pixar's use of the Story Spine in 2011 when she tweeted "Pixar's 22 Rules of Storytelling," which included the Story Spine as rule #4. Coats clarified that while Pixar didn't invent it, the studio uses it heavily in early story development. The template has since become standard in UX, marketing, and product storytelling.

The Framework

The Template

Once upon a time there was _____.

Every day, _____.

Until one day, _____.

Because of that, _____.

Because of that, _____.

Until finally, _____.

Ever since that day, _____.

Seven sentences. Each one does specific work.

What Each Part Does

"Once upon a time..."     Establishes the protagonist and the world.
                          Who is this story about?

"Every day..."            Establishes the status quo, the baseline.
                          What is normal?

"Until one day..."        The inciting incident.
                          What changes everything?

"Because of that..."      The first consequence.
                          What does the protagonist do?

"Because of that..."      The escalation.
                          What does it lead to?

"Until finally..."        The climax / resolution.
                          How does it resolve?

"Ever since that day..."  The new normal.
                          What has changed for good?

The structure embeds three-act structure in a memorizable form:

Act 1 (Setup):       Lines 1-3 (protagonist, world, inciting incident)
Act 2 (Confrontation): Lines 4-5 (consequences, escalation)
Act 3 (Resolution):  Lines 6-7 (climax, new normal)

Why It Works

Protagonist-centric — A clear hero orients the listener.
Causal chain — "Because of that" forces the author to connect events logically, not just list them.
Transformation — The ending differs from the beginning; this is what makes it a story rather than a chronology.
Memorability — The rhythm of the template itself helps the audience remember.

How to Use It

In a Pitch or Update

The Story Spine is a drafting tool. Fill in the blanks for any narrative you need to tell; then adapt the language to the context.

1. Identify the protagonist. In company contexts, this is usually:
   - The customer
   - The team
   - The product itself
   - The company

2. Fill each blank as simply as possible.

3. Read it aloud. If a sentence doesn't earn its place, rewrite.

4. Adapt the language. You usually don't use "Once upon a time"
   literally — but the shape stays.

In Product Design

Many UX teams use the Story Spine to write user stories that have emotional resonance, not just functional specifications. Instead of "as a user I want X so that Y," they describe the user's current painful day and the transformed day after using the product.

Template fill:

Once upon a time there was a support engineer named Priya.

Every day, Priya answered 40+ support tickets, most of them the
same 5 questions about onboarding.

Until one day, we launched an AI assistant that could answer
those 5 questions instantly.

Because of that, Priya's ticket volume dropped by 60% overnight.

Because of that, she was able to focus on the hard tickets — the
10% that actually need a human.

Until finally, Priya reported that her job satisfaction was the
highest it had been in 3 years.

Ever since that day, our support team has been able to scale with
customer growth without hiring proportionally.

Adapted for a pitch deck:

Slide 1: Support engineers today answer 40+ repetitive tickets per day.

Slide 2: The top 5 questions account for 60% of volume.

Slide 3: We built an AI assistant that handles them.

Slide 4: Result: 60% volume drop, support engineers freed to solve
         hard problems.

Slide 5: Satisfaction up, scale without hire, retention up 20%.

Slide 6: Ask: expand to 3 more product areas next quarter.

The pitch deck is a compression of the Story Spine. Each slide corresponds to one or two lines of the Spine. The underlying narrative does the emotional work; the slides do the informational work.

Example 2: Narrating a Quarter (Engineering Retrospective)

Once upon a time there was a platform team responsible for
deployment infrastructure.

Every day, they manually reviewed deployment PRs and responded to
SRE escalations.

Until one day, production incidents spiked — 4 in one week, all
caused by deployment errors.

Because of that, the team paused feature work and focused entirely
on a deployment platform rewrite.

Because of that, the new platform shipped 2 weeks later than planned,
but with automatic rollback and 90% fewer manual steps.

Until finally, Q2 incident count dropped to 1 — a 75% reduction —
and deploy time dropped from 2.5 hours to 18 minutes.

Ever since that day, the platform team has been able to return to
feature work, and other teams have started trusting the platform
enough to deploy without SRE intervention.

This is much more compelling than a typical retrospective that reads:

Poor alternative:
  - Q2 work: Deployment platform rewrite
  - Delayed 2 weeks
  - Incidents reduced 75%
  - Deploy time: 2.5h -> 18min
  - Team velocity returning in Q3

Both have the same facts. Only one has a narrative.

Example 3: Customer Success Case Study

Once upon a time there was an e-commerce company (Acme) that
processed 10K orders per day.

Every day, their checkout service crashed during peak hours because
their infrastructure couldn't autoscale.

Until one day, they adopted our platform-as-a-service.

Because of that, they got autoscaling and load balancing out of
the box.

Because of that, their Black Friday 2025 handled 8x normal volume
without a single incident.

Until finally, they grew to 100K orders per day without hiring
any DevOps engineers.

Ever since that day, they've been a 10x customer and their founder
is our biggest reference.

Any customer case study can be structured this way. Most are not, and they're worse for it.

When It Works

Product pitches and launches
Customer case studies
Quarterly or annual narratives
User story writing (augmenting INVEST-style stories)
Explaining a change initiative to the organization
Onboarding narratives ("here's how our company evolved")
Any time you want information to be remembered, not just heard

When It Does Not Work

Purely technical specifications — An API reference doesn't need a narrative arc.
Breaking news / alerts — "The database is down" isn't a story; it's information needing action.
Deeply complex changes with many protagonists — Story Spine needs a clear protagonist. If there isn't one, don't force it.
Audience that distrusts narrative — Some technical audiences read any narrative structure as marketing spin. Use sparingly or acknowledge explicitly.

Common Failure Modes

Structural

Skipping "Because of that" — Most common failure. People jump from "Until one day" to "Until finally," skipping the causal chain. The story loses its spine.
No Transformation — The "ever since that day" looks the same as "every day." The story has no arc; nothing has changed. Why did you tell it?
Weak Inciting Incident — "Until one day" is vague or non-specific. The story doesn't clearly pivot.

Content

Hero Ambiguity — Multiple protagonists muddle the emotional pull. Pick one (person, team, product) and stick with it.
Passive Protagonist — The protagonist doesn't do anything; things happen to them. In business contexts, the hero must act.
Manufactured Stakes — Inventing drama that wasn't really there. Audience senses this and disengages.
False Ever-Since — Claiming a lasting transformation when it was actually temporary. Eventually the audience notices the disconnect.

Adoption

Too-Literal Language — Reading "Once upon a time..." in a board presentation feels juvenile. Adapt the phrasing; keep the structure.
Over-Use — If every update is a Story Spine, it loses its impact. Reserve for moments that genuinely benefit from narrative.
Template-Filling Without Revision — The Spine is a drafting tool, not a finished product. Always rewrite after the first pass.

Three-Act Structure — The underlying shape (Setup, Confrontation, Resolution). Story Spine is a seven-sentence version.
Hero's Journey (Campbell) — More elaborate; the Story Spine is a simpler cousin.
Nancy Duarte's Sparkline — A presentation-specific narrative structure; oscillates between current and future rather than a linear arc.
StoryBrand (Donald Miller) — Marketing-specific variation where the customer is the hero and the brand is the guide.
Situation-Complication-Resolution (McKinsey/Minto) — Business-writing cousin; roughly the first three beats of the Spine.
Narrative Transportation Theory — The academic psychology behind why stories persuade more than arguments.