$1.25 billion Unicorn. Only 2 Product Managers. The Linear Method:

1. 0:00 – 2:39

   Why AI companies pick Linear: speed, directness, and low-friction workflows

   1. AGAakash Gupta0:00

      Linear just raised their Series C at a $1.25B valuation. Nan Yu is the Head of Product at Linear. OpenAI, Perplexity, Cursor. Why are all the AI companies using Linear?

   2. NYNan Yu0:12

      When they were first getting started, the thing that mattered the absolute most to them, and, and still is today, is just speed of operations, and Linear has always been built for speed.

   3. AGAakash Gupta0:20

      A lot of it comes down to how you guys build product, this Linear Method. So how would you summarize, what's the 60-second pitch for what the Linear Method is?

   4. NYNan Yu0:29

      The core of the Linear Method is just directness. If you look at a lot of the practices that's very prevalent in the software industry, they're all strangely indirect, right? Like, things like user stories where people kind of, like, tell, you know, they have this format and they say, like, you know, the actor and the desired action, all this kind of stuff. They say it and it's just like, "Yeah, but, like, what do you actually want me to do?" "Well, I want you to, you know, when you click a button, this- it sends an email." Like, why didn't you just say that?

   5. AGAakash Gupta0:49

      I think there's this tension people feel between speed and quality.

   6. NYNan Yu0:55

      To me, that's something of a, it's almost of, like, a false dichotomy. I think OKRs are a tool that makes sense in certain circumstances, but I think they're largely overused. A lot of times it's like, "Deliver this feature." That's their OKR. It's like, that's not an OKR. That's somebody shoehorning in the direct thing that they want to say. You don't want to be in this weird process of, like, sprinting and being exhausted, and sprinting and being exhausted again so that when new information comes, you're just, you're not ready to handle it.

   7. AGAakash Gupta1:20

      Really quickly, I think a crazy stat is that more than 50% of you listening are not subscribed. If you can subscribe on YouTube, follow on Apple or Spotify Podcasts, my commitment to you is that we'll continue to make this content better and better. And now on to today's episode. Nan, welcome to the podcast.

   8. NYNan Yu1:41

      Uh, great to be here.

   9. AGAakash Gupta1:44

      One of the craziest things that I've seen in your guys' rise, and I have to admit, I've been following you since way before you were a unicorn, is how many of the AI companies are using you? OpenAI, Perplexity, Cursor. Why are all the O- AI companies using Linear?

   10. NYNan Yu2:02

       I, I, I think, like, you know, when they were first getting started, the thing that mattered the absolute most to them, and, and still is today, uh, is, is just speed of operations. And, you know, Linear has always been built for speed. Um, speed in every sense of the word. You know, you know, people kind of, on the surface level, just all the interactions are very quick, but they're also very direct. So when you're, when you're taking any kind of action inside of Linear, things are very obvious in terms of what to do. You don't have to kind of sit there and figure the system out. You just, you know, kind of get in and out of it quickly, and then get back to the thing that you're actually focused on, right? For them, it's, it's actually building their companies.

2. 2:39 – 3:53

   A new generation tool stack: building for modern developer muscle memory

   1. AGAakash Gupta2:39

      I think that part of it also is that Linear seems to be part of the new tool stack. Like, the best new companies are using Linear versus companies that were started, like, 10 years ago. There was a different tool stack in place. It seems like you guys are part of the new generation.

   2. NYNan Yu2:58

      Uh, yeah. I mean, I, I think that, you know, the, every, every so often, you know, you kind of step back and take a look at your tooling and really, like, the, the values that people have in terms of how they want to get their work done and, and what they prioritize have, you know, kind of changed very dramatically. Um, you know, something that we, uh, kind of really recognize is that people, you know, have, have been doing this software development thing for a while, right? If you think of, like, the entire history of the, of the, of the discipline, it's still very young, but, you know, we- we're at a point where, um, a lot of the, the core skills are kind of baked into the muscle memory of people's workflows.

   3. AGAakash Gupta3:37

      Mm-hmm.

   4. NYNan Yu3:38

      So, you know, we can build new tools assuming that baseline, right? There's, like, people are not clueless anymore. They're ready, they're ready to go. Everyone knows how to use Git. You know, we're, we're kind of ready to, uh, to start from there as a, as a starting point. So I think Linear, like, comes, you know, with a lot of those assumptions baked in.

3. 3:53 – 6:32

   What Linear actually is: project management primitives optimized for developers

   1. AGAakash Gupta3:53

      If you had to summarize, like, Linear's functionality, how would you summarize that?

   2. NYNan Yu3:59

      Um, you know, fundamentally, we're a project management tool for, uh, software development teams. Um, a lot of the primitives inside of Linear, uh, you know, are, are really optimized for that, right? Like, uh, things like every single issue come with, like, a, like, a, you know, a preset branch name so you don't have to, like, stop in the middle of your process and make sure you're, like, following all the naming conventions and all that kind of stuff, right? So, like, a lot of those, uh, little rough edges that people run into, you know, and are very accustomed to, honestly, like, every day, you know, we try to sand those off and, and kind of make the process even smoother for you.

   3. AGAakash Gupta4:30

      AI evals are one of the most important skills for PMs, and I know you know they matter. The question is, are you doing them right? Most teams are winging it with basic metrics and hoping for the best. Meanwhile, the teams that actually ship reliable AI, they've cracked the code on systematic evaluation. Today's episode is brought to you by the AI Evals for Engineers and PMs course by Hamel Hussein and Shreya Shankar. This live Maven course will teach you the battle-tested frameworks from Hamel and Shreya, who are the engineers behind GitHub Copilot's evaluation system and 25-plus production AI implementations. Four weeks, live instruction. Next cohort starts July 21st. Start shipping AI that actually works. Enroll at maven.com with my code AG-PRODUCT-GROWTH for over $800 off. That's A-G-P-R-O-D-U-C-T-G-R-O-W-T-H. Today's episode is brought to you by Vanta. As a founder, you're moving fast towards product market fit, your next round, or your first big enterprise deal. But with AI accelerating how quickly startups build and ship, security expectations are higher earlier than ever. Getting security and compliance right can unlock growth or stall it if you wait too long. With deep integrations and automated workflows built for fast-moving teams, Vanta gets you audit ready fast and keeps you secure with continuous monitoring as your models, infra, and customers evolve.Fast-growing startups like LangChain, Writer, and Cursor trusted Vanta to build a scalable foundation from the start. So go to vanta.com/aakash, that's V-A-N-T-A.com/A-A-K-A-S-H to save $1,000 and join over 10,000 ambitious companies already scaling with Vanta. So it's, it's a red ocean market, right? That's, that's a space [laughs] that we all have tried tons of tools in, but you guys are winning. And I think

4. 6:32 – 7:55

   The Linear Method in one idea: “directness” over indirect process theater

   1. AGAakash Gupta6:32

      a lot of it comes down to how you guys build product, this Linear method. So how would you summarize, what's the 60-second pitch for what the Linear method is?

   2. NYNan Yu6:42

      Yeah. I, I, I think, you know, for, for us, like, the Linear method is, it's not just how we build products, it's how we help our users and our customers build products. So it's a, it's a little bit, you know, kind of self-referential and, and meant that way. But the, the core of the Linear method is, uh, is just directness, right? If you, if you look at a lot of the practices, um, that, uh, you know, have been very prevalent in the software industry, they're, they're all strangely indirect, right? Like, things like user stories where people kind of, like, tell, you know, they have this format and they say, like, you know, the actor and the desired action, all this kind of stuff. They say it and it's just like, "Yeah, yeah, but, like, what do you actually want me to do?" "Well, I want you to, you know, when you click a button, this, it sends an email." It's like, "Why didn't you just say that?" "Well, you know, because all this other stuff." And I, I think that that scaffolding that, you know, people, you know, ha- have, like, traditionally done, it's, it's been there because the business stakeholders didn't understand how software works or people are just unfamiliar with how computers work and things like that. Like, like I said before, we are at a, a moment where, like, we can rebase, right? In a universe where everyone's online by default, like, the internet is, like, the main place people hang out. Like, people know how computers work. So if that's the case, then what are the, what are the new assumptions that we get to make?

