"Building Product at Linear" with Nan Yu, Head of Product at Linear (1/2)
"Building Product at Linear" with Nan Yu, Head of Product at Linear (1/2)
How Linear thinks about A.I., goal setting, user feedback, and building opinionated software.
You can watch this interview on YouTube, listen to the audio, or read the transcript below.
This interview with Nan Yu is Part I of a 2-part series on Linear. Part II is a deep dive into Linear and the future of product management.
Interview Outline
Disclaimer: The interview has been lightly edited for length and readability.
As an aside, Substack just launched Notes - you can find me there :) And if you find something you like in this article, highlight it and you can “restack” it!
What is Linear’s vision?
Jacob: Linear is taking on some giants in the space like Jira and Asana. These companies are worth tens of billions of dollars and are used by virtually every product company on the planet.
It feels almost like a solved problem and yet the popularity of Linear has proved that it isn't. What is the vision behind Linear that drives it to create a product in a red ocean and be able to do it so well?
Nan: There's a lot of things to consider. I say this with completely honesty, right? We have a lot of respect for what Atlassian has done over the course of that company's lifetime. They effectively built out this particular space, right?
Jira is like a de facto standard for a lot of people's experience. And no one ever got fired for installing Jira, right? With any kind of incumbent like that, like they're always going to look like they have a sort of market dominant position.
And I think it's been tempting for a lot of startups to try to compete with Jira, right? If you ask engineers on the ground, the app it's starting to show its age. I don't know exactly what their NPS is, but if you look at an incumbent with a big market cap with relatively low NPS amongst day-to-day users, it's appealing for a certain kind of business to want to try to figure a way in or try to figure out, is there something new we can do in this space?
When we think about what Linear's perspective is, I think you of have to look at the founders of the company and the sort of people who are early on in terms of developing the app. Like we all came from a background where we got into software because it was fun, right?
We got interested in software before it was like, “oh, we make really great six figure salaries and you'll work at Facebook and Google and have a great career.” Like we were into this because we were hacking like my MySpace pages and making flash games and screwing around with computers in all sorts of different ways, right?
And we're from that kind of generation and it was fun. And we got into the corporate setting and all of a sudden became like really un-fun in all sorts of weird ways. So I think like overall, we think that we could have an opportunity to introduce ways of working and ways of developing software which make it fun again. And I think that there's a real sort of emotional opportunity there for people to adopt Linear.
“We could have an opportunity to introduce ways of working and ways of developing software which make it fun again.”
How Linear hopes to change product development
Jacob: If you fast forward, let's say 10 years, maybe even five years into the future, how do you see Linear changing the landscape of product development?
Nan: Yeah. I don't want you spending your entire day in Linear, right? Like that would be like a kind of failure mode for us if somebody just spent their entire life managing issues here and there.
So I think the utopian vision is that a lot of people who use Linear don't even know they're doing it. There's a big piece of what we're trying to do to make it pretty transparent in terms of just like what needs to be done and what kind of work is being done at the company and how software is being developed that lets people focus on their actual jobs and the stuff they're experts in, the stuff that they're interested in without focusing on all of the meta work. So a lot of the decisions that we're trying to make are trying to minimize the footprint of Linear in people's actual day-to-day lives.
“So I think the utopian vision is that a lot of people who use Linear don't even know they're doing it.”
What is the Linear Method?
Jacob: That's such a beautiful metaphor, I think, for good design as well. Good design disappears, so does good products. Products that actually do the work for you and fade into the background and allow you to focus on other things is a really cool vision for it.
I want to transition into the Linear Method because it actually dovetails beautifully. The Linear Method seems to cut through the fluff of the industry. We've built up this product manager persona in a way that says you have to have this sort of process, this sort of framework, you have to organize the tasks really well and have this great Kanban board or prioritization system or whatever.
And in reality, what we're trying to do is get from point A to point B from ideation to production ready code in a short amount of time as possible and do it efficiently. And so one of my favorite parts of the Linear Method is write issues clearly in plain language instead of using user stories.
It harkens back to this day when it was important to translate non-technical user feedback into technical documents or something. But these days everybody knows what a notification is. Everybody knows what a login screen is. And so you can just say build a login screen and that's gonna be enough to provide direction and boundaries for your engineering team.
What is the impact of the Linear Method on Linear's growth and adoption?
Nan: Yeah. And you raised a good point about, like the timing matters, right?
There was a moment in time in the sort of practice and history of software development where like user stories might have made a lot of sense because people were really wrapping their heads around this idea of translating business requirements into actual working software.
And, one of the things you pointed out is you're like, look, a lot of these patterns exist already. You can just say, do the pattern, instead of trying to indirectly tell people that you want the pattern, right? The user ought to be able to like, input their email and password in order for them to authenticate.
It's okay, you want a login screen? Thank you. And the Linear method is related to that, right? There's a lot of words that get thrown around in the industry a lot like agile and Sprint and epic and ninjas and all that kind of stuff.
And, we created those words partly to brand some of these ideas. But like the more you brand it, the more they take on a life of their own. And I think we're at a point now where everyone knows how these things work. And that gives us an opportunity to simplify the language and simplify the communication back down to what are you actually trying to get done.
Because honestly we think back to the original point that like software development and writing code and designing and things like that, like those are really interesting, deep, fun activities already. You don't need to make it more fun by calling people ninjas. That's not a thing that you need to do. And I think the Linear method is really about just like setting up a framework for people to retain their focus and put it back onto the actual task at hand.
“Writing code and designing are really interesting, deep, fun activities already. You don't need to make it more fun by calling people ninjas.”
Jacob: There's been other companies, I believe Basecamp is one, that's written a manifesto that says, this is the way that we view the world and why we're building software this way.
And it I think the goal of the manifesto has always been to attract the sort of people that see the world through the same lens that you do. Has Linear had a really visceral response from the community through the Linear method? Or is the Linear method more of an internal playbook?
Nan: I think as much as anything, it's a sort of framework for people to understand how the software is designed to work, right?
A lot of times onboarding is really hard because the question that people ask us, like, how is this supposed to work? I wanna do things like the right way. That's like something that we hear a lot when people kinda adopting Linear for the first time.
And what we are trying to emphasize is in your mind, simplify it down to its most fundamental components and that's the right way. And I think it's much easier for us to communicate that than to come in with, specific terms that we made up.
“Simplify it down to its most fundamental components and that's the right way.”
The Linear method is a way of expressing that, right? If you're working on a project, it's called a project. That's what it is. And that's it, right? There's no other weird word that we came up with for this.
It works how you think a project ought to work. Okay. Now that you've taken the five seconds it takes to learn this, go and actually produce software like you intended to do.
How is Linear opinionated?
Jacob: I think that the Linear Method has caused a lot of people to call Linear, opinionated. What are some of the strong opinions that Linear has built into the product itself that maybe people say, “wow, it might not be flexible, but this is exactly how it should work.”
Nan: I think this is gonna cause some of our users to feel a certain way because there're two feature requests we get all the time. And one of them is like custom fields and related to that, required fields, right? Those two kind of come hand in hand. And another one is like multiple assignee to an issue. And, so far, we've said no to those requests consistently over time. Hundreds of times.
“…we've said no to those requests consistently over time. Hundreds of times.”
And I think that is a strong opinion because like at the end of the day, we value clarity over almost everything else. We're like, for the day-to-day engineer doing their job when they have to either create a ticket or close an issue or do some work like they really need to know what is going on, right? And if they don't know anything at all but they just know who's responsible for this thing, they at least have someone to go to and like figure out “okay, that's my point of contact, I need to talk to 'em about this.” Or, “that's the person responsible, I can rely on them to get it done.”
Or if that person's me, it's “okay, everyone's relying on me to get it done.” Those are extremely valuable to hold at scale. And it's worthwhile to sacrifice a lot of flexibility in order to just maintain that promise to every single engineer on the ground.
There are disadvantages, right? Sometimes it's these two people working on it together. It's like, look I get it. We're thinking through a lot of different solutions to kind of maintain the clarity about it, but also let you express those kinds of ideas in the system. But, as a starting point, we're always gonna prefer clarity over every other trade off.
“…as a starting point, we're always gonna prefer clarity over every other trade off.”
Why Linear says “no” to custom and required fields
Jacob: And people might create a million different fields, muddy up the water of the issue. But if there's something that's recurring and everyone would love to create this particular custom field, then maybe that's an indication for Linear to build a feature set around that problem that they're having and make it a first class citizen of the product as opposed to it being this hacky custom field solution for it. Am I on target with that?
Nan: Yeah. I think that's one of the approaches that we've taken to field these kinds of requests, right? There are things that are first class citizens of Linear that we think are important just broadly speaking, for most issues. And those things we're happy to add to the feature set.
The problem with custom fields is sort of twofold, right? Like the first one is like what you said, like people had a million of them and then now you have no idea which ones are actually needed for a particular issue versus another one. Do they have the same custom fields? There's all sorts of configuration and sort of tribal knowledge that everybody needs to know.
And then the second problem is people then start using the hammer of oh, we'll make some of them required. And then you invariably have the this required field, but it's actually not applicable for the thing at hand, so I'm gonna put in some kinda placeholder, meaningless value to it.
And then your data quality just goes down. So our perspective has always been like, when we see other tools building these kinds of things, usually what's motivating it is there's some kind of like reporting need, right? From the management layer or above.
And they're like, "Hey, like I want to be able to understand my issues from this perspective." And in order to do that, I'm gonna force down the tedious work of doing the data entry on everybody, right? On everyone who's like doing the day-to-day stuff. And we've taken the inverse approach, right?
Which is that let's really make sure that we're always focusing on making everyone's day-to-day experience really excellent. And that's the way you're gonna get good data quality, right? We get this feedback from customers all the time which is, “for the first time I can actually rely on the issues to be like correct and up to date.”
And it's because people understand why doing whatever data entry is actually necessary is going to add value to their life. And then they're motivated to do it. And then from that foundation you can actually have reporting that's useful.
You can have very nicely structured reporting that is bad data quality, and it's just garbage and garbage out. And we're just like, “let's avoid that situation,” right? Let's make sure the data quality's always good by making the day-to-day experience really excellent. And then we can solve the reporting problems independently.
How does Linear build product?
Building Linear Insights
Jacob: I love that you mentioned that because y'all just released Insights, which is this gorgeous reporting feature built right into Linear. Let's talk about the process from idea all the way through to production and kind of walk me through how product gets built at Linear.
How did that idea get on the table? What kind of conversations were had around it? How did you get it to design? How'd you get it to engineering, et cetera, et cetera.
Nan: It's a funny story, because this is the first thing I worked on with Linear. I actually started off just as a contract product manager with Linear during the start of this process where they're like, we keep hearing it from customers. Everyone's like, "we need reporting. We need reporting." The IC's are loving all of the day-to-day work, but the managers are feeling like they're flying blind here, and we just need to be able to understand the numbers behind a lot of these things.
And everyone on the team says, okay, so clearly there's a need for some kind of reporting, but we don't wanna be in the business of building like a complete BI tool on top of our existing system, right? That's taking on so much scope.
We also don't wanna be building really underpowered tools that tick a box. Okay, you can buy Linear now, it's got reporting because it says so on the feature matrix. But then people use it and it has an outrageously steep learning curve or they just don't find it useful, right? We wanted to avoid those things.
And that's why I was originally brought in. We wanted to do a lot of research about what kind of reporting do people actually want to be doing out there. We took feedback from different customers who are asking for it, different sales conversations that we had where people expressed this is a requirement.
We read a lot papers and books written about reporting on Agile development processes and things like that. And okay, what can we take away from this that we think is like valuable, but what are the core concepts?
So there was a pretty extensive research process and but even by the time I had landed on this particular project the team had already done a lot of like user interview and stuff. So they had videos and notes and things like that to review.
Before we started developing on it, we felt like we understood the sort of key problems that we were trying to solve in the space. And the sort of design process for it was really about like simplifying that down to the minimum set of things that we can do to actually solve these things.
And we're not trying to be overly minimal. We don't wanna be austere about it. If you look at insights, there's a lot of features in it. But we wanted to center on key principles that make people really want to use reporting features.
#1 — Attention
And where we landed was, a lot of it was like, people wanna know where they're spending their effort. They wanna know where the team is spending their attention. That's like one major locus of where those requirements ended up coalescing around. Another one was they wanted to know how long things generally took.
#2 — Time
And then the sort of variant on that, it's “hey, if everyone does like estimation and we all know it's wrong, but how wrong is it actually?” Always wrong. But is it useful wrong? Or is it like random? People wanna know that. Presumably every single task management system can tell you how long things actually take, but like very few of them actually do.
#3 — Data
And then the third piece was really about data quality more than anything else. “Hey, we have this policy where, when a bug comes in you should try to label it with what customer reported“ or something like that.
We have this sort of soft policy and sometimes it makes sense, sometimes it doesn't. And you know what, it only makes sense for a subset of things or whatever it is. It's a very complicated rule set. I just wanna know of like, how good are we doing in that particular idea, right?
Or we're trying like to run a particular process. How well are we actually achieving the intent. And then you want some kind of reporting to just give you some aggregates about that kinda stuff. So those are the main areas, right?
So we're like, okay, let's make reporting that can answer those questions in a way that's like flexible enough because every company is incredibly different but it also makes a lot of sense within the Linear ecosystem, right?
We wanna make features that make sense in the context of everything else that kind of existed. So yeah, those were the main considerations that we had during the sort of initial research and design process. And we had a working version internally very early on, right? For us, it's super important to dog food the absolute heck out of every single major feature that we develop. Within maybe like a month of development, we had an internal working version that was not nearly ready to go for primetime, but like we could use it to do work and figure out what was good and bad about it.
And then we iterated,
we went through a private beta process where we teased it and had signups,
we went through a public beta process,
…and we're near the end of that public beta stage and we're maybe a couple weeks out from being ready to go to call it done.
The role of product in an engineering-heavy org
Jacob: Linear is known for having engineers and designers working on the problem at the same time. What did that look like in terms of bringing some insights from a customer interview to the table and then actually trying to solve that problem?
Was it, “hey, maybe this is a direction based on this user interview, can you go design something real quick and let's see how that looks? And engineer, is that buildable based on our current stack?” What does that conversation look like to involve design and engineering at the same time?
Nan: Yeah. I think in order to understand that you have to understand our staffing profile at the moment. In terms of working on the web app and the electronic app, we basically have two designers, right? And I wanna say 20-25 engineers or something like that.
So that's not a ratio you'd like normally deal with. And I'm the only dedicated product manager, where that's like my entire role. Almost as a forcing function, I have to stay very high level, and the designers have to stay pretty high level, right?
They're not gonna get into the pixels of every single feature that we build or anything like that. And then the product engineers are the ones that are doing a lot of the design work, design decisions as they're iterating on things. So I think that's something that's a little bit unusual about how Linear works.
Like it's it's default collaborative because we literally don't have the bandwidth to do the sort of like full separation of responsibilities like you would normally see.
Jacob: I know that your role is a very unique one in the world of product, but I want to dive into it because it fascinates me. Linear is very vocal about building for engineers versus building for product managers.
Presumably because engineers are the ones actually executing on the work, and they need to be able to take tasks and translate that into, "what am I supposed to do today?" How does your role as a product role insert itself into an organization that is very engineer driven?
Nan: I think the way to think about it is my primary responsibility is to connect different teams to each other. That's fundamentally what I'm doing. I'm taking a development team over here and then the one over there working on different issues working on different projects and features and saying, okay, like how do these two lines of development make sense?
Like at the same time or with each other? How do these features interact? Linear's a very horizontal type of product. There's a lot of different features for different parts of the development process. And they all have to make sense together. No one likes going into a piece of software and they can see the org chart from this piece of software because this thing and this thing are just totally removed from each other. They look like they were designed by different teams.
A big part of what I do is connection and integration both across dev teams like I described, and also up and down, right? What's the business strategy? What does that mean in terms of the customer segments we're targeting and how does that make sense with what's being developed and what the roadmap looks like.
If I'm able to connect the development to the business and teams to each other then I'm doing a good job.
How does Linear set goals?
Jacob: What is the process for setting goals at Linear?
Nan: Yeah, so I, I think a lot of a lot of companies get into trouble if they try to be too goal driven. Like, we set OKRs and that trellis down all the way to like individual contributors and then people are trying to set their own OKRs and just like shrug and pick a random number cause that's the best they can do.
So we're trying to like, avoid that kinda thing. For us, goals are at the level of managers. The goals themselves are pretty high level, right? There's like certain customer segments that we're trying to target. There's certain objections that we're trying to get past for things like enterprise accounts and things like that.
And so even just with that basic starting point like we leave it up to the creativity of the teams to figure out ways to attack it, right? Like we have to:
Take apart the problem,
go to the data a little bit,
understand what kind of user behaviors are driving a particular metric or number that we're seeing,
and then form some kind of hypothesis around how we might be able to solve that.
And then after that it's mostly about execution.
So I think like with everything else that we do at Linear, it's a fairly like minimal and simple process.
“For us, goals are at the level of managers. We leave it up to the creativity of the teams to figure out ways to attack it.”
We either got the customers or we didn't. We either had good adoption amongst a particular market segment or we don't. These are not things that we need to overcomplicate and we try to get these as directly as we can.
How does Linear gather user feedback?
Jacob: Obviously, you guys have a very active community. A lot of people are vocal about Linear.
Are you getting on the phone and calling people for user interviews regularly to try to prove or disprove a hypothesis? Or are you just combing through user feedback that's already coming through other channels? What's the process for making sure the data that you're basing decisions off of is good data.
Nan: So I have pretty strong opinions about this. I think that you're basically trying to triangulate three things, right?
Passive User Research (User Feedback)
Like the first one is a backlog of customer feedback. You have to have a pretty decent way to record that in a way that's structured enough for you to go reference it. I think that there's a lot of interesting things that we're trying out internally that's probably gonna make its way into the product at some point, but that's one step that you have to take and make sure you have that really buttoned up.
Product Strategy
The second thing is like understanding what the strategy of the product in the company is. There's a core strategy that we're taking, right? We're really focusing on the developer persona, making their life really good, adding layers on top of that. That's the strategy. That's not set in stone. We can change that if we want. But we’re saying, okay let's get an understanding of what the customers are saying to us and try to match that with what the strategy of the company is.
Active User Research (User Interviews)
And then the third piece is what you're talking about, which is like going out and doing active research around stuff. And I think active research is a little bit dangerous, right? People are like, I have a hypothesis and they go out and they ask questions that would like, lead to “oh yeah, here's why you're correct,” right? This is a very human thing to do.
You can shake your finger at people and say you should try to be unbiased in your interviews and stuff like that. You can try as much as you want, but it's pretty hard to avoid in some circumstances, especially if you're just really trying to get like an understanding of the details of whatever hypothesis or theory that you're putting out there.
But I think a healthy balance is trying to understand that is gonna be biased to some degree and then matching that to the company strategy.
How do you avoid bias in user interviews?
Jacob: So going back to the question about user interviews, how do you do that in a way that is trying to remove as much bias as possible, but also dig into the deep questions around that user interaction in a way that's informative for the team?
Nan: Without getting too much into like interview theory and things like that, I think one of the things that you wanna do is honestly just acknowledge that it's gonna be biased to some degree. That's the first thing I start with. I'm not trying to minimize the biases. I'm trying to control it. I'm trying to control the risk of bias.
For example, we're working on roadmaps right now, right? We're trying to make a roadmap feature a lot better. And one of the things that we ask is, "Can you show us how you communicate? How projects in the engineering department are coming along? Show us like what you are actually doing to communicate those things. What emails are you sending, what reports are you building, what spreadsheets are you maintaining?” All that kind of stuff. And that's good.
It's not gonna tell us whether having these kind of high level views are important versus not, right? We have to have some kind of independent theory to describe that, but we're not asking questions about, “how do you wanna improve the roadmap feature inside of Linear?”
Like we're trying to figure out what people are doing of their own accord and things like that. So just taking that more oblique approach to understanding the topic is probably the go-to tactic that we're trying to do to make sure that we're not just like seeing everything through rose colored glasses and giving ourselves a lot of confirmation bias.
“We're trying to make the roadmap feature a lot better. And one of the things that we ask is, ‘Can you show us how you communicate? What emails are you sending, what reports are you building, what spreadsheets are you maintaining?’ We're trying to figure out what people are doing of their own accord”
How does Linear organize user feedback?
Jacob: You've mentioned that the suggestions and feedback that you get from customers through Slack channels or Twitter or any other feedback mechanisms that y'all have in place gets funneled through into the different Linear comments or issues in order to consolidate those things in one place. Do y'all still do that or is there a different way that y'all track.
Nan: Yeah, you basically described our process. We have a lot of integrations with things like Zendesk and Intercom. So a lot of the inbound requests and comments and feedback and complaints eventually makes its way to an issue within the system in one way or another. We also do the same kind of thing with the other support channels we have like Slack and we have a pretty active customer community. It's like a dedicated Slack instance. So we're always constantly linking feedback and messages from those channels into Linear issues as well.
Jacob: Does the feedback have any sort of upvote mechanism within the issue itself in order to move something up the chain of priority? Or is priority kind of a manual process that's based off gut instinct from the team and you just use the feedback to inform that process? How does that work?
Nan: It's probably closer to the latter. If something keeps coming up over and over again and a list of associated customer comments for a particular issue gets huge, it becomes fairly obvious, but it's kind of binary in that way, right?
Either it's there to inform "hey when we do get around to building this feature or to making this improvement or whatever it is, let's make sure we've taken into consideration everything that we've heard. Or, it’s like, "so many people are talking about this, we really ought to think about prioritizing it."
So it's binary. There's no “sort everything by number of times it's been voted by people” or anything like that. It's like a two step process.
How does Linear think about the role of AI?
Jacob: I want to wrap up on a question that is very relevant to today's larger conversation around AI. I've seen some AI tools come out for product managers that seem to try to automate or take some of the grunt work out of general PM responsibilities. And Linear is already doing that without AI.
And so I'm really curious about the crossover because we're getting to a point where, with GPT-4 and other models, there's a lot that AI can do in a way that's very helpful for getting the project management part out of the way and letting people focus on actually building.
How are y'all thinking about AI and what do you think that the role of it is in the context of Linear?
Nan: We're definitely thinking about it a lot. Jori is very hands on wit thinking about our AI strategy and how we want to apply that to the product and to the business.
On a theoretical level, the first thing we have to acknowledge is that things are moving extremely quickly and any assumptions about what it's capable of doing and what it's not capable of doing can just be completely made obsolete in like a few months. So I think we have to go into it with some level of self skepticism and sort of humility about that.
Natural Language Queries
But the places where we can really use some of these large language models in a way that's naturally helpful for people is, if you think about a lot of the interfaces in Linear, what makes it so powerful is we give people ways to do visual programming in terms of building entry points into their issue database, right?
Like what are different ways I can look at this collection of issues, whether it's through Insights, whether it's through custom views or filters on projects and things like that. Those are all kind of visual programming interfaces. And a thing that AIs are good at right now is translating natural language into sort of structured language, right?
So I think there's a lot of opportunity to give people easier ways to construct those queries. People are like, “I got my AI to write sequel for me.” It's basically the same thing.
Semantic Issue Processing
I think if you go one step beyond that and you can break apart issues down to their sort of semantic concept, you can do stuff like automated de-duplication much better than we're doing today.
Every day you can think of your product a little differently. You're like, "hey, there's a feature taxonomy that's structured in a certain way or maybe I can think of it from the perspective of different user personas or things like that."
And I can try to break apart the semantics of the issue to say, "organize all of the issues in this area by these five different user personas?" And that's something where like previously, what would you have to do? You would have to, at the time where you create each issue, spend some mental effort to tag it according to some dimension that maybe you'll use later, right?
“I think one of the most powerful things that AI opens up the possibility for is turning that just-in-case work into just-in-time work.”
There's a lot of this like just-in-case type of admin work that you have to do. And I think one of the most powerful things that AI opens up the possibility for is turning that just-in-case work into just-in-time work, right? I have a new idea. Maybe there's a fifth user persona that we weren't considering. Now, can we retag every issue according to this new taxonomy? And previously that would just be like the most annoying thing ever to do in the universe, right? And now it's like, “just let a computer take a first pass at it,” right? And then we can just see if there's something that makes sense.
So I think those are near term, obvious opportunities that take advantage of what AIs are good at today. But I don't know what they're gonna be good at in six months. That's the interesting and scary and fun part of the state of technology right now.
I hope you guys have enjoyed this interview as much as I did. If you enjoyed it, please share it so others can learn from world-class builders.
Subscribe to get more content like this in your inbox each Tuesday!
—Jacob ✌️
❤️ Smash that heart!
If you enjoyed this article, smash that heart icon to show some love! 🙏