Nan Yu
Head of Product at Linear
Where to hear and read about Nan Yu2 episodes and tests
Lenny's PodcastStop planning for 2027: how OpenAI builds product 90 days at a time | Tara Sesha and Nan Yu (OpenAI)
Lenny's PodcastLinear’s secret to building beloved B2B products | Nan Yu (Head of Product)Nan Yu is head of product at Linear, has also worked at Everlane and Mode, and speaks as an OpenAI product leader in a second talk. The lesson most worth taking from him is to get a rough working version out fast and to dig into the real person's feelings behind each request.
My goal is to feel bad in the same way that customers feel bad.
Linear’s secret to building beloved B2B products | Nan Yu (Head of Product)
Nan Yu: the story and the lessons
1Nan Yu's path and what shaped his taste
Nan Yu has built products in three crowded markets. He worked at Everlane (clothing), Mode (BI tools) and Linear (project management). He used the same approach of looking for emotional pain points in all three.
He says the more competitive the industry, the more the goal-based opportunities are already picked over.
He learned to see design in everyday objects. His most recommended book is The Design of Everyday Things by Don Norman, which he read for an HCI class in college.
He saw a kid rip the handle off a café door that looked pullable but was a push door. His takeaway is that every pencil and every door was designed by somebody, and bad design can be fixed.
He watched a manufacturing defect become a bestseller at Everlane. A batch of men's t-shirts came in an inch and a half too short. The team cut two more inches off and sold it as a women's cropped box tee, which sold out in a week.
He says he witnessed it and had no direct hand in it. It began white only and now comes in about 20 colors. He cites it as product market fit coming from a defect when design and marketing work together.
He won the Mode job by acting as if he already worked there. On a friend's advice, he asked what the hiring manager's OKRs were that quarter and how he could help achieve them.
His advice is to find the hiring manager's burning problem and argue you are the solution. He also suggests asking for an introduction to an engineering manager working on the same problem, which few candidates do and which earns extra positive feedback in the debrief.
2Why Nan Yu says speed and quality go together
Nan treats speed as a sign of expertise, not sloppiness. He points to chefs, programmers and chess players such as Magnus Carlsen and Hikaru, who win at speed chess as well as regular chess. Quality depends on how many iterations you get, and only speed gives you many.
He treats a PM who claims a speed versus quality trade-off as a red flag. He cites Patrick Collison calling 'good, cheap, fast, choose two' misinformation spread by the slow.
Linear wants something working after about 10% of the time. With a rough time budget, a month-long feature has something that tests a key hypothesis internally after week one. A wrong assumption shows up then, not at 80% done.
The first version is a best guess. It needs no pixel-perfect design, but betas must not corrupt data or look hideous.
Linear releases each feature to widening circles of users. A feature goes first to internal users, since the team uses Linear daily. It then goes to beta groups, then more betas, then general availability.
If nobody in a beta uses the feature, that tells the team it missed the mark. By GA, many internal and beta users have already used every feature.
3How Nan Yu keeps Linear free of bloat
Linear refuses customization that helps managers and hurts individual contributors. Required fields and dropdowns push ICs to pick random answers or skip the tool, so the reporting data ends up wrong anyway. Linear says no to these requests outright.
His argument to buyers is that the trade-off is false, because engineers are reviewed on code, not on filling in tickets. A field asking which product version a ticket ties to means a five-minute scavenger hunt every time.
He asks buyers whether all ten wishes matter equally. Buyers say no, and only the first three really matter. Linear builds those three as native features with more depth than customization can reach.
Basic scaling work like SAML and SCIM still gets built as keep-the-lights-on work. He found the pressure to add custom features lower than expected, because buyers mainly want a more effective team.
He looks for where two user groups want opposite things. A manager wants detailed reports while an IC wants fewer steps. He makes the trade-off on purpose and searches for a solution that satisfies both.
He says it is not enough to tell a team to focus on the user.
Linear turns what strong teams already do into a button. Triage Management automates a queue that strong teams ran by hand. Linear's opinions come from consensus among high-performing teams, not taste.
His buying advice follows from it: ask whether a tool's way of working is the way you want to work, not only whether it solves a problem.
Nan keeps lost enterprise deals alive because no often means not now. Linear keeps lost deals in its CRM and follows up, since budget, change management or an exec's loyalty to another tool can change. Some deals lost two years ago have since come back.
Enterprise growth now leads the other segments, which he credits to brand pull. The pitch is a large company that wants to act like a startup.
4How Nan Yu finds what customers actually need
Nan ties every feature debate to a named real person. When deciding whether to extend a feature or add a new one, he wants a person with a name, an email and a real workflow, not a hypothetical persona.
Elegant designs fail if they don't match how work happens. He says 'Reality is ugly sometimes.'
He looks for concentrated pools inside big, vague requests. Linear got requests for custom fields, and 40% were really about tracking which customer, like Walmart, asked for a feature. It built Customer Requests, which reads the sender's email from support tools and CRMs and tags requests automatically.
Nobody tags by hand, so ICs get no extra work. Open custom fields were refused because 100 of them make ICs hate the product.
On customer calls he digs until he feels the customer's pain. He keeps asking from different angles, and asks 'So what?' to reach the stakes, such as not getting promoted. Asking 'How do you feel?' directly rarely works.
One customer put a project ship date of December 30 and got blamed by marketing. That story led to target dates at any granularity, like a quarter. Sales reps on these calls wonder where the questions are going.
He builds for emotional pain that competitors haven't mined. Every PM asks about goals and jobs to be done, so he looks at where people feel bad during the workday. People often don't notice routine pain, so an outsider has to spot it.
Triage Management came from two opposite feelings with one root cause. Teams routing tickets by hand felt underwater, and teams that didn't felt out of control. The fix is a special zone for incoming issues that notifies the right people on a rotation.
5Nan Yu's method of building the extreme version
He builds extremes because the right choice is often never on the list. Most people pick among options that are all mediocre. He pictures three choices on the table, none right, and a fourth sitting in a corner nobody looked at.
The aim is to widen the search space, not to choose better among the same options. He picks one specific trait and pushes it to its most outrageous version.
Linear found its draft design by building two opposite extremes. A no-prompt version that threw away closed drafts felt unsafe, and internal users agreed. An auto-save-everything version left a paper trail of junk drafts.
The final design prompts on a new issue and silently auto-saves an existing draft. He says, 'The best solutions are always obvious in hindsight.'
He picks the trait to push by asking what the company promises. A ride service might promise a car is always available, which implies surge pricing. Or it might promise predictable prices, which means sometimes no car.
Each promise is an extreme point of view, and you decide where on that spectrum your company sits.
His rule is that the right amount is too much minus one. Pizza example: five slices was too many, so four is right.
Lenny links it to Elon Musk's rule that if you don't add back 10% of what you cut, you cut too little.
6How Nan Yu runs the backlog, deadlines and the PM role
Linear keeps 20 or 30 unready opportunities with living written analysis. Each new customer call updates the team's model of the problem. A written, up-to-date analysis lets others read it and add to it.
Capacity planning has sat in this backlog while the team learns from users who struggle with it. Conviction is less about having a solution than about how much of the problem to take on, since taking on too much means overpromising.
Nan treats product management as a go-to-market role. His 'double triangle' puts engineering and design on one side and sales and marketing on the other, with the PM connecting them. A full-time product marketer on the PM team writes changelogs and release notes, and sales tests the words in the field.
Linear sells to expert practitioners with a sensitive BS detector, so wrong terms get a stink eye. He says PMs leave the most impact on the table on the sell side and should originate the message.
He makes few deadlines and treats each one as a P0. The engineer on a deadline is pulled off nothing else, and the PM cuts scope until the go or no-go call can be a yes. The product may lack features but must be real enough to ship.
Marketing launch dates earn a deadline because the windows (about 50 weeks, 12 months or four quarters a year) don't return. Saying no is still valid, as long as it is a choice.
Linear hits deadlines by shipping early, not by estimating. A working version after 10% of the time leaves the rest for another iteration or for polish.
He calls it a hot take that Linear does almost no estimating. Taking a deadline seriously has to start on day one.
7What Nan Yu says about building AI products at OpenAI
Nan names what people can absorb as the real limit. Models can do far more than people use. He calls the pace of launches 'beyond breakneck', a 'la palooza' of features.
The agent launch broke enterprise processes and their ideas of how updates should arrive. The team's answer is to build what users need, not what they say they need.
He maps agent design to the limits of human attention. People evolved to hold only so many things in mind, and few could manage 40 direct reports. Users cope by bundling agents under a chief of staff agent, so they manage one, not seven.
Whether to use one agent identity or many then depends on details like memory, permissions and whose credentials it uses.
Nan wants computer use as the fallback that finishes the job. He says it will 100% do the job until the right hooks and MCPs exist, even if it is slow and costs more tokens.
On half-finished tasks: 'If it gets like 99% there and then it just like barfs, then you're like, well, this is actually a worse sort of like unfulfilled promise.'
He puts far more weight on onboarding and self-driving products. He says onboarding matters far more now, because capability overhang means people must quickly grasp what a product offers. Many engineers dislike working on it, yet the initial experience drives success.
He expects products to use themselves to solve the 'empty input box' problem, like self-driving that gives users a gentle on-ramp.
He calls old PM principles still true and stays reachable to users. He sees user empathy and systems thinking as the old product principles 'in disguise', now applied from scratch. He has long been a DMable PM from developer and enterprise work.
Agent feedback is subtle, such as a bad tone, so good feedback often comes only on the second or third follow-up question. That user knowledge is also a PM's value to research.
Stop planning for 2027: how OpenAI builds product 90 days at a time | Tara Sesha and Nan Yu (OpenAI)
OpenAI's product leaders explain how they build AI products when models change every few months: ship imperfect features fast, aim 2 to 3 months ahead, and finish the last mile of a task. The payoff is a practical set of rules for working with research, designing agents people can follow, and staying close to users.
Nan names what people can absorb as the real limit. Models can do far more than people use. He calls the pace of launches 'beyond breakneck', a 'la palooza' of features.
The agent launch broke enterprise processes and their ideas of how updates should arrive. The team's answer is to build what users need, not what they say they need.
He maps agent design to the limits of human attention. People evolved to hold only so many things in mind, and few could manage 40 direct reports. Users cope by bundling agents under a chief of staff agent, so they manage one, not seven.
Whether to use one agent identity or many then depends on details like memory, permissions and whose credentials it uses.
Nan wants computer use as the fallback that finishes the job. He says it will 100% do the job until the right hooks and MCPs exist, even if it is slow and costs more tokens.
On half-finished tasks: 'If it gets like 99% there and then it just like barfs, then you're like, well, this is actually a worse sort of like unfulfilled promise.'
He puts far more weight on onboarding and self-driving products. He says onboarding matters far more now, because capability overhang means people must quickly grasp what a product offers. Many engineers dislike working on it, yet the initial experience drives success.
He expects products to use themselves to solve the 'empty input box' problem, like self-driving that gives users a gentle on-ramp.
He calls old PM principles still true and stays reachable to users. He sees user empathy and systems thinking as the old product principles 'in disguise', now applied from scratch. He has long been a DMable PM from developer and enterprise work.
Agent feedback is subtle, such as a bad tone, so good feedback often comes only on the second or third follow-up question. That user knowledge is also a PM's value to research.
Linear’s secret to building beloved B2B products | Nan Yu (Head of Product)
Linear's head of product explains how the team ships fast without losing quality, says no to bloat, and digs for the emotions behind customer requests. The result is a B2B tool that Lenny's survey found was the top tool people wish they could switch to from Jira.
Nan Yu has built products in three crowded markets. He worked at Everlane (clothing), Mode (BI tools) and Linear (project management). He used the same approach of looking for emotional pain points in all three.
He says the more competitive the industry, the more the goal-based opportunities are already picked over.
He learned to see design in everyday objects. His most recommended book is The Design of Everyday Things by Don Norman, which he read for an HCI class in college.
He saw a kid rip the handle off a café door that looked pullable but was a push door. His takeaway is that every pencil and every door was designed by somebody, and bad design can be fixed.
He watched a manufacturing defect become a bestseller at Everlane. A batch of men's t-shirts came in an inch and a half too short. The team cut two more inches off and sold it as a women's cropped box tee, which sold out in a week.
He says he witnessed it and had no direct hand in it. It began white only and now comes in about 20 colors. He cites it as product market fit coming from a defect when design and marketing work together.
He won the Mode job by acting as if he already worked there. On a friend's advice, he asked what the hiring manager's OKRs were that quarter and how he could help achieve them.
His advice is to find the hiring manager's burning problem and argue you are the solution. He also suggests asking for an introduction to an engineering manager working on the same problem, which few candidates do and which earns extra positive feedback in the debrief.
Nan treats speed as a sign of expertise, not sloppiness. He points to chefs, programmers and chess players such as Magnus Carlsen and Hikaru, who win at speed chess as well as regular chess. Quality depends on how many iterations you get, and only speed gives you many.
He treats a PM who claims a speed versus quality trade-off as a red flag. He cites Patrick Collison calling 'good, cheap, fast, choose two' misinformation spread by the slow.
Linear wants something working after about 10% of the time. With a rough time budget, a month-long feature has something that tests a key hypothesis internally after week one. A wrong assumption shows up then, not at 80% done.
The first version is a best guess. It needs no pixel-perfect design, but betas must not corrupt data or look hideous.
Linear releases each feature to widening circles of users. A feature goes first to internal users, since the team uses Linear daily. It then goes to beta groups, then more betas, then general availability.
If nobody in a beta uses the feature, that tells the team it missed the mark. By GA, many internal and beta users have already used every feature.
Linear refuses customization that helps managers and hurts individual contributors. Required fields and dropdowns push ICs to pick random answers or skip the tool, so the reporting data ends up wrong anyway. Linear says no to these requests outright.
His argument to buyers is that the trade-off is false, because engineers are reviewed on code, not on filling in tickets. A field asking which product version a ticket ties to means a five-minute scavenger hunt every time.
He asks buyers whether all ten wishes matter equally. Buyers say no, and only the first three really matter. Linear builds those three as native features with more depth than customization can reach.
Basic scaling work like SAML and SCIM still gets built as keep-the-lights-on work. He found the pressure to add custom features lower than expected, because buyers mainly want a more effective team.
He looks for where two user groups want opposite things. A manager wants detailed reports while an IC wants fewer steps. He makes the trade-off on purpose and searches for a solution that satisfies both.
He says it is not enough to tell a team to focus on the user.
Linear turns what strong teams already do into a button. Triage Management automates a queue that strong teams ran by hand. Linear's opinions come from consensus among high-performing teams, not taste.
His buying advice follows from it: ask whether a tool's way of working is the way you want to work, not only whether it solves a problem.
Nan keeps lost enterprise deals alive because no often means not now. Linear keeps lost deals in its CRM and follows up, since budget, change management or an exec's loyalty to another tool can change. Some deals lost two years ago have since come back.
Enterprise growth now leads the other segments, which he credits to brand pull. The pitch is a large company that wants to act like a startup.
Nan ties every feature debate to a named real person. When deciding whether to extend a feature or add a new one, he wants a person with a name, an email and a real workflow, not a hypothetical persona.
Elegant designs fail if they don't match how work happens. He says 'Reality is ugly sometimes.'
He looks for concentrated pools inside big, vague requests. Linear got requests for custom fields, and 40% were really about tracking which customer, like Walmart, asked for a feature. It built Customer Requests, which reads the sender's email from support tools and CRMs and tags requests automatically.
Nobody tags by hand, so ICs get no extra work. Open custom fields were refused because 100 of them make ICs hate the product.
On customer calls he digs until he feels the customer's pain. He keeps asking from different angles, and asks 'So what?' to reach the stakes, such as not getting promoted. Asking 'How do you feel?' directly rarely works.
One customer put a project ship date of December 30 and got blamed by marketing. That story led to target dates at any granularity, like a quarter. Sales reps on these calls wonder where the questions are going.
He builds for emotional pain that competitors haven't mined. Every PM asks about goals and jobs to be done, so he looks at where people feel bad during the workday. People often don't notice routine pain, so an outsider has to spot it.
Triage Management came from two opposite feelings with one root cause. Teams routing tickets by hand felt underwater, and teams that didn't felt out of control. The fix is a special zone for incoming issues that notifies the right people on a rotation.
He builds extremes because the right choice is often never on the list. Most people pick among options that are all mediocre. He pictures three choices on the table, none right, and a fourth sitting in a corner nobody looked at.
The aim is to widen the search space, not to choose better among the same options. He picks one specific trait and pushes it to its most outrageous version.
Linear found its draft design by building two opposite extremes. A no-prompt version that threw away closed drafts felt unsafe, and internal users agreed. An auto-save-everything version left a paper trail of junk drafts.
The final design prompts on a new issue and silently auto-saves an existing draft. He says, 'The best solutions are always obvious in hindsight.'
He picks the trait to push by asking what the company promises. A ride service might promise a car is always available, which implies surge pricing. Or it might promise predictable prices, which means sometimes no car.
Each promise is an extreme point of view, and you decide where on that spectrum your company sits.
His rule is that the right amount is too much minus one. Pizza example: five slices was too many, so four is right.
Lenny links it to Elon Musk's rule that if you don't add back 10% of what you cut, you cut too little.
Linear keeps 20 or 30 unready opportunities with living written analysis. Each new customer call updates the team's model of the problem. A written, up-to-date analysis lets others read it and add to it.
Capacity planning has sat in this backlog while the team learns from users who struggle with it. Conviction is less about having a solution than about how much of the problem to take on, since taking on too much means overpromising.
Nan treats product management as a go-to-market role. His 'double triangle' puts engineering and design on one side and sales and marketing on the other, with the PM connecting them. A full-time product marketer on the PM team writes changelogs and release notes, and sales tests the words in the field.
Linear sells to expert practitioners with a sensitive BS detector, so wrong terms get a stink eye. He says PMs leave the most impact on the table on the sell side and should originate the message.
He makes few deadlines and treats each one as a P0. The engineer on a deadline is pulled off nothing else, and the PM cuts scope until the go or no-go call can be a yes. The product may lack features but must be real enough to ship.
Marketing launch dates earn a deadline because the windows (about 50 weeks, 12 months or four quarters a year) don't return. Saying no is still valid, as long as it is a choice.
Linear hits deadlines by shipping early, not by estimating. A working version after 10% of the time leaves the rest for another iteration or for polish.
He calls it a hot take that Linear does almost no estimating. Taking a deadline seriously has to start on day one.
Linear