5. 7:55 – 9:02

   Staying small on purpose: hiring fewer people and valuing efficiency

   1. AGAakash Gupta7:55

      And you obviously aren't new to product either. You were a CTO at Everlane. You were VP at Mode. What struck you as you've spent the last couple years at Linear as different about how you guys build product?

   2. NYNan Yu8:10

      I, I, I think, you know, like, if you look at the, the, the newer wave of companies, there is this, um, this desire to keep the company as small as possible, and I think that Linear is definitely, you know, like, an example of that, right? We, you know, we -- The question we always ask is, like, okay, like, here's what we need to do. How few people can we hire in order to do this effectively? And, and I, I think that that's, you know, partly, you know, uh, a function of, like, the funding environment, uh, that we grew up in and, and, and, and the sort of, uh, new tools that are available to us. But I think a lot of ti- you know, the biggest difference that I've seen, right, between previous, uh, you know, kind of eras that I've worked in and, and now is, um, like, no, no one brags about how big their company is anymore, right? It's like, it's kind of the opposite.

6. 9:02 – 10:46

   Principles in practice: meaningful direction, momentum, and sustainable pace

   1. AGAakash Gupta9:02

      So I wanna pull up the Linear Method website because a lot of people have actually pointed me to this website when I ask them, "Oh, how are you guys building things?" And they say, "We keep coming back to this website." It's this beautifully designed page, right? So if I go into these principles and practices here, can you talk us through these a little bit? How did you guys come to these principles, and what do they mean to you?

   2. NYNan Yu9:24

      Yeah. I, I, I think, you know, the, the, the overriding things that these, um, these principles try to get at is be really, really direct and, uh, and be very fast, right? You know, when we talk about meaningful direction, being purpose-built, these are ways to directly solve people's problems, okay? You're not, you're not building for yourself, you're building for somebody else. You're solving real problems for real people. And, uh, and then creating momentum, right? It's, it's like, how do you, how do you get to, you know, h- how do you maintain enough flexibility but also keep, uh, enough of a pace to, you know, react to things that you learn in the wild, right? If your users hate a feature, if they really love something, you're gonna, you're gonna take that information, you're gonna feed it back. And the only way to do it effectively is to, you know, have some kind of baseline velocity, right? Have momentum so that you, you know, you're ready to, to react to it. But you don't wanna be, you know, in this weird process of, like, sprinting and being exhausted and sprinting and being exhausted again so that, you know, when new information comes, you're just, you're not ready to handle it. You're just, like, exhausted from the previous sprint and you're not ready to, to go. So, like, that's what, you know, we really try to, uh, you know, try to, try to embrace, right? Be direct and also kind of keep, uh, keep the momentum going so that you, you know, you're ready to react to the wild.

7. 10:46 – 12:00

   Speed vs quality is a false tradeoff: fix upstream so you don’t need hacks

   1. AGAakash Gupta10:46

      I think there's this tension people feel between speed and quality. How do you guys negotiate that tension?

   2. NYNan Yu10:55

      [laughs] Um, I, you know, I, I, I think, like, to me, that's something of a, it's almost of, like, a false dichotomy, right? You know, like, tho- those are very overloaded words, and I think what, when people say that there's a trade-off between speed and quality, what they, what they're really trying to say is, uh, they don't want people to, um, they don't want people to cut corners, right? And they're like, "Don't take shortcuts. Don't put in hacks. Don't do those kinds of things." Um, but I think for, for software especially, if you have a high-quality code base and, you know, really strong abstractions and good concepts in there, uh, you don't really feel a need to put in hacks. And I, and I, I think that that's, that's, that's the sort of conundrum that you're, you're dealing with, that if you find yourself in a situation in which it's, it's, you know, you, you're tempted to take these kinds of shortcuts, there's probably something wrong upstream about the quality of the, the software to begin with that kinda put you in that situation. So, you know, what we try to do is, like, kind of think through these things and not get ourselves into a point where we're, where we actually have that kind of temptation.

8. 12:00 – 13:18

   Saying no to busywork: decisive, falsifiable bets instead of endless analysis

   1. AGAakash Gupta12:00

      One of the most powerful principles I think you guys have here is say no to busywork. How does that-- How do you implement that day to day?

   2. NYNan Yu12:09

      I, I think, y- you know, a, a lot of busy work is a result of indecision, and it's a result of like, uh, like lack, like a... Once again, like lack of clarity, lack of directness. So, you know, if you think about busywork, it's like, "What do you want to do?" "Well, we're gonna collect a bunch of data. We're gonna run a bunch of AB tests. We're gonna do all this stuff." And usually what that reflects is there's, there's some lack of clarity in the first place for, you know, what you were trying to do. Because, you know, like a lot of times, if you, if you think about what's the, what's the best way to understand the world is to like have some mental model of it and then act really aggressively in a way that's very falsifiable, right? If the w- if the w- if the world does not w- operate how you think, it will tell you very quickly, right, and very loudly. And if you're able to do that, then you don't have to waffle. You don't have to do a bunch of make work and, and do a bunch of analysis or whatever it is. You can just build the thing and then see how the world reacts, and if it reacts poorly, then you can change your mind. You've learned something.

9. 13:18 – 16:27

   Roadmaps without rigidity: intent, fast updates, and planning only a few quarters out

   1. AGAakash Gupta13:18

      One of the things that I heard listening to these principles, and I think I had a misconception of prior to this interview, was around roadmaps. What's your guys' take on roadmaps?

   2. NYNan Yu13:29

      I, I think, you know, ro- roadmaps generally are useful tools, right? They, they... They're an expression of, of intent, right? And they help like align a lot of people who are, you know, uh, who otherwise, you know, they have... Everyone's got their own idea of, of, you know, what the, what the current consensus is and, and where we're going. So I think as a, as a, as a tool, you know, very useful. Um, I think, you know, the, the one aspect of roadmaps is you kind of have to be ready to change them at a moment's notice, right? 'Cause it's an expression of intent, and your intent is gonna be completely a function of like what your latest information is and what your best information is. So if you get a bunch of new information and somehow your roadmap stays the same because that's, I don't know, some- someone's idea of what it... of, of what ought to be, I think that that's, that's where the problems start coming, coming around, right? Like, you can't treat the roadmap as, as, you know, somehow it's blessed and it's sacred and you can't touch it. You know, you h- you have to, you have to assume that it's, it's just the, the reflection of your best knowledge at the moment.

   3. AGAakash Gupta14:29

      What type of roadmaps are you creating then? Are you mainly focused on the short term, like this quarter or the next couple work cycles? How granular are you getting?

   4. NYNan Yu14:41

      I, I think we, you know, we plan for maybe three quarters out, like at all, and then, um, and then, you know, with, with dramatically less certainty as it, as it gets further out.

   5. AGAakash Gupta14:52

      Today's episode is brought to you by the AI PM Certification on Maven. Run by Miqdad Jaffer, who is a product leader at OpenAI, this is not your typical course. It's eight weeks of live cohort-based learning with a leader at one of the top companies in tech. OpenAI just doesn't stop shipping, and this is your chance to learn how. Run along with product faculty and Mo Ali, the course has a 4.9 rating with 133 reviews. Former students come from companies like OpenAI, Shopify, Stripe, Google, and Meta. The best part, your company can probably cover the cost. So if you want to get $500 off, use my code AAKASH25 and head to maven.com/product-faculty. That's M-A-V-E-N.com/P-R-O-D-U-C-T-F-A-C-U-L-T-Y. Today's episode is brought to you by Maven. The problem with most courses online, like Udemy, is there's no live component, and the instructors aren't experts in their fields, they're professors. At Maven, you get direct live access to experts and operators from the world's best tech companies. You can't get that access anywhere else, in any university, and you usually can't find them on YouTube either. I featured so many of Maven's experts in the newsletter and podcast for that reason. To help you out, I've put together a collection of courses I recommend at maven.com/x/akash. This includes courses like AI Prototyping for PMs, Product Sense for PMs, and getting an AI PM certification. Visit it now at M-A-V-E-N.com/x/A-A-K-A-S-H.

