Systematized Creativity by Extremes
Build the most extreme version along one attribute, feel it, repeat in the opposite direction, then find where they meet
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 95%
To find non-obvious solutions, Nan Yu deliberately builds the most extreme possible version of a product along a single trait — the fastest, the safest, the most luxurious — discarding cost and practicality on purpose. Living with each extreme reveals what actually feels good and bad, expanding the search space so you discover the right option that would otherwise sit in an unexamined corner. The final answer is the balance point discovered between two opposing extremes.
Origin
Nan Yu's method at Linear; he connects it to Brian Chesky's Airbnb '11-star experience' exercise and contrasts it with working-backwards-from-the-ideal (attributed to Amazon/Jeff Bezos).
Core principles
- 01Creativity fails when people cannot extrapolate two or three steps beyond what's in front of them
- 02Asking 'how extreme can you take it' forces you past the constraints you psychically hold without realizing
- 03The biggest product risk is not choosing wrong among your options — it's never seeing the right option to begin with
- 04Extremes are defined by your product's core promise (e.g. 'always fast,' 'always safe')
- 05The right answer is usually the balance discovered between two extremes, and is obvious only in hindsight
How to run it
- 1
Name the core promise and its attributes
Identify the promise your product makes users (Linear: be fast) and the attribute axis relevant to the problem (e.g. speed vs. safety). Extremes are defined against that promise.
Pro tip For any company, ask what promise you're making users — it dictates which extremes are worth exploring.
- 2
Build the most extreme version along one attribute
Construct the outrageous version — the fastest, safest, most luxurious — and deliberately throw away cost and practicality. Ship it (at least internally) fast so you can actually feel it.
Pro tip Actually build it, don't just brainstorm for ten minutes — you learn from felt experience, not speculation.
Watch out The extreme is not the answer; it is a probe to map the possibility space.
- 3
Build the opposite extreme and feel it too
Now build the extreme in the other direction and live with its failure mode. Each extreme teaches you a distinct set of real problems.
Pro tip Roll extremes out to real user circles when safe — the safe-but-cluttered version's problems only surfaced once real users generated a paper trail.
- 4
Find where the extremes meet
Design the final solution as the specific balance point between the two extremes, informed by having felt both failure modes.
Pro tip The balance can be conditional — different behavior in different states — rather than a single compromise.
In the wild
For saving draft issues, Linear first built the fastest possible version: hit X and it's discarded, no save prompt, no interruption. It felt dangerously unsafe (users feared losing changes) — as suspected. So they built the opposite extreme: autosave every keystroke. That felt safe but left a paper trail of abandoned 'Untitled' objects. The final design conditionally splits the difference: on a brand-new issue it interrupts you to confirm saving a draft, but on an existing draft you're already editing it silently autosaves in place.
→ A non-obvious solution that feels right; a teardown would see very specific choices, but the path there was two deliberate extremes and finding where they meet.
Common mistakes
Deciding among only the visible options
You debate three choices when none of them is right — the correct fourth option sits in a corner you never looked because you didn't expand the search space.
Carrying invisible constraints
Practicality and cost assumptions you don't even realize you hold keep you from seeing the real possibility space; the extreme exercise exists to break past them.
Is it for you?
Best for
Product teams stuck between incremental options who need to discover non-obvious solutions and can ship extreme prototypes quickly
Not ideal for
Situations where building throwaway extreme versions is prohibitively expensive or where user data safety prevents even internal extreme experiments
From the transcript
“how how extreme can you take it like you're designing a a product you're trying to come up with a solution like what's the most…”
“the biggest risk is you didn't see the right choice to begin with right you have these three Cho and like none of them were…”
“the path to get there is to do something totally extreme in One Direction and then totally extreme in another Direction and then find where…”
“the best Solutions are always obvious in hindsight right”
From the episode
Linear’s secret to building beloved B2B products
Nan Yu (Head of Product)