Story, Not Specs Arc
Move from the current problem to a proven picture of the future
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 97%
The Story, Not Specs Arc presents an idea as a transition rather than a catalogue of features. Start with the status quo, then expose the limitation or frustration that makes change necessary. Raise the stakes with a bold promise, demonstrate the solution as proof, and finish with a concrete picture of the future. Codie attributes this pattern to Steve Jobs's product communication: he described clunky phones or heavy laptops, promised a better experience, and showed the solution live. The mechanism is memory and attention. A simple account of change gives the audience a structure it can follow, while sparse language and visuals preserve the bandwidth to feel the difference. Specifications can support the story, but they do not lead it.
Origin
Codie derives the arc from Steve Jobs's stripped-down product presentations and his preference for showing a solution live instead of leading with features.
Core principles
- 01People remember change better than feature lists
- 02A clear problem gives the promise meaning
- 03Proof should be shown rather than merely described
- 04Simple language leaves room for the audience to feel the story
How to run it
- 1
Establish the status quo
Show what the audience experiences now in concrete language. Make the starting point recognizable before introducing the change.
Pro tip Use a familiar observation rather than an abstract market description.
Watch out Do not spend so long on background that the problem disappears.
- 2
Expose the problem
Name what is clunky, heavy, slow, costly, or otherwise unsatisfactory about the current state. Connect the limitation to something the audience cares about.
Watch out Do not exaggerate a weak problem to manufacture stakes.
- 3
Make the bold promise
State the meaningful change in one short, concrete line. Give the audience a clear destination rather than a bundle of capabilities.
Pro tip Aim for a headline that can organize the entire presentation.
Watch out The promise must remain supportable by the proof that follows.
- 4
Show the proof
Demonstrate the solution live or present direct evidence that the promised change is real. Let the audience see the difference rather than asking it to infer one from jargon.
Pro tip Build the demonstration around the promise, not every available feature.
Watch out A proof overloaded with details can bury the change it is meant to show.
- 5
Reveal the future
Close by showing how the audience's world looks after the solution works. Reinforce the transformation, not the specification list.
Pro tip Echo the opening problem so the contrast is unmistakable.
In the wild
The presentation begins with the limitations of existing devices, promises that the audience will hold all of its songs in a pocket, and then shows the solution. The product is remembered as a change in experience rather than a collection of technical specifications.
→ The audience can picture the benefit and connect the demonstration to it.
Common mistakes
Leading with the feature list
Specifications without a change narrative force the audience to determine why the product matters.
Promising without proving
A bold future loses credibility when the presentation never demonstrates the solution or supplies direct evidence.
Crowding the story
Dense slides, jargon, and excessive bullets consume the attention needed to follow and feel the transformation.
Is it for you?
Best for
Founders, marketers, and leaders presenting a product, strategy, or future vision.
Not ideal for
It should not replace detailed specifications when an audience needs them to evaluate safety, compliance, or implementation.
From the episode
Stop Over-Explaining: The 3 S’s Rule For Projecting Authority