10. 16:27 – 18:59

    Always-on planning and an escalated idea backlog: discovery never “starts from zero”

    1. AGAakash Gupta16:27

       And what does that planning process look like? You know, your average company, they're taking, you know, maybe like a month of time where everybody's all hands on decks on this large planning exercise. How do you guys run it internally?

    2. NYNan Yu16:39

       I, [sighs] I, I've, I've always been, I've always been puzzled by those like very large planning exercises because it's... it almost assumes that you're kind of starting from zero knowledge, um, you know, at, at, you know, whenever that happens. And I think for, for us, we're, we're constantly thinking of these things, right? So when, when we think about like, you know, we have our hands on some stuff or we're developing it and we're like, you know, really learning a lot and prototyping, putting stuff in front of customers. And then for the stuff that's further out, we have an idea of what our priorities are, and we're doing whatever we can to like learn more about, you know, those ideas and to sort of like, you know, ma- matriculate our, our, our thoughts around it, our point of view, um, our mental model of how the world works, you know, with relation to those ideas. And by the time that like the next quarter rolls around and we're ready to kind of move on to the next set of things, you know, like we've already done a lot of the thinking and a lot of the planning. I think w- if you, if you put that off until like the start of the quarter or, or the half or something like that, you're, you're really putting yourself at a disadvantage because like you can do all the intense research in the world, but like doing it even in a, in a, over a month, it's just, it's just not enough time to hit all of those things at the right amount of bandwidth.

    3. AGAakash Gupta17:47

       Like an always-on planning, sort of always-on discovery process. Is there any particular rituals or ways of communicating your learnings in the always-on process that you guys use?

    4. NYNan Yu18:02

       We, uh, [clears throat] so we, we have like a sort of, you know, I, I guess you'd call it like, like a backlog, right, of, of ideas that we've accepted. Like, we think that this is a problem that's worth solving.And now it's up to us to, to develop some points of view, right, on how to solve this problem. So we have maybe like, I don't... I'm, I'm gonna guess like 30 or 40 of these areas where we're like, look, we have some, you know, developed point of view on this. Um, it might not be fully mature. You know, we might not f- we might, we might not feel good about it yet. Um, but if any of... If, if anything on that list comes up in a conversation with a customer, that generates a conversation with the product team, right? So if I'm a, you know, like in customer success or sales or, or, or support or something like that, a customer asks about a thing and it's on that list, like, like their job is to escalate it into the product organization so that we can like dive deeper and try to learn something from it.

11. 18:59 – 24:24

    OKRs are overused: use them for high-leverage, measurable orgs—not IC theater

    1. AGAakash Gupta18:59

       Makes sense. So one of the things people tend to do to operationalize these quarterly plans is build OKRs. What is your guys' take on OKRs?

    2. NYNan Yu19:10

       [laughs] Uh, I, I think, I think OKRs are a tool that, that makes sense in certain circumstances, but I think they're largely overused. And, you know, if you, if you ask like OKR proponents like, "Hey, who should use OKRs?" They're gonna say something like, "Well, everybody. Every startup should do it. Every major comp- every big company should do it." And I, I don't think that's the case, right? And, and, and it k- gets back to this, um, this idea of like directness. OKRs are a very indirect way of aligning your team, right? You can... You, you, you look at it... I mean, like the, the, the official way you're supposed to do it is you're supposed to look at a number and you're gonna have this very huge error bar on trying to hit that number. It's supposed to be a stretch goal, all this kind of stuff. And, uh, and this, this, this is... It, it, it's good if you have just like an absolute ton of different divisions and departments and that kind of stuff, and you're okay with like duplicate work and people stomping on each other, because that's gonna happen anyway, right? And you're like, "Look, at least they're aligned on pointing at this number and trying to achieve that, you know, kind of financial outcome more or less, like for the company." And I think that when you're, when you're not at massive scale, that you can say things [laughs] that are much, much more direct than that. And this, this shows up all the time. Uh, you know, we, we interview a lot of customers and, and, you know, we, we ask them about their planning process and we're like, "Hey, look, can you show us your OKRs? Like, what are your OKRs this quarter?" And for dev teams, a lot of times it's like, "Deliver this feature." That's their OKR. It's like, that's not an OKR. You... Like, that's somebody shoehorning in the direct thing that they wanna say, which is just like, "Ship the product, ship the feature. Here's the five features that really matter to our customers 'cause we've been talking... Our sales team's been talking to them and it's, it's just clearly obvious, so do it." And they, and they, they can't contort themselves into making an OKR because that's the wrong tool, right, to like, to use at that level of, uh, granularity.

    3. AGAakash Gupta20:56

       Is there... If you had to take the opposite side, when should teams use OKRs?

    4. NYNan Yu21:03

       I, I, I think that, uh, there are certain very high level, um, you know, managers for which OKRs are probably more appropriate, where they are, they are really, really responsible and they have a lot of budget in order to achieve a particular, you know, fiscal outcome, right? Whether that's like a growth team, right, where the, again, their goals are largely numeric to begin with. Finance team, um, you know, marketing, those kinds of teams, where it's, it's a, it's inherently a very measurable, you know, kind of outcome they're trying to achieve in the first place. And that, you know, they, they have a lot of flexibility in terms of how to deploy their organization and their budget in order to achieve it. I think in those circumstances, you probably don't wanna trickle it down as much as people typically do. They try to like trickle down all the way to like individual contributors and it's just like, come on, guys. Like, like this one marketing analyst is not gonna be able to affect anything. They, again, their OKRs look like, "Deliver these reports." It's like, that's just their, that's just their job. You're just, you're just describing their job. Like don't... 'Cause I, you know, you know, honestly, where OKRs lose a lot of credibility is when people try to shoehorn it like that, and then everyone's day-to-day experience is like, "Well, I'm just..." Like, "We're pretending here, guys. Like, what are we even doing?" So it's better to like use them at the level of, of, uh, of elevation, right, and, you know, for the right purposes and, and then they're very useful, and not try to like kind of force it down, you know, everyone's throats and, and, and try to, you know, get it all the way cascaded down to like the most granular parts of your company.

    5. AGAakash Gupta22:35

       Yeah. That really resonates with a recent conversation I had on the podcast with Anthony Maggio, who is VP of product at Airtable, and he talked about how he basically keeps the output metrics for like his senior directors who lead specific product areas 'cause they actually have the capacity to impact that. But individual [laughs] PMs, I think trying to shoehorn that in, that's when you really get into this performance play acting OKR symptom.

    6. NYNan Yu23:00

       Yeah. Yeah. And it, it generates really weird outcomes too because if, you know, if a PM thinks that like they have to hit this OKR, this number, they're gonna... They don't have very much leeway to impact much outside of that, so they're just gonna probably even overfit on that, right? Maybe to the detriment of the, uh, the organization.

    7. AGAakash Gupta23:16

       Exactly. Talk to me a little bit more about that. I think that OKRs can be a little bit the death of craft.

    8. NYNan Yu23:23

       [laughs] Yeah. I, I, I think it, it's just, you know... It, it's, it's somebody, um, deciding to, to kind of reset your incentives, right? They're coming in, they're dictating what your incentives are. And again, for, for some roles at some levels of elevation, that's a very natural fit and it makes, you know... You, you were already thinking about your work along those lines, or you should have been. And I think for, you know, for the, for the roles where it's, you know... How are you gonna give a designer an OKR that really makes sense to them, right? They're trying to make something beautiful, they're trying to make something usable and, you know, you could, you could try to contort yourself and make some kind of usability metrics and that kind of stuff, but this is like, that's not... They're gonna end up spending a lot of time not doing, you know, the thing that you hired them to do, and I think that that's, that's, that's ultimately kind of the, the problem is that you, you take their incentives and you, and you kind of pull it away from their core competencies into, into this, you know, very like financialized, normalized kind of way to look at the world.

