Lenny's PodcastNan Yu: How Linear ships beloved B2B software at speed
Through week-one V1s shipped first to internal users then waves of beta rings; Linear refuses customization that helps managers and breaks IC workflow.
CHAPTERS
- 0:00 – 7:47
Why Linear is winning hearts: building tools people actually enjoy
Lenny opens with survey results showing a huge desire to switch from Jira to Linear, framing Linear as a rare beloved B2B product. Nan explains Linear’s origin story: removing day-to-day “speed bumps” that make builders hate their workflows and restoring a sense of fun and flow.
- •Survey insight: #1 wished-for switch is Jira → Linear
- •Linear’s founding motivation: reduce friction and “sadness” in daily work
- •Beloved B2B as proof of real product-market fit
- •Linear succeeding despite typical switching barriers in enterprise tools
- 7:47 – 9:25
Debunking the speed vs. quality trade-off: competence creates both
Nan argues the perceived trade-off comes from equating speed with sloppiness. In reality, experts move quickly because iteration volume drives quality, and fast teams create more shots on goal.
- •Speed ≠ rushing; speed comes from mastery/competence
- •High-quality software emerges from many iterations
- •Experts in any craft tend to be both fast and good (chef, contractor, chess)
- •‘Good/cheap/fast’ as an excuse used by slow organizations
- 9:25 – 13:50
What “moving fast” looks like at Linear: a working V1 in the first 10%
Nan describes a concrete operating cadence: if a project is budgeted for a month, Linear aims to have something workable in about the first week. The purpose is early hypothesis testing and avoiding late discovery of wrong assumptions.
- •Have a rough time budget; deliver a working prototype by ~10% of the timeline
- •Test a key hypothesis internally immediately
- •Avoid the ‘80% done’ trap where it’s too late to change course
- •Early working software beats perfect specs and pixel-perfect design
- 13:50 – 15:31
Iterate in widening circles: internal → beta groups → GA
Linear progressively increases exposure of new features, starting with internal use and expanding to early-access customers once data safety and basic UX thresholds are met. Engagement (or lack of it) becomes a strong signal for whether the feature hit the mark.
- •Feature rollout rings: internal first, then early access cohorts, then GA
- •Minimum bar before external release: data safety and presentable UX
- •Usage is a key validation signal—not just stated feedback
- •The approach reduces wasted effort building unused features
- 15:31 – 19:43
Avoiding enterprise bloat: saying “no” to manager-driven customization that hurts ICs
Nan outlines a clear line in the sand: reject customization/reporting requests that improve middle-manager oversight at the cost of IC workflow quality. He explains how these features create bad data anyway because ICs disengage when tools become burdensome.
- •Hard ‘no’ category: customization for reporting that worsens IC workflows
- •Misaligned incentives: managers want data; ICs are evaluated on output, not ticket hygiene
- •Bad UX leads to random/incorrect inputs → unreliable reporting
- •Core promise: don’t take steps that make builders hate their tools
- 19:43 – 23:59
Enterprise growth without selling out: solve the top needs natively, not via a laundry list
Lenny probes the fear of “turning down big deals,” and Nan argues buyers ultimately want teams to be more effective. Linear navigates enterprise by focusing on the few needs that matter most and building deep native solutions rather than broad, shallow customization.
- •Enterprise adoption is increasingly driven by brand trust (‘Linear is for us’)
- •‘No’ often means ‘not now’; follow-ups convert as orgs and needs change
- •Decompose laundry lists: identify the top 2–3 must-haves
- •Native depth beats configurable-but-shallow solutions
- 23:59 – 28:18
Anchor product debates in real people and real workflows (not personas)
For complex feature decisions, Linear ties discussions to specific known users and concrete workflows. Nan warns against elegant solutions that don’t match messy reality and introduces how they interpret feedback as a test of whether their model was wrong.
- •Use real individuals (name/email) as the reference point, not hypothetical personas
- •Reality is often ‘ugly’; elegance must map to real constraints
- •Heuristic isn’t volume-based: a small amount of feedback can reveal flawed assumptions
- •Two modes: correct mismatched assumptions (‘annealing’) or find concentrated use cases within broad demand
- 28:18 – 30:39
From custom fields to ‘Customer Requests’: finding the real job behind requests
Nan shares how repeated requests for custom fields were reframed into a better solution: customer-linked requests integrated with CRM/support systems. The result preserves IC experience while enabling reporting and context about who asked for what and why.
- •Custom fields are tempting but often create IC burden and bloat
- •Discovery revealed a major underlying need: track work by customer account
- •Automate tagging via CRM/support integrations rather than manual entry
- •Bonus: engineers get richer context (emails, true use cases) while building
- 30:39 – 34:08
Customer calls as empathy work: “feel bad in the same way customers feel bad”
Nan explains his approach to discovery: go beyond analytical ‘five whys’ to uncover the emotional driver behind a request. He uses the emotional root (fear, misalignment, embarrassment, stress) to guide what the product should prevent or enable.
- •Goal: uncover emotional valence behind feature requests
- •People rarely answer ‘How do you feel?’ directly; deeper conversation reveals it
- •Example: deadlines/dates create miscommunication pain → flexible date granularity
- •Empathy defined operationally as sharing the customer’s negative feeling
- 34:08 – 41:19
Emotional hooks as product strategy: competing on the underexplored ‘feelings’ layer
In crowded markets, Nan argues functional ‘jobs-to-be-done’ gets commoditized quickly. Linear looks for “schlep blindness” moments—recurring pain users accept as normal—and turns them into product advantage.
- •Competitive categories force differentiation beyond obvious goal-oriented solutions
- •PMs/engineers underweight ‘touchy-feely’ signals—creating opportunity
- •Schlep blindness: users normalize recurring pain until an outsider spots it
- •Example: triage management resolves ‘underwater’ chaos and ticket black holes
- 41:19 – 44:41
Backlog and conviction-building: maintain 20–30 opportunities and keep updating the model
Nan describes a backlog practice focused on understanding, not premature commitment. Opportunities remain ‘not ready’ until the team has enough shared context and clarity on what portion of a problem Linear should take on.
- •Keep a portfolio of opportunities that are continuously re-evaluated
- •Document and share evolving analysis so the team can engage and contribute
- •Example backlog item: capacity planning—many bad solutions today
- •Key nuance: decide how much of the problem to solve to avoid over-promising
- 44:41 – 48:09
Systemizing creativity: build the extreme versions to expand the solution space
Nan outlines a creativity method: deliberately push concepts to extremes (fastest, safest, most luxurious) to break hidden constraints and reveal better options. The team then learns from extremes and converges on the right trade-off.
- •Creativity challenge is often extrapolation beyond defaults
- •Ask: ‘How extreme can we take it?’ to surface unseen choices
- •The biggest risk: never seeing the right option in the first place
- •Build the extreme quickly, feel it, then converge
- 48:09 – 54:14
Demo case study: saving drafts by testing ‘fast but unsafe’ vs ‘safe but messy’
Nan demos Linear’s drafts feature and walks through how they arrived at the final UX. They tested a super-fast version (no interruption) and a super-safe version (autosave everything), then merged the best of both into a nuanced flow.
- •Extreme 1: no prompts (fast) felt unsafe—kept internal
- •Extreme 2: autosave everything (safe) created clutter (‘untitled’ trails)—rolled out and measured
- •Final solution: interrupt only for brand-new issues; autosave edits within an existing draft
- •Method: ship variants early, observe behavior, then refine
- 54:14 – 58:22
B2B tools teach you how to work: opinionated defaults as ‘embedded best practices’
Nan argues adopting B2B software is adopting a way of working, not just features. Linear aims to encode consensus best practices into defaults and automation—making ‘the worst you can do’ still reasonably competent.
- •Many B2B tools originate as internal processes turned into products
- •Buying software imports a baseline operating model into an org
- •ERP adoption as extreme example: companies conform to the tool’s best practices
- •Linear’s stance: opinionated ≠ arbitrary; it reflects patterns from high-performing teams
- 58:22 – 1:04:16
The ‘double triangle’ PM: connecting builders (eng/design) with sellers (sales/marketing)
Nan describes product management as partly a go-to-market discipline, emphasizing tight feedback loops with marketing and sales. He explains how Linear embeds product marketing deeply into product work to craft precise language that resonates with expert buyers.
- •PM–eng–design collaboration is common; PM–sales–marketing is underused
- •Expert practitioners have strong ‘BS detectors’; wording matters
- •Linear has product marketing embedded with the PM team (release notes, changelogs, messaging)
- •Double triangle model: PM sits between build-side and sell-side to align outcomes
- 1:04:16 – 1:09:15
Job hunting for PMs: discover the company’s ‘burning problem’ and act like you already work there
Nan shares a repeatable approach to interviewing: treat the company as the user and run discovery to uncover what they urgently need solved. By tailoring your narrative to that need (and asking pointed questions like current OKRs), you become a clear solution rather than one of many candidates.
- •PM hiring is problem-driven; identify the hiring manager’s real job-to-be-done
- •Shift from ‘I’m good at everything’ to ‘I solve your specific problem’
- •Tactic: ask specific operating questions (e.g., OKRs this quarter)
- •Go deeper by requesting conversations with cross-functional partners (e.g., eng manager)
- 1:09:15 – 1:14:20
Deadlines: fewer, real, and treated as P0—enabled by early shipping, not estimation
Nan argues deadlines fail when they’re treated as casual fabrications. When they matter (often for launches), make them P0, protect the team from distractions, cut scope aggressively, and rely on early working software rather than heavy estimation to preserve optionality at go/no-go time.
- •Deadlines should be rare; when used, they must outrank everything else
- •Protect focus: don’t pull engineers off a P0 deadline project
- •PM role: cut scope to ensure a shippable product exists by the deadline
- •Minimal estimation; instead ship early and use remaining time to iterate/polish
- 1:14:20 – 1:21:07
Lightning round + wrap: books, media, products, mottos, and an Everlane product-market-fit story
Nan recommends influential media (notably The Design of Everyday Things) and shares small product observations that reflect his design lens. He closes with an Everlane story where defective men’s tees were reframed into a hit women’s product, then shares where to reach him for feedback.
- •Book: The Design of Everyday Things and seeing everything as designed products
- •Favorite show: The Diplomat
- •Product observation: Sakura Micron pens marketed as a ‘Bible Study Kit’—keyword + use-case positioning
- •Motto: ‘The correct amount is too much minus one’ (test extremes, then step back)
- •Everlane story: defect salvage → cropped box-cut tee becomes a bestseller; contact via X/Twitter DMs
