Features need stories
Give someone a list of capabilities and they have to do the assembly themselves — work out which parts apply to them, in what order, to what end. Most won’t. Not from laziness; the assembly requires knowing the product, which is the thing they don’t have yet.
A story does the assembly for them. Someone like you, in a situation like yours, did this, and afterwards this was different.
Three parts, in order
What you can do. Why it matters. What success looks like.
The third is the one that gets dropped, and it’s the one that makes the other two legible. “Set up call routing” is a task. “By Friday, no caller waits more than twenty seconds and you stop checking the queue at night” is an outcome someone can want.
The same structure works internally, which is the underrated half. A team that can state the story — who this is for, what changes for them — makes consistent decisions about a hundred small things nobody will ever spec. A team that has only a backlog makes a hundred locally reasonable choices that don’t add up to anything.
Amazon’s working-backwards memo is the mechanised form: write the press release and the FAQ before any code, and if the release reads as boring then the feature is boring and nobody has to build it to find out. The value isn’t the document. It’s that stating the outcome first makes it obvious when the outcome was never really the point — a discovery that costs an hour on paper and six weeks in a sprint.
Where it breaks
Narrative is a compression, and compression discards.
A good story is coherent, and coherence is not a property of reality. The tidy arc — problem, insight, solution, transformation — is available for almost any set of facts, including a wrong one, and it gets more persuasive as it gets further from the mess. Teams that tell their story well can talk themselves past evidence for years, and the better the storyteller, the longer it runs.
There’s a specific version in product work: the narrative starts driving the roadmap. Something is built because it completes the story rather than because anyone needed it. The feature that “rounds out the vision” is usually this.
And stories are how software gets oversold. The gap between the story and the product is where trust is spent — a customer who bought the narrative and met the software will not extend credit twice. In a category with real limitations, which anything AI currently is, the temptation to narrate past them is constant and expensive.
The check: can you tell the story with the failure modes included and have it still be worth buying? If yes, tell it. If it only works with the caveats removed, the problem isn’t the storytelling.
Takeaway: translate features into user stories.