12. 24:24 – 25:53

    Goals for craft roles: points of view, falsifiability, and long-run hit rate

    1. AGAakash Gupta24:24

       So what is the better way to set up incentives for IC designers and PMs? How do you guys give them goals to go after?

    2. NYNan Yu24:33

       I, I think for, for us, for designers and PMs, right? Like, the most important thing that we look for is have you established, like, a point of view and a story that makes sense to customers? And it's a v- it's a very kind of like, you know, Boolean type of outcome. Like, is this... Like, is there a strong point of view here that's falsifiable, you know, from, from kind of like user response? And if you're able to do that, right, then we can, you know, we can get into, like, okay, are you able to generate, like, a wide variety of these things, you know? Or, you know, can, you know, did we explore widely? Did we figure out, um, you know, our, our... How... Like, what's our hit rate on this, right? Are, you know, are, are you consistently, you know, landing stuff? That's, that's fine, right? Those are, those are, like, the, the sort of, you know, in the long run, you kind of evaluate these things. But, like, in the sort of, you know, quarterly, monthly kind of basis in terms of like what you're thinking about, it's are we, are we pursuing a strong point of view about the world? Or if we're not, are we very clear about what information that we need to, like, go gather in order to establish that point of view? And then you're back at square one, which is like, okay, now how are you gonna be, like, posture yourself in such a way that the world is gonna tell you that very, very aggressively and very quickly.

13. 25:53 – 30:46

    Craft and quality controls: ‘roasts,’ internal dogfooding, and incremental rollout

    1. AGAakash Gupta25:53

       So it sounds like you guys have a pretty high bar for what you build. It seems like you're trying to really encourage a lot of conviction around the user story for folks. Is it fair to say that you guys spend a lot of time making sure that things clear a high bar?

    2. NYNan Yu26:10

       Uh, yeah, we do. We have a lot of internal processes, right, to, um, to help, you know, make sure that the quality level remains high so that we're kind of covering a lot of different angles when it comes to this. But i- importantly, we're leaving a lot of the, um, uh, you know, discretion to, uh, the, the contributors that are building the thing. So we have a process, uh, that we call roasts, where, hey, we have a feature, it's ready to go out, and we literally have the entire team sit down for, like, an hour and just, like, try to break it in every single way they can.

    3. AGAakash Gupta26:42

       Wow.

    4. NYNan Yu26:42

       Right? And, and kind of give feedback about, like, you know, kind of bugs and technical issues, but also usability, you know, like opinions, right? And it's like, and it always ends up generating, like, an absolutely enormous document of feedback from the team, no matter how small the feature is, no matter how well-baked we think it is. And, you know, we don't expect them... We don't expect the team to, like, address every single thing that's mentioned, right? We expect them to sort of, like, read through it to, you know, to help fill in their blind spots. Like, "Oh, I didn't... I've never seen it that way. Okay, if I see it that way, then how do I... How should I think about this? Like, you know, should we, should we make this change?" Um, and then make, you know, kind of well-informed, balanced decisions, right, based on, uh, based on that feedback, including one which is like, "No, that's not our point of view. Our point of view is this other thing, so this is not, like, a, a concern for us." Like, and it's, it... That's a perfectly fine response to, you know, a piece of feedback from, you know, from me, from, from, from anyone at the company.

    5. AGAakash Gupta27:38

       Have you ever taken a feature to 90% like that and decided not to launch it?

    6. NYNan Yu27:43

       It, it usually doesn't get to that stage and, and it gets pulled back. Um, we've definitely delayed stuff where we're like, "Look, w- I think we've uncovered a, a blocking issue that we gotta resolve first." Um, what we, what we actually try to do is, is kind of fail super early for those circumstances where you're like, "Look, the entire theory of, like, this feature or this idea is, like, wrong." Um, we, you know, we, we have a, a sort of incremental rollout system, and the first increment is, is internal testing where we produce, like, the smallest version of the feature we can to just use internally in our day-to-day workflow. So by the time it hits, like, the first beta customer or whatever, we've been using it for months. And, uh, so, like, when, when things get, you know, really f- kind of U-turned or, or, or thwarted, it's, like, it's during that first leg where things, like, really, uh, you know, really get reconsidered.

    7. AGAakash Gupta28:35

       Can you give us an example maybe of how you guys had, like, a grander vision, but then you built a smallest version that you could start testing internally pretty quickly?

    8. NYNan Yu28:46

       Yeah. Actually, let me, let me think. Uh, we, we had... We've had, like, very recent examples of this. Um, oh, okay. Uh, so we, we, we have a feature that we're building right now, um, which, uh, you know, it was... It's designed to, you know, when you, when you dispatch an issue to an agent, um, you know, again, like the thing we talked about earlier, which is like the responsibility of that dispatch is still on whoever, whoever assigned the agent, right? It's like, I can't be like, "Oh, I assigned it to, to Devin, and now it's Devin's problem," right? Like, Devin gets performance managed against this. No, no, no. It's like, like, I'm the engineer. This is still my responsibility even though Devin's helping me out in, in building this. Um, so that, that sort of initial model that we had about, like, just assigning it to the, to the agent user, it probably wasn't enough, right? It's more of like a collaboration or like, like a pairing kind of relationship. So, you know, we're implementing, you know, the UI and the, and the reporting, all that kind of stuff to, to understand, like, okay, even though Devin worked on this, right, who, who were they pairing with that we can go to to actually hold responsibility for the output? And the original vision for this was a lot bigger. The original vision for this was like, "Oh, man, we could dispatch this to, like, QA, and there's all these different roles that you can play. You can, like, you can, like, collaborate with, you know, pair program with other human engineers and, and, and designers and things like that." And we tried to make a whole system work, and we realized that like, "Look, guys, we... Let's solve a smaller problem. Let's just solve this, like, agents... You know, robots are not actually responsible for anything, so we have to, like, have a human on the other end. Let's solve that problem, and then we can worry about the sort of other, these other kind of collaboration modes later."

    9. AGAakash Gupta30:22

       So I think that's valuable to hear for people. Even you guys don't always get the initial scoping right. You started to go down the path a little bit of a bigger feature, but thenYou have that culture in place, going back to the Linear Method of thinking about, oh, what is the smallest feature? And so you guys kinda pulled yourselves back into, let's build this smaller solution to this smaller problem first.

    10. NYNan Yu30:45

        Yeah.

