Parallel Story-and-Product Building
Define core principles, then develop the product and its story together
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 89%
This model replaces the traditional sequence of building first and creating the launch story later. The team begins by defining durable principles: what it is building, for whom, and why the change matters. Product development and narrative development then proceed in parallel. New capabilities refine the story, while attempts to explain or demonstrate the product expose unclear value and influence implementation. The team continuously updates both tracks instead of waiting for a long, polished launch runway that may be overtaken by competitors or technical change. Stable principles preserve coherence even when individual features, demonstrations, and release dates move quickly.
Origin
Extracted from Marketing Against The Grain
Core principles
- 01Anchor both product and narrative in stable principles
- 02Develop the explanation while developing the product
- 03Replace long launch runways with continuous sense-making
- 04Assume slow work may become obsolete before launch
How to run it
- 1
Define the anchors
Write down the audience, problem, promised transformation, and principles that should survive feature changes.
Pro tip Use plain language that engineers, marketers, and customers interpret similarly.
Watch out Feature lists are too volatile to serve as principles.
- 2
Draft the story early
Create an initial explanation and demonstration while the product is still being built.
Pro tip Use the story to identify which capability will create the clearest user realization.
Watch out Do not present an early narrative as an immutable launch script.
- 3
Build both tracks
Develop the product while repeatedly revising the narrative against real capabilities and feedback.
Pro tip Review product and story together in the same milestone meetings.
Watch out Separate teams can drift into describing a product that no longer exists.
- 4
Compress the demonstration
Find one succinct use case that makes the product's value immediately understandable.
Pro tip Prefer a concrete transformation over a broad capability catalogue.
Watch out A spectacular demo that is unrepresentative will damage trust.
- 5
Ship and continue refining
Release once product and story are sufficiently aligned, then learn with external users.
Pro tip Preserve the core principles while changing weak wording and examples quickly.
Watch out Waiting for complete certainty can make the work obsolete.
In the wild
An AI startup defines its promise as letting non-designers edit images conversationally. While engineers improve the model, marketers test demonstrations and discover that a simple before-and-after edit communicates more value than technical benchmark language. Both product and story converge around that workflow.
→ The team launches a coherent product before market changes invalidate a six-month campaign.
Common mistakes
Waiting until launch to explain the product
Late narrative work can reveal positioning problems when there is no time left to change the experience.
Chasing every weekly change
Without stable principles, parallel iteration becomes incoherent reaction rather than disciplined adaptation.
Polishing an obsolete story
A long launch runway is wasteful when the product or competitive landscape changes underneath it.
Is it for you?
Best for
Teams shipping rapidly changing products in markets where capabilities and competitors move weekly.
Not ideal for
Stable products whose specifications and market context rarely change.
From the transcript
“you have to know what your stories are, kind of your core principles of what you're building, so that like you can kind of continue…”
“that six months, somebody might build something way better. And the work you have is just completely obsolete.”
From the episode
Google's Secret AI Advantage (Why DeepMind Will Dominate)