The 10% Working-Version Rule
Have a testable working version by the time 10% of your time budget elapses, not at the halfway point
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 95%
Nan Yu argues there is no real trade-off between speed and quality — sloppiness, not speed, kills quality. The mechanism to move fast without cutting quality is compressing time-to-first-working-version: instead of research-then-design-then-build, you get something that runs and tests a key hypothesis within the first ~10% of your allotted time, then spend the rest iterating against reality through expanding circles of real users.
Origin
Nan Yu's articulation of how Linear builds, reinforced in the episode by a Patrick Collison (Stripe CEO) tweet that 'good, cheap, fast: choose two' is 'devious misinformation spread by the slow.'
Core principles
- 01Speed and quality are not a trade-off; competence is the real driver of both
- 02The first version is your best guess in the general direction, never expected to be great — so no one wastes time being a perfectionist
- 03The value of software comes from how many iterations you could run, and iterations require going fast
- 04Waiting until you are 80% done to test a core assumption is too late to change course
- 05Cheapness comes from lowering the quality bar of V1: no pixel-perfect design, no chasing minor UI bugs
How to run it
- 1
Set a rough time budget and target 10%
Estimate how long the feature should take, then commit to having something that actually works by the time only 10% of that budget has passed — for a one-month feature, that means a working version in roughly the first week.
Pro tip The goal is not a polished candidate; it is the smallest thing you can start learning from.
Watch out If you only have a rough candidate at the halfway point, you are already too slow to safely change direction.
- 2
Build the smallest thing that tests your key hypothesis
Strip out anything that does not test whether the core assumption holds. Skip pixel-perfect design and minor UI bug fixes — what matters is working software you can interact with to see if it solves the core problem and feels good.
Pro tip Frame it as taking a controlled risk that V1 will not be perfect; that framing is what makes it cheap to build.
- 3
Release through a gradually widening circle of users
Every feature is used by an expanding set of users before general availability: first internal (Linear uses Linear daily), then early-access beta customers, then multiple beta audiences, then GA. Each ring gives real feedback and real problems to solve.
Pro tip If no one in an early ring engages with or uses the feature, that silence is a strong signal you missed the mark.
Watch out Before exposing a feature to external betas, ensure it will not corrupt user data or look hideous — the quality bar rises as the circle widens.
- 4
Spend the remaining time deciding: iterate or polish
Because a working version exists so early, the rest of the budget is spent choosing whether to run another iteration or polish the current version to shippable state — a decision you set your future self up to make.
In the wild
Linear maintains a gradually increasing circle of users for every feature. It starts with internal dogfooding since the team writes software in Linear daily, then moves to an early-access beta group, then several beta audiences, then general availability.
→ By the time a feature hits GA it has already been used and stress-tested by many different user types, de-risking the release.
Common mistakes
Equating speed with rushing
Teams assume going fast means being sloppy. In fact experts at the pinnacle of a craft are fast precisely because the work is second nature and clean — speed is a signal of competence, not corner-cutting.
Perfecting V1
Sanding everything down to tip-top shape before testing wastes the cheapest learning window and delays the moment you discover a wrong assumption.
Is it for you?
Best for
Product and engineering teams in competitive B2B software who want to increase iteration count and validate direction before over-investing
Not ideal for
Work where a broken or partial first version could corrupt customer data or where regulatory/safety constraints forbid shipping anything unpolished
From the transcript
“by the time 10% of it has passed you have a workable solution right”
“like no no no like after week one you have something that works that tests some kind of key hypothesis internally”
“the only way you're going to get a bunch of iterations done and try different things and really feel out uh these different variations is…”
“we have uh a sort of gradually increasing sort of Circle of users that use every single feature so by the time it hits uh…”
From the episode
Linear’s secret to building beloved B2B products
Nan Yu (Head of Product)