Nan Yu on Speed, IC-First Product Design, and the Extreme Version Method

Nan Yu is Head of Product at Linear, the project-management tool widely regarded as a model of product craft. She previously held product roles at Facebook and other companies. At Linear, she has developed a set of practices around building high-quality products quickly without treating the two as a trade-off.

Key ideas

Speed and quality are not a trade-off. The premise that you must sacrifice one for the other is false. Linear’s record is the counter-evidence: a small team producing a product widely considered best-in-class in quality, shipped faster than most larger teams. The tension people feel is usually a symptom of unclear standards, not genuine conflict.
The 10% rule: every new feature or interaction should differ from user expectations by at most 10%. More than 10% requires users to build an entirely new mental model; less than 10% wastes the design opportunity. The skill is finding the highest-value change within the 10% constraint.
IC-first product design: refuse to build features that only make sense for managers or executives reporting up. If the primary beneficiary of a feature is a person who aggregates data for a status report, and not the individual contributor doing the work, the feature does not belong in a product built for people who do the work.
Extreme version method: when stuck on a design problem, push the concept to an absurd, unreasonable extreme. The extreme version clarifies the concept’s essence and often reveals a better version of the more moderate original idea.
The double triangle PM model: two distinct PM archetypes — the funnel PM (growth, activation, retention) and the value PM (feature work, product quality) — require different skills and metrics. Conflating them causes hiring mistakes and misaligned expectations.

Episode content

Speed as a product value

At Linear, speed is not a virtue in itself but a consequence of operating clarity. When everyone understands the product standard and trusts the standard, decision time collapses. Deliberation happens once (when the standard is set), not repeatedly for each feature.

Nan Yu argues that the “quality costs time” assumption is usually disguising a different problem: lack of conviction about what good looks like. Teams that know what they are building and why move quickly. Teams that are uncertain move slowly and then revise. The revision cost is where most time disappears.

Linear’s approach: establish taste at the company level, then trust it. The company’s design standards are visible in every shipped product; new decisions are made by reference to those standards, not by reopening the aesthetic debate.

The 10% rule

The 10% rule originates from research into user adaptation and mental model formation. Users have expectations for how software behaves — built from every product they have ever used. A new interaction that differs significantly from expectation creates friction; users must update their mental model before they can use the feature fluently.

The rule says: cap the difference at 10%. A 10% deviation is perceptible enough to register as an improvement without requiring significant mental model adjustment. More than 10% and you are effectively asking users to learn a new product.

The design challenge is not the 10% — it is choosing which 10%. This is where taste operates: identifying the dimension on which a 10% change creates the most value. For Linear, this often means optimising for speed of the core workflow (keyboard shortcuts, command palette, fast loading) rather than adding new features.

IC-first product design

The IC-first principle emerged from observing how B2B products fail. A product used daily by 10,000 individual contributors will often accumulate features requested by 10 managers who report data upward. The managers have budget authority; the ICs have usage authority. Products that optimise for the managers’ reporting needs become slower and more cluttered for the people who actually use them.

Linear’s approach is to refuse these features. If a feature’s primary user is someone who needs to export or aggregate — rather than someone doing the actual work — it is a sign the feature optimises for oversight, not for work. The practical test: would an IC with no reporting responsibilities benefit from this feature on the day they use it?

Nan Yu notes this is not anti-management; it is anti-waste. Reporting features can be built at the edge of the product (exports, integrations) without polluting the core workflow.

Emotional empathy and schlep blindness

Beyond the structural IC-first principle, Nan Yu describes a prerequisite: genuine empathy for the people doing the work. She distinguishes “cognitive empathy” (understanding what users need abstractly) from “emotional empathy” (feeling the frustration of a bad workflow in your own body).

Product teams that rely only on cognitive empathy can identify that something is broken without feeling how broken it is. Emotional empathy generates the motivation to fix the unglamorous parts — the slow load, the clunky keyboard shortcut, the obscure error message. She calls the failure to feel this motivation “schlep blindness”: not seeing the important problems because they are unpleasant to work on.

Extreme version method

When a design team is stuck — multiple competing proposals, no clear answer — Nan Yu’s technique is to push one concept to its extreme. If you are debating how much information to show on a card, design the version that shows everything. If you are debating how minimal a mode should be, design the version that shows nothing.

The extreme version almost never ships, but it reveals the essence of the concept more clearly than a moderate version does. Once you have the extreme, the question “how far should we pull back from the extreme?” is easier to answer than “what should we add to the baseline?” The extreme version also functions as a creativity unlock: it breaks the assumption that the current range of options is the complete range.

Double triangle PM model

Nan Yu’s model distinguishes two PM archetypes:

Funnel PM: responsible for the metrics at each stage of acquisition, activation, retention, referral, revenue. Their primary skill is identifying friction in the funnel, running experiments, and improving conversion. They think in percentages and cohorts.

Value PM: responsible for the product’s core experience — what makes it worth using. Their primary skill is product taste: knowing what is good and why. They think in features, interactions, and quality.

Most product organisations need both types but often hire one expecting them to do the other’s work. A funnel PM cannot replace a value PM, and vice versa. The organisations that fail to distinguish them end up with either a product that is perfectly optimised for a mediocre experience or a beautiful product that nobody knows how to grow.

Deadlines as P0

Linear treats deadlines as first-priority constraints. A deadline is not a suggestion or a target; it is a commitment. Missing a deadline is the equivalent of shipping a major bug — it is a product quality failure.

The implication: if a deadline cannot be met with current scope, scope must be cut. This forces teams to make the hard prioritisation decision before shipping rather than discovering it during the project when changing course is expensive. The discipline of treating deadlines as P0 forces the “what matters most?” question early.

”Correct amount is too much minus one”

A memorable heuristic for product scope: the correct amount to include in a release is the maximum you would call “too much,” minus one. This is not a literal instruction but a calibration device. It names the intuition that ambitious scope is almost always the right bet, except when it crosses into incoherence. The challenge is finding where “too much” starts — and then shipping just before that boundary.