Best-Imaginable Product Brief
Define the breakthrough first, then turn ambition into testable capabilities
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 96%
Begin with an unusually demanding question: what would the best product the team itself could imagine using contain? Then translate the answer into a finite capability list that distinguishes a genuine leap from a modest upgrade. For DOOM, id Software specified controllable lighting and height, non-orthogonal walls, networked cooperative and competitive play, modifiability, and shareware distribution. The team paired this ambition with confidence in the planned engine architecture and later audited the original list, which exposed that multiplayer had been forgotten. The mechanism joins vision to accountability. A bold standard creates distance from the existing category, concrete capabilities guide design and engineering, architectural review keeps the promise plausible, and a written list prevents the team from quietly losing difficult commitments during execution.
Origin
Extracted from The Tim Ferriss Show through John Romero's account of defining DOOM before development began.
Core principles
- 01A breakthrough target should exceed incremental improvement
- 02Ambition becomes executable through concrete capabilities
- 03The architecture must support the promised experience
- 04A written brief preserves commitments during development
How to run it
- 1
Set the extreme standard
Describe the best product the team can imagine experiencing, not merely the next improved version. Make the desired leap explicit.
Pro tip Frame the question from the user's experience rather than from available features.
Watch out An extreme standard without execution experience becomes fantasy.
- 2
Identify the category barriers
List the limitations that make current products feel constrained. Decide which barriers the new product must break to feel drastically different.
- 3
Write concrete capabilities
Translate the vision into a bullet list of observable capabilities, experiences, and distribution choices. Avoid adjectives that cannot be tested.
Pro tip Write each item so the team can later answer whether it shipped.
- 4
Check architectural plausibility
Confirm that the planned architecture can support the list and that the builders understand the hardest unknowns. Revise promises that have no credible technical path.
Watch out Confidence from past success is not a substitute for checking the new architecture.
- 5
Build against the brief
Use the capability list as a stable reference throughout development. Let it guide priorities without confusing it with every implementation detail.
- 6
Audit before release
Return to the original list while there is still time to recover missing commitments. Resolve each omission deliberately rather than forgetting it.
Pro tip Schedule the audit instead of relying on memory.
In the wild
Before starting DOOM, id Software listed capabilities intended to move drastically beyond Wolfenstein 3D: variable lighting and height, angled walls, multiplayer, modding, and free shareware distribution. Romero revisited the list in October and noticed multiplayer was still missing, prompting John Carmack to add peer-to-peer networking.
→ The shipped game delivered the promised multiplayer and the other category-changing capabilities Romero described.
Common mistakes
Settling for incremental change
A list of minor improvements cannot produce the drastic experiential gap the method is designed to create.
Using untestable promises
Claims such as best or revolutionary do not guide execution unless translated into observable capabilities.
Forgetting the original brief
Without an explicit audit, difficult commitments can disappear during a long build, as multiplayer nearly did.
Is it for you?
Best for
It is best for proven teams attempting a category-defining leap after mastering the current form.
Not ideal for
It is not ideal for inexperienced teams that cannot yet assess the architecture or execution burden.
From the transcript
“And this was the only time we ever did this, the next game needs to be the best game we could imagine playing, that there…”
“So we made a list, a bullet point list of all the things that this new game should have.”
“I need to make sure we're putting everything in the game. We didn't promise stuff that we didn't deliver on, and we need to mostly…”
From the episode
#681: Doom Legend John Romero — The Path to Prolific Innovation and Making 130+ Games, How to Find the Soul of the Work, Audacious Ambition, and Building in Monk Mode
John Romero