14. 30:46 – 32:33

    Shipping without ‘move fast and break things’: scope shrinking as the momentum engine

    1. AGAakash Gupta30:46

       Love that. Now, what we've been describing here, this almost feels like a little bit of a long, drawn-out process, or it can, especially if you're from one of those cultures where, you know, sales is used to banging on the table, "Hey, we need this feature. Where, why isn't it here one month later?" The CEO's knocking on your door six weeks later. How do you, how do you negotiate the pull towards, you know, move fast and break things that you're hearing from executives and Mark Zuckerberg and others to this approach of quality?

    2. NYNan Yu31:19

       I, I think, you know, I, I, I don't know if like move fast and, and break things is a little bit outdated. That's why I think even Facebook doesn't, doesn't use that, that second bit. Um, but I, I think, you know, moving fast is, is real, right? And I think, you know, one of the Linear Method, uh, concepts is, is, you know, keep momentum. And the, the way you keep momentum is you are constantly, you know, moving in a direction in a way that's like steady and that's like predictable, and a big part of that, right, is shrinking down the scope. So this, you know, the, the things that we talked about, about like, hey, look, if the scope was too big, like what's the smallest subproblem that you can solve? And if, if you are able to solve that subproblem really, really well, then you can always expand the scope afterward, and you kind of incrementally, uh, you know, expand the, the scope and, and, and kinda keep momentum as you, as you're doing it. So that's, that's our, you know... It, it's like, honestly, it's our one weird trick, right? And like I, I promise you it's not more complicated than that, which is just shrink the scope as aggressively as you can so that you can ship it quickly with high quality at the same time. And then as you, you know, understand more about the world, you can steer it in a way that's, you know, that's closer to what reality is telling you.

15. 32:33 – 34:07

    Building in public (carefully): changelogs as accountability, marketing, and documentation

    1. AGAakash Gupta32:33

       So I think we covered, you know, the essence of some of the key elements of the Linear Method. One we haven't quite talked about is build in public. How do you guys do that?

    2. NYNan Yu32:42

       Uh, yeah, we, we have a, a very, um, consistent changelog that we put out into the world. And I think, you know, uh, one, one of the things that we, we do to build in public, um, that, you know, we've been doing since the beginning of the company's inception and, uh, it's really become a ritual for us, is releasing, uh, a changelog every two to three weeks. And, you know, for us, it's like it's a way to keep ourselves honest, right? If we ever come up with, uh, to a week and we're like, "Is there anything to put on changelog? Is there not? Okay, what did we do wrong?" You know, it, it, it helps, it helps, you know, us, uh, be accountable to ourselves. Are, are we kind of consistently keeping our momentum? Um, it's also a, a really great way of looking back, right, to sort of see the, the story of how Linear's evolved, and it kind of naturally produces this like kind of documentation trail of how we got to the place, uh, that we got to. Um, and every single time, you know, we have a, we have a changelog out there, it's, it's an artifact for our customers to, uh, to share with each other, right? If there's a feature that they were really, um, that they've been waiting for or that they find especially useful, it's, it's a reference that's generally fairly small, right, 'cause every changelog is incremental. Um, so that they don't have to like send people to like an enormous documentation repository or stuff like that. It's like, "Hey, look at this changelog that's what Linear just released." So it, it serves a lot of different purposes, and we f- we found it to be very, uh, very useful for those, for those reasons.

16. 34:07 – 38:05

    Public roadmaps and enterprise asks: avoid anchoring, sell outcomes, ask more questions

    1. AGAakash Gupta34:07

       What's your take on public roadmaps?

    2. NYNan Yu34:10

       I think that they are, um, they are a little bit, uh, dangerous in a lot of circumstances if you... You know, the thing we talk about roadmaps, which is like, look, you have to be ready for reality to tell you that your roadmap is wrong. And, uh, so when you put a, put out a public roadmap, there's a lot of, um, there's a lot of kind of, uh, it has an anchoring effect, right? It's like, well, I put out this thing, I promised it to these people who are... You know, the people who are looking at your public roadmap are probably gonna be like your loudest customers. They're not necessarily your most important ones or the ones that you should be listening to the most, but they're gonna be very loud. And, uh, so they, they're, it just ends up being like a lot of social pressure to kind of like stick to it, and, um, you know, it, it, it's, it, it kind of makes the incentives a little bit, uh, like a little bit messed up in, in, in that way. So if you're, you know, if you're gonna make a public roadmap and you, you have a posture that you're ready to kind of like change it at a moment's notice, then, you know, that's, uh, you know, feel free to do so. Um, or if you're, you know, if you actually have a lot of certainty for what your roadmap's gonna be because it's a bunch of table stakes features or something like that that you know you're gonna have to do, um, I think that's an okay situation to be in as well. There, there's a lot of different like shades of gray for this too. You know, like our, um, our sales team, for example, with our most important customers, they share, you know, like some parts of our roadmap to make sure that like we're aligned with how they're trying to deploy Linear at their companies and how they wanna grow. So there's a bit of that, you know, give and take, but sort of like a, a full public roadmap that's like on the internet and open to everybody is, uh, it's... You, you have to be a little bit careful because it could really screw up your incentives.

    3. AGAakash Gupta35:46

       And as a head of product, I know I was often called into those sales calls to talk to the roadmap, to preview it, especially with those big accounts or with big existing customers or churn risk customers. How do you handle those conversations?

    4. NYNan Yu36:01

       I, I, I think, you know, you, with, with a lot of, uh, what's the, what's the word? Uh, with, with a lot of care, right? And, and, and, and it's... For those very, very specific moments, like a lot of it is, is like trying to understand, you know, what it is that the counterparty wants to know. You know, like n- no customer has ever churned because of the lack of a single feature. That's never happened, right? And I, I know it can seem in those circumstances that they're, they're banging their fist on the table and, and, and this is the thing that's gonna make or break the deal, but it's, it's, it's extremely rare that that's the case. And usually, there's some underlying goal that they ha- that the stakeholder is trying to accomplish, or their company is trying to accomplish or something like that. And as long as you help them, you know, in every way that you can, right?Partly it's about the roadmap, partly it's about, you know, educating them on how to best use the product or, you know, how to use a different product in conjunction with yours or something like that, right? There's a lot of, like, customer success kind of stuff, uh, that you need to do in those moments and, you know, it typically turns out pretty okay.

    5. AGAakash Gupta36:58

       That's how I like to approach it as well, is like more try to get into understanding, almost asking a lot of questions even as a product leader, even if they've already told the sales leader, again, in the conversation with you so that you can go a little bit deeper then and figure out like what, what is the problems you want to solve? I can share, you know, our thinking on how we're gonna be solving those in the future, but try to avoid getting really specific with a public roadmap. "Yes, this quarter we're gonna be shipping these features. Next quarter, we're gonna ship whatever else."

    6. NYNan Yu37:28

       Yeah. Yeah. Totally. I think asking a lot... Like if you ask our salespeople, they're like, "Well, does Nan do in these calls?" They're like, "He asks a lot of questions." That's what they'll say to you, right? And then, and I think, I think that's, that's, that's true, right? Like, it's like, it's ultimately, I mean, ultimately these stakeholders they, they really do want to be heard. They're like human beings too, and, you know, for, for us, like the people on the other end of it are in roles similar to ours, right? They're like, you know, product leaders, VP of engineering, that kind of role, and, uh, you know, and they, they want to be heard. They want to know that they're understood, and so sometimes, like, that's all you're there to do, is to make sure that they, they know that you know what they're feeling.

