Linear’s secret to building beloved B2B products | Nan Yu (Head of Product)

Episode Summary

Executive Summary: Nan Yu, Head of Product at Linear, argues that great product teams can move fast without sacrificing quality by shipping early, testing extreme versions, and learning from real users. He emphasizes protecting IC workflows over manager-friendly reporting, using emotional friction as a product signal, and keeping PM tightly connected to sales/marketing. The episode also covers hiring, deadlines, and Linear’s disciplined approach to product design and GTM.

Main Topics: Speed and quality are not a trade-off (Priority: 5/5): Nan argues that fast teams are usually more competent, not sloppier. Linear’s process is to ship a workable version in the first ~10% of the time budget so the team can validate assumptions early and iterate quickly. Protecting IC workflows from bloat (Priority: 5/5): Linear rejects feature requests that help middle managers report on work but make individual contributors’ lives worse. The company prioritizes a product that stays simple, fast, and enjoyable to use. Designing from real people and real use cases (Priority: 5/5): Instead of building for abstract personas or generic requests, the team digs into specific users, specific workflows, and concrete problems. This prevents elegant but unrealistic solutions. Using emotion as a product signal (Priority: 5/5): Nan looks for moments when users feel bad—frustration, fear, confusion, or wasted effort—and builds products that remove that emotional pain. He treats empathy as understanding the source of that bad feeling. Extreme prototyping to find the right solution (Priority: 4/5): Linear often explores the most extreme version of a product idea first—safest vs fastest, most automated vs most manual—to expand the search space and reveal the best balance through real use. PM as a bridge between builders and sellers (Priority: 4/5): Nan frames product management as part of go-to-market, not just engineering/design. PMs should help shape messaging, release notes, and customer language by working closely with sales and marketing. Hiring and deadlines as problem-solving exercises (Priority: 4/5): In interviews, candidates should act like they already work there and diagnose the hiring manager’s real job-to-be-done. Deadlines should be rare, treated as true P0s, and accompanied by aggressive scope reduction rather than heavy estimating.

Key Arguments: Speed is often a proxy for competence; strong teams iterate faster because they know what they’re doing, not because they rush. A first version should be just good enough to test key hypotheses internally and with early users, not polished to perfection. Enterprise software should not become bloated by satisfying customization requests that degrade IC productivity. Many feature requests are really attempts to solve emotional pain or social pressure (e.g., reporting to a boss), so the real problem is often different from the stated request. A PM’s job is to understand the specific person and context behind a request, then build for the real use case rather than the generic ask. The best products also teach customers a better way to work; software adoption changes behavior, not just tooling. PMs in B2B should be deeply involved in product marketing and sales conversations because they understand the customer language best. Deadlines become meaningful only when they are treated as serious and protected with scope cuts, early shipping, and minimal distractions. Creative product work improves when teams intentionally explore extreme options before settling on the balanced solution. Hiring is more effective when the candidate identifies the company’s immediate problem and positions themselves as the solution rather than as a generalist who is good at everything.

Data Points: Time budget for first usable version: ~10% of allotted time - Nan says a team should have a workable solution by the time about 10% of the planned schedule has elapsed. Beta rollout model: Internal users first, then early access customers, then broader beta audiences, then GA - Linear gradually expands feature access to validate and refine new work before general release. Custom fields request analysis: ~40% - Nan says about 40% of custom-field requests were actually about tracking customer-specific requests and reporting on them. Backlog size: 20–30 opportunities - Linear keeps a backlog of product opportunities that are not yet ready because conviction is still being built. Deadlines cadence: ~50 weeks / 12 months / 4 quarters - Nan argues there are limited chances to communicate with customers or market, so missed launch moments matter. Feature adoption pain example: 1.5 inches too short - At Everlane, a batch of men's T-shirts came in about an inch and a half too short and was repurposed into a women’s cropped tee. Product growth reference: Fast growing B2B SaaS; enterprise growth leading other segments - The host notes Linear’s strong growth and Nan says enterprise growth has been leading other segments. RCS adoption scale: 150,000+ businesses - Sponsor read for Cinch cited broad usage of its messaging API across major companies. Top tech adoption stat: 8 of the top 10 largest tech companies globally - Sponsor read for Cinch highlighted enterprise adoption among large tech companies. Integration acceleration stat: 7x faster - Sponsor read for Paragon claimed AI companies ship integrations seven times faster using its platform.

Pivotal Quotes: "there's not actually a trade-off between speed and quality" — Nan Yu: Nan’s core thesis on Linear’s operating model: speed comes from competence and iteration, not sloppiness. "My goal is to feel bad in the same way that customers feel bad" — Nan Yu: Nan explains how he digs into customer calls to uncover the emotional source of pain, not just the functional request. "The correct amount is too much minus one" — Nan Yu: A personal motto about pushing to the edge, then backing off one step to find the right level.

Implications: For product teams, Linear’s playbook suggests that clarity, user empathy, and disciplined constraint can outperform feature accumulation. The broader lesson: great B2B products win by protecting workflow quality, not by pleasing every buyer request.