Lenny's Podcast: Product | Career | Growth
00:16:47 · Andrew Ambrosino, S1
[00:16:47] S0: Yeah, I mean, I totally hear you. Let's give it up for the human brain. [00:16:50] S1: For now. As we were getting ready for this, you said that you were listening to the episode with Jenny who does the head of design for Claude Code and Cowork and such. And she had this whole kind of thesis that the design process is dead. There's no time for design. Things are moving too fast. Just build now and design is kind of steering things as things move along. You're implying you have kind of a different perspective on the design process. [00:17:13] S0: We probably agree on a lot of this, Jenny and I. I wasn't a fan of the design. The design process proper, I agree with her take that it is dead. I genuinely was not a fan of this process before AI. [00:17:27] S1: Can you describe the process real quick just from people think about the design? What does that mean?
00:17:31 · Andrew Ambrosino
[00:17:31] S0: Yeah. So I mean, when I ran a startup a number of years ago, we would do design hiring. And there was this sort of snarky article that came out about the case study factory. And it was like mid-SERP era stuff and it was that designers were being taught about this process and valuing that above all else, above all outcomes even. And if something went through this process that two things were true. One, it would be good and the process would guarantee quality and guarantee impact. And also that if something, the thing was good if it went through that process, even if you don't like it and nobody uses it. And it's like the process of user research and the divergence and the convergence, it's the right framework. It was always a little academic. But I think this is really exposing some areas where it falls down, especially because of the speed of implementation. And once again, that process is sort of predicated on the assumption that implementation is expensive and that you can really only afford to build once. And so you need to fully, exhaustively go through the problem space and the solution space before implementing. And then we saw with Figma and Origami and all of these tools that you can fast-forward some of the insights by pulling interactive prototypes earlier into the process. That you can simulate production. And there ended up being sort of a meme about executives just being like, "Well, can we just do a prototype and then expect it to work?" But this thing was real that this became part of the design process proper. We pulled prototyping into that. The problem now is that you can pull all of the implementation into that and there's a mismatch between, I think a lot of assumptions. Again, you see this fully polished prototype that looks like it's ready to go out the door. And enough people at a company see that and they're like, "Can we release this now?" But the appropriate, we're actually in that early design process stage and nobody's just saying that. This is where we are with a bunch of multiplayer exploration. 90 people will have this idea. It'll look really polished, but it's like, "No, this is actually..." That's the design process now. Tying the design process to mediums, media, that's the scary part. It's that designers have more tools now to do this process with.
00:20:05 · Andrew Ambrosino, S1
You can put stuff into the current product and you can A/B test it or just use that as a prototype. Many companies right now have this idea of a baby version of the product. Like baby Cursor, you've seen this on Twitter. We have baby Codex, a dramatically simplified code base that approximates all of the interactions of the production app. And therefore is a lot quicker to vibe code over. Because you can be like, "Well, what if the sidebar worked like this? Or what if a pane came in and had a group chat here? What if X, Y, Z?" That's a huge tool that's part of the design process. So to say that the design process is dead, I feel like it's both true and false. It's that if you are tied to the tools and the exact day-to-day specifics of the process, then yeah, it's dead. You're not going to have a good time. But to throw the process out completely or throw the overlay of the process, the like, "Hey, we are at this point in the process." That is still more important than ever. [00:21:11] S1: It's really interesting because you have a background in every function. If people look at your LinkedIn, it's like engineer, designer, product manager, founder. Now you oversee the desktop app. And I think design is not under your purview, is that right? Is there a separate design team or are they under your? [00:21:25] S0: Depends on the week. [00:21:26] S1: Okay. [00:21:27] S0: We worked very closely together. We believe in, while sitting together, being embedded. Reporting line, I don't know. [00:21:35] S1: They shift weekly. What does the design process look like on the Codex app?
00:21:38 · Andrew Ambrosino
[00:21:38] S0: Yeah, there's been a lot written about role collapse, existential role collapse. There are no roles anymore. We haven't seen that. We have seen more role collapse in the Codex org than I think other parts of the company and other parts of the economy. I think part of this is that this was a technical product for engineers. And so our designers speak engineer, our product managers speak technical language and write code. Alexander has a master's degree in computer science, which is, I do not have a master's degree in computer science. So we've seen a lot of role collapse. And I think that one of the ways that we describe how the groups work together is that there's significantly more overlap in the roles than there used to be. And everybody's sort of defined less by the fence and the boundaries of where design stops and engineering starts, but more the average of where they're working. So if you average up all of the things that somebody on our design team does, there's plenty of code writing things. There's plenty of things that are product work, but on average there are dots over here if you draw it out on a diagram. And this sort of speaks to the process too, especially because the entirety of the Codex app has been informed by the dog fooding loop. There is a desire among all of us to try to do as much as possible in the app even when it's not the best tool, so that it can become the best tool. And so a lot of design we all work on by using the app and say, "Okay, what's broken about this?" This is a whole thing we do, which is that we often don't improve our process so that we can make the product better to do it, which is a deeply uncomfortable place to be in. But week to week, it's changing.
00:23:30 · S1, Andrew Ambrosino
[00:23:30] S1: I love this point so much that what are you? It's your role is the average of what you spend your time on. If most of your work is PM-y work, then okay, you're PM for now. If it's engineering, you're an engineer for now. I feel like, was OpenAI the first company to call people member of technical staff? [00:23:46] S0: No, I believe that this might've started with Xerox. First company I interned at, it was a company called Upthere, did the same thing. This has been around. But it's much more common now, but it is kind of a tradition in research focused companies, right? [00:24:01] S1: Okay, got it. So it emerged from research. But I feel like it's such a, I don't know, sign of where things might be headed, this idea of we're just going to call everyone member of technical staff, your function isn't set. You're not in this bucket of the PM org or the eng org or the design org. Do you feel like that's where we all head long-term? Do you feel like functions will continue to exist? There's still the PM skillset and the eng skillset and the design skillset. And people are, "I'm a designer." Or do you think this is like, people call it builder. Do you feel like there's this collapse coming where everyone's everything and that's just the future? Or do you think we're going to continue to be mostly divided up in quadrants?
00:24:38 · Andrew Ambrosino, S1
[00:24:38] S0: Yeah. There are some things that I'm afraid of. And I think that some companies like to be very extreme about getting onto the bandwagon of whatever people say is going to happen. And I think part of the danger in eliminating the concept of roles is that it can dangerously eliminate the idea that things are specialties with knowable best practices. I've heard a lot of companies be like, "We're getting rid of the product role," which I think is by the way, a terrible idea. And everybody's just going to be a builder. And then what happens is this whole discipline of product that's been built up and has real best practices, real things that have been tried and failed, and real processes, that just gets abandoned. Because people are like, "Oh, I wrote some code." That's not a great place to be in. I think that the boundary of so and-so, this isn't your lane. I welcome that part going away. But there's a balance here where it's like not everyone can work on everything, for one, both in terms of breadth and depth rate. This is why managers are not going to go away. Not everybody can work on everything. And also every discipline has a skill component to it, which I think a lot of engineers are guilty of not recognizing that, "Well, engineering has a skill to it. It's writing code and other roles are just people vibing." It's like, "No, that's not how it works." Yes, you can use Excel, but you cannot work on the finance team, that kind of stuff, right? [00:26:24] S1: Yeah. I think there's also just like, "Do you want to be doing this work?" [00:26:27] S0: Yeah.