-
Avoid Bloated Software
-
Avoid customization features requested by middle managers to ease reporting if they worsen IC workflows.
This trade-off leads to bloated software that makes ICs hate their lives.
Nan Yu
And what kind of feature requests do we absolutely have to say no to? And the stuff that we absolutely have to say no to is also the exact kind of thing that leads to this kind of like bloatedness that makes ICs kind of hate their lives. And it’s very specific. It’s customization features requested by middle managers in order to make reporting a little bit easier at the cost of making IC workflows worse, right? It’s like, if it fits that description, we’re just saying no. There’s no debate because we’ve already thought about it. And this is the thing that we can’t take a single step down this path. So I think that’s like, honestly, one of the core promises of-
Solve the Top 3 Problems
-
Understand customers’ top priorities, often hidden within longer lists of requests.
Focus on solving these core problems exceptionally well, surpassing competitors in quality and depth.
Lenny Rachitsky
It. So there’s an element of you think you need this, but it turns out you’ll be more successful and get everything you want not getting this yeah and and me and thing is it’s not everything
Nan Yu
You want right because like if people come with a laundry list and it’s like a laundry list here’s here’s 10 things i want you’re like do you want all those 10 things equally they’re like No actually i don’t the first three are the things that really matter to us if we solve the first three then the other stuff we can negotiate on so our job is to solve the first three way better Than anybody else. That if they got through the first three through some kind of like visual programming customization type of thing, that it’s never going to get to the quality level and the depth that We’re able to offer by offering those as native features.
Lenny Rachitsky
It’s interesting thinking back to that survey I shared where like the tool people want to switch to if IT allowed them was linear. And on the one hand, you could argue, well, OK, IT is not letting them use linear for all these reasons. On the other hand, you guys are growing really quickly within enterprise.-
B2B Software Teaches Workflows
-
B2B software often originates from internal tools created to streamline successful processes within companies.
Adopting such software means adopting the underlying workflow and best practices it embodies.
Nan Yu
Know, I think like if you think about how a lot of B2B software gets created, it’s because there was some person in the middle of some giant company who implemented some kind of process. And they’re like, wow, this process is really working for us. Maybe we should make it easier. And they build a little tool internally. And then like all of their, you know, colleagues can now like press on buttons and good things happen. And then they turn that process and that tool, you know, they spin it off into a startup and they like make a startup. This process repeats thousands of times. So when you adopt that tool, you’re not just adopting like the actual software, you’re adopting the idea that this is a practice that you ought to be doing in the first place.-
Choosing Tools
-
When choosing a tool, recognize that it will change how you operate.
Be thoughtful about how you want to work, not just the problem you want solved.
Lenny Rachitsky
I think a takeaway here is when you choose a tool, recognize it’s going to change the way you operate and be thoughtful about the way we want to work versus just we just have a problem we Want solved. Yeah, exactly. I-
Deadlines
-
Take deadlines seriously and treat them as P0 problems so stakeholders understand their importance.
Reduce scope as much as possible to ensure the deadline is met with a shippable product.
Nan Yu
Have a very specific point of view on deadlines. I don’t know if that’s a fire away. I think like what often happens is people get depressed about deadlines, right? They’re like, hey, here’s the ship date. And then you never make it. You know, I don’t know if you’ve had this feeling before. Absolutely. You were an engineer before too, right? So it’s just like engineers is better. Like, oh yeah, yeah. Deadlines, they’re complete fabrications. And the only way to make deadlines real is to take them so seriously that they are basically like a p0 problem and like everything else has to not matter in comparison to the deadline because That that’s the that’s the only way you’re going to be able to signal to the team and also to all stakeholders that you’re actually taking it seriously so you know my my feeling on deadlines Is don’t have too many of them right and when you do, it’s a P0. So the engineers working on it, they don’t get to work on anything else. Like someone’s, oh, I need them for this. Like, don’t, nope, you’re not pulling them off of anything. We’re doing this. As a PM, your job is to just cut as much scope as possible to make it possible to hit that deadline, right? Like, what are the things actually blocking us from doing it? Because what you want to do is at the moment where you have to make the go-no call on whether to ship, you want to be able to actually have a product that you can say yes to. It might not have all the features you had wanted or whatever it is. And you can say no. You can make that choice. But you want to set yourself up to be in a position where you can actually say yes or no to something. Because what often happens is like oh we want this thing well it’s not even close to being done yet so there’s no possible way we can say yes right i can’t ship it it’s just it’s it’s like Half broken it’s like no no you want to get to a point where it works right it might not be the product that you want but it is an actual real product that you can conceivably ship so you said
Lenny Rachitsky
That uh don’t have too many deadlines, but when you do, make sure everyone understands these are actual deadlines.-
Treat Deadlines Seriously
-
Treat deadlines as P0 problems; don’t let anything else distract the team.
Ensure the product can ship by the deadline, even if it lacks some features. Aim for a “yes” or “no” decision, not an impossible task.
Nan Yu
Because what often happens is like oh we want this thing well it’s not even close to being done yet so there’s no possible way we can say yes right i can’t ship it it’s just it’s it’s like Half broken it’s like no no you want to get to a point where it works right it might not be the product that you want but it is an actual real product that you can conceivably ship so you said
Lenny Rachitsky
That uh don’t have too many deadlines, but when you do, make sure everyone understands these are actual deadlines. When do you decide it’s worth having a deadline? Is it like a marketing launch sort of thing? What’s worthy of a deadline in your experience?
Nan Yu
Yeah, it’s usually having to do with some kind of external marketing type of exercise that you’re trying to hit. Got it. Uh, and I think that that’s like the other thing that I think as, as builders, we, we, we can often look at like launch dates and stuff like that. It’s like, Oh, you know, who cares if it’s a little bit later or we skip this, this change log or whatever it is. And I think that that’s, you know, that’s, that’s really, uh, I don’t know. It makes me go crazy when I hear people say that in all honesty. With marketing and communication with customers, you basically have a limited amount of opportunities to do so. A year is 365 days. There are 12 months. Each of those months has about four weeks. There’s some rhythm where you get to have 50-ish weeks to say something to your audience once a week. Or you get to have 12 months to say something really big or four quarters to say something huge. If you miss one of the opportunities, you don’t get it back again. You can’t time travel back and say like, okay, actually, let’s redo first quarter and say this message that we
