Lenny Rachitsky: evaluation

Transcript context

…There's a couple ways that you can turn that around. So one is you should still be having regular communication, so they can still see what's coming up in the now call them. So they have a sense of what the order of things are and that things that are in the now column are probably weeks away, not months and months away. You should probably have launch readiness meetings so people understand this is the stuff that's going through testing, and that's likely to be coming out now. But one of the other things that you can be doing for your marketing and sales teams is separating your hard launch from your soft launch. So what you should be doing is basically saying your developers are able to launch something on a particular date and it's the date that's convenient for them, right? Let's say they think that they can get something out for end of September. Now, that might be pushed to made October because things go wrong. Now at that point, whether it's end of September or mid-October, it doesn't really matter to the marketers because they're busy talking about the stuff that was launched in August. They've got lots of stuff to work on. They're selling and marketing the stuff that's already live and out there. When this new thing comes out, that's a soft launch. As soon as that soft launch is out, great, let's kick off this launch meeting with launch steps. Now you've got something else to go do. And it's so much better for marketing anyways because they're not setting up their launch steps based on something that they don't have eyes on. There's nothing worse than the marketers trying to market something based on pictures from the designers that have vastly changed by the time they go out or that they don't know whether it's going to come out on the right day or not. So they've actually got a functional working version that they can share with some customers. They can start getting videos of it working. They can get testimonials from early beta users. And then they can spend, whether it's two days or six days or six weeks or six months planning the biggest, bangest launch they want. They can then spend the next however long they want to launch their hard launch, and then that goes out. And in that period that they're doing that hard launch development is cracking on with their next thing. And by the time that they're done that marketing is then, "Okay, great, what have you built? We're ready to work on the next thing." So you're just separating soft launch from hard launch, so that you don't have this stress of trying to line up to completely different types of projects, your marketing projects and your development projects, which is where a lot of those things fall apart. Got it. So kind of the basic premise is roadmaps or timelines sound great and awesome. Everyone would love to know when things are going to be done and if it worked it'd be great. Oftentimes, they're all made up, they don't work, you don't hit deadlines, they're always missed. So instead of promising dates for everything you're doing, you're better off generally just giving a sense of, "Here's what we're going to work on now. Here's what's coming up next." And then for the things that really need a date, we're going to put dates on those things and give it our best shot. Is that [inaudible 00:31:29]- Yeah. That's absolutely right. If something does have to have a date, we don't live in la la land, if something has a regulatory date, when GDPR came down, everyone had a due date on the roadmap, because if you didn't hit that date then you were going to be in trouble. Sometimes you might have dates that are tied to things like the Christmas rush, or if you're in education it might be like has to be out by the school year. At which point, in order to reach something by that date you have to put in more project planning work, as in you have to plan out ahead of time, you have to put in more buffer time to do that. And generally you have to plan to get that thing done well before, so that you can have a soft launch before and make sure it works and do some iteration and fix it before the actual full-on launch happens. Because if you leave it too late, it's going to go wrong and you're going to miss the deadline. If you did that for all of your launches, you're just going to end up either cutting quality, because everything's just going to be big crap cause it's going to be pushing it out the door last minute. Or you're just going to end up spending so much time trying to plan things to the nth degree that you're just going to move super slow. This is why you end up with teams who are really big but can't deliver worth anything. Where compared to these tiny teams, who are just out delivering them and just spinning things out the door, they're the ones who aren't spending all their time going, "Are we certain this is going to deliver? And how many hours is this going to take you? And let me go talk to this person, find out how many days it's going to take him," and back and forth and back and forth. They're just building, and it goes faster.…

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