17. 38:05 – 40:36

    Applying the Linear Method to AI agents: start with a clear model, learn fast, iterate

    1. AGAakash Gupta38:05

       So that's the Linear method, at least as I see it, as a lot of the core essence. Now I want to talk about how that Linear method is applied to building AI features. Maybe walk us through this AI agents launch. You know, I want to hear the stage gate processes. I want to see how you guys shaped it for craft and quality over time.

    2. NYNan Yu38:26

       Yeah. I, so, you know, one of the things that we talked about with the Linear Method, right, is clarity, establishing a very strong point of view, right? And, and, and kind of, uh, being, and shipping small increments. So the first version of our agent platform is there's a very clear concept. Agents are just like other users, right? You can do anything with them. You can, you can @mention them in comments, you can add them to your teams, you can assign them to issues, you can add them to projects, all this kind of stuff, right? They, they just have a user account, and we're gonna go from there. And then the world is gonna tell us if that is the right model, because nobody knows, right? Like agents are a new species of, of, of, uh, artificial intelligence that exists and, like, no one truly knows, right, how, you know, what the long term is gonna look like. So we started with that. And, um, you know, and for, for us, that was, that was a, that was a very clear spec. It's, it's a very small spec, right? Because all of the actions that humans can do inside the system are already established, so it's very clear. Um, and, uh, and we learned a lot immediately, right? We l- we, you know, quickly learned about this responsibility thing, that robots are not responsible for anything, so you have to, you have to put a human on the other end of it. Uh, we quickly learned that they're very chatty, so if you, you know, if you just use comments, they're gonna throw a lot of comments into the world and it, it might be a little bit overwhelming. So y- you might have to give them their own space to be chatty, and then only have the comments be like the super important stuff that they say. Um, and also just even the, uh... But then, but then also they have, they have these abilities that, uh, that humans don't have. They're able to kind of like look at your entire workspace and see every single issue all at once, right? No p- no person can do that in like less than like, you know, uh, in, in like instantaneously like, like, uh, like agents can. So, you know, giving them that visibility helps, helps them, uh, have the right context, right, to do their work. So like we learned these things because, like these are the, these are the, the emergent, uh, you know, kind of concerns and problems that we ran headfirst into. But like that's the goal, right? We had a very strong point of view. Agents act exactly like humans. We, we, we put that out into the world, and we discovered that it, there, there were some inadequacies with that point of view, and we discovered them fast, and now we're addressing them quickly.

18. 40:36 – 45:54

    Why Linear built agents (not a generic chatbot): follow real workflows and avoid bloat

    1. AGAakash Gupta40:36

       And when you created, I guess, that initial vision, like we're gonna be working on AI agents, how did you build up the conviction that we were talking about earlier that this is a problem to be solved, or this is an area we're gonna be working in?

    2. NYNan Yu40:51

       Yeah. The, the kernel of the idea came when we saw people starting to, like, juggle multiple agents simultaneously. Like, you know, 'cause a- again, like unlike previous modes of computing, uh, AI can take human clock level time to like do their work, right? It can take several minutes, it can take hours even, and, uh, and that, that's like a new problem that like emerged. And, you know, all of a sudden the, the work with the computer becomes like very, very async and, uh, and, you know, we kind of looked at Linear. We're like, look, Linear is the place where you're managing distributed async work. So we think there's a very good fit here. So that, that was the sort of origin- original kernel of it. If people were just kind of using, you know, kind of a, like IDE-based, you know, kind of live interaction type things in, in a single-threaded way, I think there wouldn't be a fit here. But because, you know, like people are s- really, really starting to run like background jobs and things like that, like we're like, okay, there's probably something, um, you know, that's something that's a, that's a very close fit. And also, you know, because people work in teams, they don't work necessarily in silos all the time, then like Linear will be a great place to, to try to, you know, to try to be like the clearing house for this kind of information.

    3. AGAakash Gupta41:59

       Okay. So I'm trying to contrast what I hear here with you guys not necessarily pursuing a lot of the flashy AI features before. And what I think is the difference then, like why you guys don't have, you know, a talk to me Linear chatbot like every other company, but you do have the AI agent, is you saw this happening naturally within users' workflows already. But you saw that there were some problematic elements of how that workflow was happening, so you saw opportunity for you to solve that problem. Is that a fair encapsulation?

    4. NYNan Yu42:33

       Yeah. I, I think that that's, uh, that's fair and that that's very typical for us, right? Like a lot of our features have, you know, are, are really evolutions of, of internal tools that we see people building out in the wild, right? You're a large company, you build this nice little tool for your team to use, and we're like, "Okay, that, that seems useful," and then we can help you like, you know, actually make a productionized, you know, full-blown version of it.

    5. AGAakash Gupta42:54

       Okay. So the takeaway from how Linear is approaching AI features versus your average company, right, is really focus on not what's flashy out there, whatever the latest AI trend is, but instead focus on what are a lot of my users doing [laughs] on top of the product that might have some problematic workflows within it.

    6. NYNan Yu43:17

       Yeah. I think a, a big part of it is that, you know, the, you know... I, I think our, our core mantra, like, for the Linear Method and for ourselves, right, is, like, really to, to solve real problems for real people. And there are so many real problems out there, so many that are emergent, so many that are existing, that, you know, we have, we have plenty of space to cover. Uh, rather than trying to, you know, do the thing that's, like, the loudest possible feature, we wanna... We, we, we're hopefully trying to make, like, the most useful thing.

    7. AGAakash Gupta43:48

       Love it, and I think there's a lot of lessons there for people, so go check it out. Um, see how Linear is not just, like, jumping on every feature bandwagon, right? Which I think that the average SaaS company is. And I think that goes to one of the things that people really love about Linear, which is it's not bloated. Are there any, like, other key disciplines or takeaways people should take so that they can avoid feature bloat?

    8. NYNan Yu44:17

       Yeah. I mean, there, there's the classic thing, which is take your users very seriously, but don't take them literally. And especially with a very wide, uh, product surface like Linear has, you know, people are gonna ask... You know, every single feature you could possibly think of, somebody has asked for before. And a lot of, uh, a lot of the response really needs to be, like, trying to understand, like, what, what the user's goals are, what they're trying to accomplish, you know, the... what, what kind of frustrations they're having and, and how that overlaps with what you're hearing from other, uh, from other customers. And then once you understand that, then you can, like, you know, begin to approach the problem space with, you know, with, with some kind of solution exploration. I... You know, like, a lot of times candidates and, um, you know, and, and, and, you know, and, and people, like, ask us about, like, "Hey, you know, all these startups try to compete with, like, Atlassian and Jira, and, like, you know, they, they all, they all kind of become very similar to them. Like, how are you, how are you gonna prevent yourselves from doing that?" And, uh, and I think the, um, the answer is, like, you know, the way that these incumbent company... Not, not just Atlassian, but a lot of incumbent software got to the way it is is 'cause they took their users, they... very literally, right? They, they said yes to a lot of requests, and that might have even been the right thing to do in that era because, like, all this stuff was new. They, they don't, they didn't have a better way to think about it. It's like, "Sure, our user's asking for it. Let's do it." But now, like, we're, we're kind of, like, taking a, a sort of second pass at this, right? We have the, the benefit of knowing that history and knowing what outcomes, like, that leads to, to sort of, like, you know, try to avoid and try to, you know, think about things a little bit more critically.

