Lenny Rachitsky: evaluation

Transcript context

…Before I got there I think there was a little of like, "Design is just going to sit with Design and not necessarily work in close proximity with engineers and product managers, et cetera." And one of the things that I believe as a necessary part of building a high-functioning organization is that, one, building together is important. So having engineers, and product managers, and designers be together, have shared goals, and align on that and be able to just look over each other's shoulder and talk about things, is important. So sitting together is important. However, that Thayer thing that you're talking about actually was like something that I was very devoted to, which is bringing Design together at key moments multiple times throughout the week to also build a community in Design. Like Joebot at Airbnb once said, "It's like, well, what T-shirt do you wear? What team are you on?" And I was like, "You have two T-shirts. You have the Design T-shirt and you have the Marketplace T-shirt, or whatever cross-disciplinary team that you work on. Because both are really important communities to build for slightly different reasons." So yeah, Thayer was a good spot for that. Zooming out a little bit, I think the elephant in the room a lot of times with design is this idea that I'd say most PMs, most founders, intellectually understand the value of design, understand the value of high quality. But day-to-day it's often not actually prioritized versus new features, new product launches, partly because the ROI is just really unclear. If we spend another month making this more awesome and making this even more amazing design-wise, experience-wise, what is that going to get us? Clearly, at Airbnb design was highly prioritized. At Stripe, from an outsider's perspective, it clearly is. I'm just curious what you've learned about how to make the case for the ROI of design and just how Stripe, and Airbnb, and Lyft have done that. It's a great question, and I think this is like an age-old question that I don't know if will ever go away, and probably because the quality bar keeps evolving, keeps rising. But I think first to kind of level set before we dive into that I would say that there are levels of quality. There is the, does the thing work? Does it provide some sort of value proposition? It like executes on its job. That's baseline quality. Next is that, does it do it exceedingly well? Is it error-free? Actually, maybe that's not even exceedingly well but just error-free and it actually works in a well-rounded way. Then beyond that, like level three, level four, level five, does it exceed expectations and it does something that you weren't even seeking for as a user? And I do think the levels of quality should be based on user expectations. I don't believe that there are disciplines that just don't care about quality. I think it's more about that prioritization and kind of like what you talked about is just like, is it really worth getting something to that exceedingly well state or is it, what about just like another feature and being seduced by the chase of another feature versus actually taking your features to a level of being great? That is hard. And I get it when you look at your user base and they're all shouting from the rooftops for this additional feature. Of course you're going to want to prioritize that over something they never asked for. Then the other thing would be you end up with like you've got three things that you could possibly do to make perhaps the next stage in your product development. Two of them you know you can measure and they're going to line up to business goals, and one of them you can't. Of course that's going to be enchanting to want to go after the things that you can actually measure, you know that they're going to have that impact. But the companies that know that quality is non-negotiable, it is a long-term necessary aspect of what they build, don't play that numbers game. Or what they do is they recognize that it is absolutely functionality, but the quality of those features that is actually going to get to great usability, desirability in their product. Actually, I think it's kind of like an analogy for going to the gym or working out. I don't know about you, but literally every time I think to do this, there's a fight in my head of like, "Ah, do I really need to work out today? Is this one day going to give me six-pack abs?" Like, "Of course not." So like, "Why go? Why not just skip it today?" But of course then at some point, hopefully, I realize that it's like, "Well, if I skip it today, what's to stop me from skipping it another day?" And really in the belief of that these things, it really does add up to a better outcome in the end, and so a longer, healthier life. So hopefully I can get myself together and go to the gym. I do think some of the best companies on the planet think that way.…

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