Quality, Features, Deadline — Choose Two
Every launch drops one of three; software lets you drop quality only if you plan to earn it back
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 95%
A launch triangle Dylan Field learned from Figma co-founder Evan Wallace: for any new launch you get quality, features and deadline — pick two. Because software is iterable (unlike physical goods), you CAN legitimately ship features-plus-deadline and improve quality afterwards. But the choice must be conscious and made up front, and the iteration phase must actually go back and pay the quality debt, not just add more features.
Origin
Field attributes this explicitly to Evan Wallace, his Figma co-founder ('another thing that Evan taught me'). It is a variant of the classic project-management iron triangle, adapted for software's iterability. The 'minimally awesome product' phrasing is Field's own upgrade of MVP.
Core principles
- 01For a new launch you can have quality, features, and deadline — choose two.
- 02Software's superpower is that quality can be added after ship; hardware's cannot.
- 03The default for a v1 is a minimum bar of quality with fewer features, not maximum features with broken quality.
- 04Aim for a minimally awesome product, not a minimum viable one.
- 05Iterative improvement must include quality, not only new features.
How to run it
- 1
Name the launch type before you scope it
Decide up front whether this is a get-it-out-and-learn launch or a hold-the-bar launch. Field's own products split both ways: FigJam and Figma Slides were shipped fast to get feedback; Dev Mode took roughly three times as long because the team had to genuinely understand the developer user first.
Pro tip If the user and the problem are already well understood, bias to speed. If you do not yet believe you are adding value, speed just ships a wrong thing faster.
- 2
Explicitly drop one of the three
Choose the two you are keeping. Quality + deadline means cutting the feature set to a minimum. Features + deadline means accepting a quality gap you will repay. Quality + features means the date moves.
Pro tip Write down which one you dropped. The failure mode is teams that quietly believe they kept all three.
Watch out Never silently sacrifice quality. Field is explicit that you sometimes need at least a minimum bar of quality, and shipping fewer features is the price of it.
- 3
Set the minimum quality bar for the thing you DO ship
Even in a features+deadline launch, define the floor below which the shipped surface will not go. The result is a 'minimally awesome product' — small in scope, but genuinely good at what it does.
Watch out The bar for switching products is high (Field notes B2B craft expectations have risen). A launch below the switching bar gets no feedback because nobody uses it.
- 4
Ship fast to convert opinions into feedback
Get it out. The faster it ships, the faster real feedback replaces internal speculation. Field's regret about Figma is that it took three and a half years to launch and roughly five to get a paying customer — his verdict: 'too long, don't do that'.
Pro tip Hire someone who forces the ship date. Figma's shipping was catalyzed by an engineering leader who, in his first week, presented the gap and said 'you're really close, let's go'.
- 5
Pay back the quality debt in the iteration phase
Once live, do not spend the entire iteration budget on new features. Field's rule: when iteratively improving, you cannot just focus on features — you have to focus on the quality too.
Watch out Features+deadline launches quietly become permanently low-quality products when the roadmap after launch is all-new-features.
In the wild
Both were shipped extremely fast on purpose. The problem and users were well understood enough that the value of early market feedback beat the value of a longer polish cycle.
→ Both reached market quickly and generated feedback loops that guided subsequent iteration.
Dev Mode looked deceptively simple from the outside, but Figma tried directions that did not work and had to keep iterating until the team genuinely believed it added value and truly understood the developer user. Field says it took at least three times as long as products that look more complex.
→ A product that appears simple but required a much longer build — proving that perceived simplicity is not a proxy for build cost, and that a fast-ship default would have shipped the wrong thing.
Figma took three and a half years to launch and about five years to a first paying customer. Field attributes the delay partly to slow hiring and partly to the genuine difficulty of the product — but he does not defend it.
→ Field's explicit advice to founders: 'wait too long, don't do that' — everything they tell you about getting the product out quickly is true.
Common mistakes
Trying to hold all three
A team that refuses to drop quality, features, or the deadline does not escape the trade-off — it just makes the trade-off unconsciously, usually by shipping late AND buggy.
Applying MVP thinking to a physical-goods-like surface
The trade only works because software can be iterated after release. If quality is baked in permanently at ship time, you cannot use the iterate-later escape hatch.
Confusing simple-looking with cheap-to-build
Dev Mode looked simpler than FigJam and cost three times as much to build. Estimating the launch triangle off the perceived surface complexity produces wildly wrong scope.
Is it for you?
Best for
Founders and product leaders scoping a v1 or a major new surface who need a defensible, explicit trade-off instead of a schedule everyone privately knows is fiction
Not ideal for
Products where quality failures are irreversible or unsafe (hardware, medical, financial infrastructure) — there, the quality leg is not tradeable at all
From the transcript
“another thing that Evan taught me was that um for any new launch you got quality features deadline choose too”
“I'm not saying you should always do that sometimes you need to at least have a minimum bar of quality for the things you have…”
“so you choose Fe you know quality and deadline and sometimes you say actually here's the minimum feature set and we're going to have this…”
“everything they tell you about uh you know making sure that you get a product out really quickly is totally true the faster you”
“just be focused on the features you had to focus on the quality too”
From the episode
Dylan Field live at Config: Intuition, simplicity, and the future of design