19. 45:54 – 53:30

    Career and org design at Linear: work-trial hiring, PM/PMM structure, and PM efficiency

    1. AGAakash Gupta45:54

       I wanna shift gears a little bit and talk about you. [laughs] So, uh, I think, uh, a lot of people would want a job like Head of Product at a unicorn, let alone, like, at the unicorn that all the top new companies are using. What's the story of landing the job?

    2. NYNan Yu46:16

       Um, you know, Linear, Linear has a, uh, a work trial-based, uh, interview, uh, system, right, where, you know, every candidate comes in and they, they work with a team for some period of time. Um, and, like, for me, I, you know, kind of consulted with the company on a, on a, on a sort of new feature set that they were, um, uh, kind of exploring. Uh, I think, you know, I ended up working with the company for a pretty long time, like, maybe, like, six weeks or something like that on th- on this thing and working with the team. Um, and it was, uh, enough of a, a positive experience on everyone's front where they, they, they, uh, you know, they made me an offer and decided to bring me on board. Um, you know, it was very fortunate for me. Uh, but I, I think that, you know, that, that's, that's a specific instance, uh, you know, for, for us. But I think generally speaking, um, you know, I... for... We are a fully remote company, and there are very specific qualities that, you know, we look for that, you know, other, other companies might not. Um, but just, like, very good async communication, like, extreme clarity, uh, like, obviously, like, bias towards action, all that kind of stuff. But it's like everyone says those things, but it's, like, it's, like, doubly important when you're, when you're fully remote. Um, so that, that's... I don't know. That's, that's the kind of backstory.

    3. AGAakash Gupta47:32

       So w- it sounds like you didn't have a full-time job at the time you did the work trial, right? How do people navigate that when they do have a full-time job?

    4. NYNan Yu47:41

       Uh, you know, we... It's paid, so, you know, basically we're, we're tr- we're buying some of your PTO. That's the best way to think about it is that, like, look, if you're willing to sell us some of your PTO, like, then, you know, we can, we can do this work trial thing. But we're also very flexible. We understand people have different circumstances, so if they need to, like, you know, kind of straddle a weekend to get a couple of days in there and stuff like that, we're, we're very, uh, open to, you know, making it work.

    5. AGAakash Gupta48:02

       Okay. And how did the initial, like, the very first process where you get in touch, I might be mispronouncing your CEO's name, Kari, uh, but get in touch with him, right, and, like, even clear the stage that he wants to do a work trial with you. How did it happen for you?

    6. NYNan Yu48:21

       Um, it, it was, you know, it, it, it was actually a very long story. Like, the, the f- my first contact with Kari and the team was, was, uh, years ago, um, when they were kind of developing the very first version of the product and I was, uh, you know, running an engineering team at a company called Abstract. Uh, and they, they were interviewing, you know, startups, right? And I was one of their, uh, you know-

    7. AGAakash Gupta48:42

       Nice

    8. NYNan Yu48:42

       ... their interviewees, so to speak, right? Like, you know, I told them all about, like, processes and my... I had, like, strong opinions about this stuff. So that was probably the first touch point I had with them. Um, and then, uh, you know, I kept in touch and, you know, when they, uh, you know, when, when it was, you know, a, a... There was a little bit of luck involved certainly, right? They were like, "Hey, we were..." They were looking to explore their first analytics productUh, you know, to help people measure, like, what's going on in the, uh, in their workspaces.

    9. AGAakash Gupta49:07

       Okay.

    10. NYNan Yu49:07

        Um, and I had just, you know, done a stint as VP of engineer- sorry, VP of product at a, uh, a BI company, uh, called Mode. So, you know, I, I had very relevant [laughs] experience for that, uh, that kind of problem.

    11. AGAakash Gupta49:19

        Yep. Okay. So the takeaways from your story, like, keep in touch [laughs] with people and make yourself available for that work trial if you need to. And then for somebody else, like somebody wants to become a PM on Linear, work under you, what would be your advice to them?

    12. NYNan Yu49:37

        Um, I mean, we ha- we have a job rec open right now, so my ju- my, my advice would be to, uh, a- apply for the job first. Um, but I think, you know, ultimately we are, we're looking for, uh, you know, someone who can bring a lot of clarity and a lot of, uh, i- initiative to, to the organization. Like, you know, for us, like, PMs are the... They- they- they sort of do the m- the most amount of work at the beginning and the end of the process, right? It's like the startup energy it takes to sort of, like, figure out the problem space and, like, get that initial exploration in place, and then when you're close to the finish line to kind of like make sure that everything kinda comes together and, uh, and we're really, really clear about how we're gonna go to market for things. So those are, those are the, you know, the kinds of qualities that we're, we're really looking for. Um, and, uh, you know, and, and yeah, definitely, definitely, uh, go to the, go to the job site and, and, uh, and apply for the position.

    13. AGAakash Gupta50:35

        What is the right way to, like, prepare s- yourself so that you do well in the work trial?

    14. NYNan Yu50:44

        I, you know, I- I- I- I think [laughs] there's not, there's not any... There's not one thing, but if, if there's one piece of advice I can give people for, honestly for any interview process, but especially ours, is you, you gotta put your ego away. I think a lot of times PMs are, you know, we- we're- we're so used to, like, doing a bunch of research and, like, being right about things and having a reputation and things like that, it's just like, look, you're, you're in a, you're- you're- you're in a, um, a process where people are trying to evaluate a v- it's a very difficult thing, right? Most PM interviews are, are extremely, you know, kind of messy, you know, sort of evaluation processes. You gotta, you, you really do need to put yourself out there and, like, have a lot of, like, just be exposed because people need to know what they're getting into. Like, a lot of the PM evaluation criteria are just like, "I need to know what I'm getting involved with." And if you, if you, you know, if you ha- if you're putting up protective screens and, and, and not really kind of like showing who you really are, then people can kinda see that, and then it just becomes like, "Well, I don't have enough information to make a, make a hiring choice here."

    15. AGAakash Gupta51:51

        So kind of being willing to be yourself then.

    16. NYNan Yu51:55

        Yeah. Although b- be yourself sounds so, so, like, mundane, right? It's, it's not, it's not really that. It's just like, it's like don't, don't, don't try, don't worry about being wrong. Like, the worst case scenario is you don't get hired, which is like, that's fine, right? Like, like no one, no one has 100% hit rate on, on, on applying for jobs, so it's just like you're... We- we- we count wins. We don't count losses.

    17. AGAakash Gupta52:16

        Makes sense. And how do you organize your PM team?

    18. NYNan Yu52:20

        Uh, so our, our PM team is very small right now, but, um, I think one of the sort of more distinctive, uh, features of it is that we have product management and product marketing, uh, all reporting into the same structure. Um, you know, I'm, I'm a big believer in that those are almost the same role. They have slightly different responsibilities, but, like, they, they ought to be a lot closer. Um, like, product marketing is much more closely related to product than it is to the normal marketing things like demand gen and, and, and, like, performance marketing and things like that.

    19. AGAakash Gupta52:49

        Okay. How many PMs do you guys have right now?

    20. NYNan Yu52:51

        Right now we have one. [laughs] One in additi- in addit- well, two including me, but, like, one, one addition, uh, in addition to me and, uh, and one product marketer. We have another product marketer coming on board next year, and we have effectively two PM, uh, PM roles open right now.

    21. AGAakash Gupta53:05

        Okay. And how big is the engineering team?

    22. NYNan Yu53:08

        Uh, gosh, uh, I don't know for cer- It's must be around 40 at this point.

    23. AGAakash Gupta53:13

        Wow. So you guys made it to unicorn status with 40 engineers [laughs] and 2 PMs. Um, that's pretty, pretty efficient. That's amazing.

    24. NYNan Yu53:25

        Thanks. [laughs]

    25. AGAakash Gupta53:27

        [laughs]

    26. NYNan Yu53:27

        We, we, we try.

