Lenny Rachitsky: belief

Transcript context

…Part of it is you hear something, and you're like, "Gosh, that actually is... " Not only is that true. It means that the way we thought about this was a little bit wrong, and I call this process... I don't know if it's the right way to describe it. I call it a kneeling where you have a thing, and it's not quite the right shape, and you put it out into the wild. So, this happens way in the first bit of the life of a particular feature. You release a thing, and then you start getting feedback about it, about hey, it doesn't quite fit reality, and then you ask yourself like, "Did we test that aspect of it? Did we actually match that part to reality?" And if you didn't, then it's like that's the part where you don't actually need that many pieces of feedback against it. It's not really a volume thing. It's like, "Did we think about this right or wrong?" That's one sort of category. Another category is just you're getting a request for maybe a very big feature or a feature set from a lot of different people, but then you dig in, and you try to say like, "Okay. Well, tell me about how you're trying to use this," and there's 100 different use cases. So, you have choices here. You can either build the big feature that covers all the long tail of use cases or you can try to see if there's really concentrated pools of use cases for this that really make a lot of sense to adopt as a first order type of feature. So, I think those are the two sort of strategies that we employ the most. It's like, "Did we think about this wrong? And now we're just learning something about how it matches reality or for this big general feature that people are asking for, are there actually more specific use cases that we should be solving, and we should be solving really, really well?" A thread that's coming through so far across a lot of these examples is getting to the specific person using the thing and making them happy and making sure the ask is going to solve their actual problem. In the case of looking at the IC versus the middle manager, in this case, it's like, "Let's talk to the person actually asking for this thing," not, "There's like 100 people generally asking for this thing and let's build what we think is a general solution. " Yeah. I'll give you an example of all of these things, which we just launched a feature called Customer Requests, and basically what this does, it adds a new concept of Linear, which is a customer. For B2B companies, this is very relevant, and the reason we did this is because we kept getting this request for fully customized fields, and we would be like, "Well, what is it that you want with your custom fields?" Because the problem is you add 100 custom fields and all your ICs start hating it. So, we don't want to go down that path, but what is it actually you're trying to do? And 40% of them were because, "Well, I have a customer," like Walmart or whatever, right? Like, "Walmart asked for this feature, and it's really important. I need everyone to know that Walmart needs this. I need to track it. I need to see how have we report... " We can report on what have we done for Walmart over the past year so that when my CSM has a one-on-one conversation with a rep, they can have some kind of evidence that we've been doing stuff for them, like all this kind of stuff. We're like, "Okay. Cool." That sounds like a very useful and powerful thing you want to do. How do you expect people to tag these things? Well, manually, because that's how we did it in our spreadsheets. It's like, "Okay, instead of that, we're going to hook up with your customer support tools. We're going to hook up with your CRNs. We're going to automatically bring in feedback from these companies. We're going to analyze the emails where they're from, and then if someone requests a feature that gets escalated into engineering, it'll just be tagged with whoever asked for it. You don't have to do anything, but you will know, and you can still report on this stuff, but there's nothing about this that makes ICs lives harder. In fact, it makes them feel more confident because when they're building the thing, they actually understand who's asking for it and exactly what the email said. So, when they're doing the design or the details, they can actually see the real-life use cases that are present and solve for those directly.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.