20. 53:30 – 1:00:10

    From Everlane to B2B SaaS: margins, sales dynamics, and how to pivot industries

    1. AGAakash Gupta53:30

       So like we said, you were CTO at Everlane. Why, why are Everlane clothes so expensive?

    2. NYNan Yu53:37

       [laughs] Um, you know, it, it's funny. Like, I think depending on your point of view, they could be very cheap. Uh, Ever- Everlane is a, um... Certainly when I was there. It was a, it was a cost-plus business, and the, the game was really just to, you know, you have a materials cost and you're delivering s- you're delivering that as, as much value as you can in the materials to your customers with a, with a, you know, kind of standard retail markup. And I think that that's, um, you know, a, completely a function of the quality of materials that, that were chosen at any given moment in terms of, like, how expensive the, uh, the clothing actually is. Uh, importantly, it's, it's not a, it's not a, like, a lifestyle-driven or image-driven business, right? So if you compare it to something like, I don't know, like-like-like Coach or Burberry or something like that, it's like w- it, it's not, it doesn't have those kinds of, uh, those kinds of margins. It has, like, very, very reasonable margins. So if something seems expensive, hopefully that's because the materials that are being delivered have a lot of value.

    3. AGAakash Gupta54:32

       Okay. So it's really you guys are, are just doing that cost-plus method, but actually it's you're mostly reinvesting that price that somebody's paying into quality material.

    4. NYNan Yu54:42

       Yeah. Yeah, exactly. I think, uh, well, like, certainly when I was there at Everlane, uh, like 70 to 80% of the cost of goods was purely materials. It wasn't cut and sew or labor or anything, or shipping or any of that kind of stuff. That was the other 30 to 20%.

    5. AGAakash Gupta54:56

       What was the shift like from going to basically a cost-plus, lower margin apparel business into these companies like Mode and Linear, very product focused, totally different margin businesses?

    6. NYNan Yu55:10

       Yeah, I mean, it, it's, yeah, obviously, it's, it's like this kind of B to- B2C retail, you know, kinda scenario to, to, you know, kind of a product-led, but like all, you know, obviously ultimately B2B and, and in some ways, like enterprise business. Um, I, I think on, on that front, it was, there was a lot of learning, especially at Mode. Like, I, you know, kinda learned to deal with sales teams, um, you know, in, in a, in a really big way to kind of do all the kinds of, like, questioning and pushback that we talked about and when, when you, when you get sat in front of a customer and they're kinda, like, grilling you. Um, so I think that part of it was really, um, was a really big shift. Uh, however, I, I'll say that, you know, s- uh, a big advantage I had going into it was on the storytelling aspect. Like, if you think about selling commodity goods in a kinda cost, cost-plus way, the only differentiation you have is on brand and, uh, and on, on the story that users tell themselves in their heads. Um, and you know, something that I discovered was that, like, I, I kinda naturally came equipped with that muscle in a way that a lot of the sort of B2B PMs, uh, around me, like, just had no familiarity with.

    7. AGAakash Gupta56:13

       I made that shift a couple times, yeah, B2C, B2B, back again. I feel like some of the specifics, like you said, like there are specific skills, whether it's working with sales or working with customer success or dealing with enterprise clients, that are specific skills, but a lot of the essence of it, of product management, is still the same.

    8. NYNan Yu56:34

       Oh, yeah, totally. And like, even at Everlane, like w- I, I did a lot of the sort of B2B shaped things. Like, we built a lot of tools for our merchants and, you know, you c- you, you, you dig in and you're, you're, you're taking requirements from, like, power users. You're, like, learning about their workflows and their business and things like that, so you know, a lot of that stuff is very, very overlapped. Um, you know, ultimately, you're like, you're trying to produce some kind of, like, uh, theory of mind for your customers, like why they're making buying decisions, why they're making, um, like, why they're coming to you in the first place versus competitors. So yeah, a lot of that stuff is, has a lot of overlap.

    9. AGAakash Gupta57:09

       So you were able to successfully make the shift. I work with a lot of PMs who are job searching, and it feels like everybody right now is just getting pigeonholed into a particular industry. If they were in B2C apparel or even the more B2B flavored aspects like you were working on, they still end up just being stuck in apparel, or if they were in B2B SaaS, they're just stuck in B2B SaaS. Can a, today's PM really shift industries, and if so, how?

    10. NYNan Yu57:36

        Yeah, you know, I, I, I can, I can tell you my story, and you know, I, I, I don't know how widely applicable it is, right? Like, the, the way I shifted, 'cause like I, you know, I, I did my stint at Everlane, and, uh, you know, I had to use so many SaaS tools, you know, in that process. I'm like, I r- I r- like, I'm really interested in this area. I wanna, I wanna build tools for pro users. How am I gonna do it? Um, and the way I did it was I took a IC engineering job at a B2B SaaS company, and I, I, I'm like, "Look, I'm good enough at this stuff where it's a smallish company. I'll get in the door here, and I'll just be... I'll, I'll work my way into the right, into the right position." Um, so that was, that was my, you know, sort of like get your foot in the door, and then, especially if you're at a startup, like, people will quickly recognize your ability to contribute in whatever way is, you know, best suited for the org, right? It's like I, I know that getting hired is hard because everyone wants, like, the perfect candidate, but just, just get hired and then, you know, like if... Thought experiment. You're working at a company. An engineer on your team shows a lot of, you know, kind of ability to think through product and is really good at it. Are you gonna stop them from doing that? Like, uh, no, you're not. You're gonna be like, "No, do that more," right? Like, like-

    11. AGAakash Gupta58:45

        Yeah

    12. NYNan Yu58:45

        ... "That's great." So, like, put yourself in that position, right? So if you think you got the chops, just get in the door, and then you'll, you'll figure it out.

    13. AGAakash Gupta58:52

        I love that. So it sounds like, though, then you're, you were probably taking at least, well, we know a level hit, 'cause you went from CTO to IC engineer-

    14. NYNan Yu59:01

        Yeah

    15. AGAakash Gupta59:01

        ... but potentially even a compensation hit. So you might need to be able to take that in order to make the long-term move that you want.

    16. NYNan Yu59:08

        Yeah, I mean, I, I think th- that's, you know, uh, th- there are, there are obviously a, a, 1,000 different ways to do this kind of, this kind of pivot. This is what happened to work for me. Yeah, I did take a level hit. I took a compensation hit, but it also was something where I feel like it was very explainable on my resume. You know, I'm like, "Hey, I did a CTO thing for, like, a while, and I wanted to, like, you know, chill for a second and take an IC role for, for a year or so." Like, I... That, that's a very explainable sentence, right? Like, people, everyone will nod their head and be like, "Yeah, I get that."

    17. AGAakash Gupta59:36

        Okay. All right. Well, Nan, I think we could keep going for another hour or two-

    18. NYNan Yu59:43

        [laughs]

    19. AGAakash Gupta59:43

        ... um, but I know you, as a head of product, are very busy, so thank you so much for being on the podcast.

    20. NYNan Yu59:49

        Yeah, appreciate it. It was a lot of fun.

    21. AGAakash Gupta59:51

        If you guys have enjoyed this conversation with Nan so far, you will love our entire conversation, which you can find on Apple or Spotify Podcasts, where we break down the Linear method. And you will also love my newsletter, where we go even further on tactics, tools, and frameworks that you can take today to adopt this Linear way of working.

Episode duration: 1:00:20