Ex-Meta VP Reveals His Top Lessons from 25 Years Leading Product Design | Jon Lax (Meta)

teams would come to me with we have to make sure there's Delight in this product and I'd be like yo you haven't even shipped anything yet like you haven't even figured out like what your product is and you're busy trying to figure out the physics of the like easing curve of this like button press and I'm like that's no like we don't even know what this product is yet like and I've always really loved the idea that you first start with making something that's useful and necessary like should this exist in the world is it useful right and if you can get that nailed down okay now make it beautiful like now like take the time to really make it beautiful often designers will jump to the last part before doing the first like this thing people can't even use this yet or no one's using this yet and it's not that the easing curve on the button is going to make it more useful I can tell you with high certainty that a lot of the things that designers care about the larger populations don't care as much about that doesn't mean you should go make badly crafted products but you have to figure out where you're spending your time and energy and when you're spending it there I spent a lot of time in my career trying to get that last 10% and learning that often it didn't add that much to people's satisfaction with the product and I've actually dialed it back a lot and actually found i' made better products faster cuz the thing is it takes time to do all those things and that's time that your product's not in mark market usually all right welcome

everyone my guest today is John LAX former vpf design at meta John spent over eight years leading design teams on projects from meta reality labs to events to search to I'm sure a lot more and before meta John ran his own design firm for 12 years I've been reading John's blog and he has many great hot takes that ex actually chat with him about so yeah so welcome John hey Peter thanks for having me all right so let's

start with one of your hot Tis so you wrote a blog post about how Vision decks and North Stars have little value compared to solving known problems can you share more about that sure I think that if you are a designer or you've worked with designers you've probably at some point in your career or maybe multiple times in your career seen these like northstars Vision decks they go by a bunch of different names but effectively what they are an attempt to try to think about a product in the future and design it you know in the automotive industry we have concept cars are kind of that idea right where they designed hey one day we might build a car that does this and in product design and in design in general there are um a lot of times where designers are asked to go and like oh go build us a go design a Northstar and designers run off and they spend some time in a room and they did you know they design oh here's what our product will look like at some point in the future and they are I have to say I'm gonna C they're super fun to work on like in my career I've done I couldn't even tell you how many of these and it is fun to just design without constraints to imagine a future to imagine you know what your product could be uh and you just get to design these things the problem is that they're not that effective right um typically once you design it people look at that and go that's really cool and then they just go back to their job and there's you know like they don't really go anywhere and so I became increasingly disillusioned with these as an effective tool in terms of you know showing your engineers or your PMS or even leadership hey here's what we should build and there's a few reasons for why I don't think they're that effective the first one is when you're going to go do a North star or a vision I think the question you have to answer is okay this thing that you're going to design like when might we be able to build this is this something that's like 10 years off or is it like a 12 months off right like what time scale is it existing on and often designers will go design these things that are like three to five years in the future like sometimes Technologies need to be invented for their design to even exist in the world and that's really tough for those to become effective because it's like okay cool you designed this thing maybe when we invent all these Technologies or maybe when our product is more mature we could build this but we can't build this right now so that's why engineers and PMs just kind of go back to doing whatever they're doing the other thing too is the culture of the company that's showing it in some cultures these North Stars or these Visions are more effective because there's something culturally that allows those artifacts to be internalized and used but in more pragmatic cultures especially I think in technology cultures they sort of see these things like the organization the company looks at these videos or these designs and they ah yeah this is really what we do yeah and so they just ignore them and so you know that's another reason why you know people just don't they don't really work and so where I started to so what was happening with the design teams I was working with is that they would show up with these North Stars or these visions and they just they spent a lot of time a lot of energy a lot of emotional energy also like not just time and like emotional energy into these things and then like nothing would happen and I just said hey let's just stop doing these let's actually like focus on things that are more like what do we have to solve right now you know work through right now what are the problems we can solve nearer term and that actually was much more effective maybe not as fun but more effective and so I just didn't like them because I just didn't see them

working so like what is the right time scale to think about solving problems because if you are too tactical you know every quarter like tactical otherwise it's like too Visionary what's the right time skill here yeah so I this is just the way I think about it and you can kind of break it up however you want so I tend to think of different time scales so the kind of nearest time scale is sort of zero to two weeks right or maybe zero to four weeks and in your in whatever company you work in you probably have a rhythm like whether it's a release schedule so a lot of companies at least in the software side do like two week release schedules maybe it's monthly something like that that's kind of the smallest time scale unit where you're just trying to get to the next brdge cut or the next you know the next push then you kind of move out uh to the you know one and that's sort of like work that's sort of four weeks maybe as long as a 90 days you know you can kind of divide it however you want and that's work that just takes a little bit more energy it's not like for the next Branch cut it's not just a bug fix it's a bit more substantial that you could do and then you start to move out maybe to a six Monon you know time scale and you keep going out and you can keep going six months to 12 months and then a year to three years to five years and so if you think about each one of those time scales and work this game down it if a team is working just in the zero to two week time scale they're just running to keep up right they're just trying to do like that and the problem when a designer especially a designer is just working that close to the backlog is you're kind of working like with your head down like it's like walking while looking at your feet right like you can only see a little bit in front of you I think that as you start to work on longer time scales right so just going back to what we talked about in terms of these North Stars those tend to be things like oh in three years our product will be able to do that well that's looking really far into the Horizon and that can be difficult as well because as I said you start designing you know really far out and that can get a little untethered from the time scale so what I like personally is I think for designers most of your time is probably spent somewhere between zero to four weeks maybe six weeks so you're doing work that's probably going to ship inside of that time frame so it's not just like oh what do I have to do today push it out you can stretch it a little bit I really like it when design teams kind of are operating a bit ahead of their engineering teams so if your engineering team is just trying to get to the next Branch cut I want the designers to be maybe four to six weeks out ahead of them right that I think is like a real sweet spot for teams because they're able to take some time work through some Concepts but they're not so far out that they're doing work that's completely untethered from what the uh Engineers are doing or the PMS are doing I will say one caveat if you're managing teams and you look at the work they're doing and all of the work like you look at a designer you say okayy what are you working on and all of the work is actually in the zero to two week or even maybe behind the backlog meaning the engineers have coded a thing and are waiting for like a front end that's a bad place to be right because your designers are just running to keep up with the work and if you know if you're on a design uh if you're a designer on a team where you're the only designer and there's like 20 Engineers they're going to like outwork you right you're just going to be you know running to catch up and I think that you know a lot of us have been there seing teams like and if you're a manager you're like oh gez this team needs more designers you need more capacity to get out ahead of the engineers a little bit I do also like while the majority of the time that design team is working is kind of four to six weeks out ahead of you know the engineers I do think maybe once or twice a year the design team should stop and they should do work that's maybe hey where do we want to be in a year right like take a week or two and do not so much a Northstar Vision but you know just look lift your head up and look out a little further on the horizon and then go okay this is cool what do we need to do now in the next four weeks to start to move towards that point on the horizon that I think is really healthy and I've seen that work really well yeah because if you look at a year from now some part of that will probably still ship to customers but if you look at like three or five years from now it's purely like it feels Pur like an exercise to convince the to like impress the CEO or something like tot VP yeah and I do want to you know say that like sometimes there is about a In some cultures in some instances in some situations a little bit of an executive theater is required right like you do need to kind of get people excited about a thing but I think recognizing that's what it is just like to use my example of the automotive industry the concept cars right the concept cars are there not because the car company actually thinks they're going to build that car they're there to sort of excite the press to create a moment to you know inspire a little bit to show kind of what they're capable of but the idea that going to that car is going to show up you know in the dealership 12 months later Doesn't Really Happen got it so along similar

lines I really like your phrase the three Miracle problem like I feel like a lot of companies see Shiny thing like shiny Trend they like they want to fall more into it and never work works out so like can you talk about what do you mean by a three Miracle problem yeah so I was this came up where I was teams were coming in design and they were showing me they like oh we're working on this problem and the problem was often something like okay when our product has um hey we're try to Des okay let me give you a really good example AR glasses right AR glasses is you know everyone knows that meta Apple people are working on AR glasses and it's pretty easy to imagine that in some future if you're wearing a pair of glasses that can project UI or things into it that there is a risk that will become very cluttered right and so there's a lot of videos out there of like oh all these ads being pushed into my field of view and it's cluttering up and so you'd have design teams coming in and starting to solve that problem and be like oh how would we do this or that well hold on a second we don't actually have a like we don't have a pair of glasses that work we don't have any users for it right we don't have the content at that density that would create that problem so you actually need three miracles to happen before this problem exists you need to create the glasses you need to have content that goes into them and then you need to have too much content that is crowding your field of VI hey let's go solve the first miracle before we worry about the Third one right and so the team was just jumping out ahead of itself and I'm like that's not a good use of time or energy right where they're too far out on the time scale they're trying to solve problems and there's a whole bunch of preceding problems that have to be solved before the problem they're solving can even exist in the world right yeah and so when I look at things I'm like hey is this actually like a problem today or is this some potential problem that requires preceding things to actually exist before it's an issue and if you see that you got to stop that work because it's like hey this just isn't valuable work because the other thing too is the idea that the team has accurately predicted right each step in that they're going to get the right solution to that problem today is very low yeah exactly like the first two Mar calls might not even come true right like you'll see in startups they'll like oh we have to we need a design system it's like hey you don't have a product yet you don't have users you don't have enough designers like Design Systems are meant to help you scale like that's a like solve that problem after you actually like when you have it right and but they try to get out ahead of it too soon yeah I think a lot of is kind of like this intellectual exercise where like you know if I'm a good designer I need a design system I need to have a three-year Vision like it's a lot of like right it's like intellectual stuff as opposed to real problems well and you know as an industry and I'm speaking specifically with the design industry are design industry sort of fetishizes all of that and so as a designer you get a lot of credit from other designers when if you show up and say hey look at this design system I created or look at this you know brand system like little you know micro interaction detail Isn't that cool and other designers will go man that's so awesome because we all love that stuff right but it's often it's not actually all that valuable to the product or to users in that moment and I think that designers get can get very distracted by those things and spend energy on them when it's not the best use of their time so then let's

kind of skip to the probably your most controversial point which is for designers at is you wrote this post called Delight comes last right and you know it might sound crazy to a lot of designers maybe tell me more about that yeah so I mean this is all kind of related right like when do you solve like what problems do you solve when right like everything is kind of a I've also written this thing like everything's like a prioritization problem right like it's not that you don't want to like just quickly going back to the augmented the AR glasses thing like it's not that you shouldn't solve that problem but when do you solve that problem right and so delay is another one I would sit in you know teams would come to me with you know designs for like I said small like oh look we have to make sure there's Delight in this product and I'd be like yo you haven't even shipped anything yet like you haven't even figured out like what your product is and you're busy trying to figure out the physics of the like easing curve of this like button press and I'm like that's no like we don't even know what this product is yet like and so I've always really loved the idea that you first start with making something that's useful and necessary like should this exist in the world is it useful right and if you can get that nailed down okay now make it beautiful like now like take the time to really make it beautiful but often designers will jump to the last part before doing the first you know conditions like hey this thing people can't even use this yet or no one's using this yet why are you and it's not that the easing curve on the button is going to make it more useful so don't do that right now and so once again I think I would tell designers like this isn't the time to worry about this right or the other thing designers do is I think that we have a tendency because we really value those things to overinvestment there is you know some I can tell you with high certainty that a lot of the things that designers care about you know larger populations don't care as much about that doesn't mean that they're not that you shouldn't do some of them and that you like that doesn't mean you should go make badly crafted products like that's not what I'm saying at all but you have to figure out where you're spending your time and energy and when you're spending it there and I do find that designers will do it too early they'll do it too much I spent a long a lot of time in my career trying to get that last 10% and learning that often it didn't really matter um in the sense that it didn't matter that the product it didn't add that much to people's satisfaction with the usage it didn't add that much and I've actually dialed it back a lot and actually found I made better products faster because the thing is it takes time to do all those things and that's time that your product's not in market usually and that's not good yeah because if you're in the market then you're learning at least right you are but what about like I mean there's this trade-off right there's trade-off between I guess quality speed to Market and scope sure and you have this definition of like MVP or you know minimum level products like I think you have a good definition of this like what is the r scope to deliver into the market so yeah first of all if there was like a precise answer to that life would be a lot easier right like the fact is that there is like there is an art and a debate here about what is the right level right so if you were to talk um to some people I'll call them PMS but I don't mean to paint all PMS with the same brush but you know there are people who believe that get it out fast iterate as quickly as possible you don't have to be right you just have to learn as quickly as possible and like iterate the hell out of it and get it to be good enough there's other people who believe no you should really craft it and only release it when it's at some level of quality but at the end of the day both of those are very subjective judgment calls quite frankly and I think that in either direction it's bad right if you wait too long it's bad and if you push it out too early it's bad and finding the sort of Goldilocks moment is really tough MVPs in our industry became a I would say on the side of pushing stuff out too quickly MVPs became this like excuse to do to put crappy things into market and what I mean by that is you would look at something and say oh I don't know this doesn't seem really good and you'd go and challenge the team that they oh no it's just an MVP don't worry yeah that's what PM say yeah it's just an MVP right and I got in the habit of saying okay what do you mean like by MVP and they would say oh that's a minimum viable product I'm like well I know what it stands for like that's not what I'm asking like how do you define an MVP and they would kind of give me a Blank Stare usually because they well it's a minimum viable product we just need to like learn like there be some and it was really just used as an excuse because a lot of PMS get rewarded for shipping it looks like it's that classic like is this progress or motion it's was like and it was mainly motion I was like look we shipped the thing and of course designers were getting torn up about it because often what went out was not crafted at all it was just kind of what could be built in that two week cycle or that four-week cycle and so what I said is I said look like when you say MVP like how do you define it mostly need have a definition I said okay well let me give you a definition and my definition of MVP is a product that can be shipped to a statistically significant group of people that tests a single hypothesis right and either proves or disproves a single hypothesis and it tells you what to build next and inside of that definition so if you take the we kind of break it down really quickly the first part is it has to be shipped to a Sally signant group of people meaning you have to put it out into the world and people need to actually use it right and you can't just like send it to 20 beta testers and like oh okay like they loved it you know call it a day like that's not a group of people it has to have a hypothesis it has a point of view hey we believe this and in using it it's going to either prove or disprove itself we have this thesis this hypothesis people want X or people have this need and when we give it to them we're either going to see do they or don't they right and so it has to have that this was another problem that we saw with MVPs people ship MVPs and I say well how will you know if it worked or not and they had no idea they were just trying to get into like they thought somehow miraculously they were like we I saw products go out within without instrumentation so there was actually no data and I'm like well you rushed to get this out you forced you know the designers to ship this thing and you don't even know if it's good or not right and so you need some sort of data you need to ahead of time agree on whether what usage will we see in the product that will tell us whether our hypothesis was correct or incorrect right and so that definition at least hopefully gets a team to agree upon what they're building why they're building it how they will know if they're building it and the nice thing is that if you do this correctly and you put it in Market what you may learn is no one wants this but you want to learn that as quickly as possible right and the one thing this is Mark rapkin who's a VP of he comes from the engineering side and he always said about MVPs which I repeat I love this quote is he's like hey the one thing I know about MVPs is a shitty product performs shitty right and so you know I think that's really important it's like look you can't release a shitty product and expect to learn anything from it right and I think that's really

important so I really push teams to first of all have a diff when if you want to use term MVP totally cool no problem does everyone agree on what an MVP is right and often they don't and often I think well we can talk also about minimum lovable products designer concept of an MVP is very different that maybe an Engineers or pmss or a marketing persons or you know maybe even leaders and I think that it's really important that when you go build anything everyone has to kind of have a shared understanding and agreement on what we're building and that often is missing I think that what designers did was in order to counteract the kind of abuse of MVPs like the they said okay well we're going to create a whole other thing called minimum able product right and if you go online you can see the diagrams of what that means and that I viewed as really an attempt to counteract the kind of you know bad behavior on MVPs the reason I never loved minimum lovable product is because I actually think it's almost too high a bar for some of these things like a lot of products we use quite a lot we don't really have to love them right it's that's not a necessary condition for a product you know to exist in the world and so I always found the lovable part just a little too high a bar to put on especially early stage products and to my other point about delay comes last I think some of those things come later in the process right and I think that if you burden something with that too early it can bog a team down you get in debates about how lovable is it you know and that's a hard question to answer yeah no I think you're right I think a lot of it designers reacting to like these other incentives that PMS have like you know to try to get promoted or like you know try some number and you know you work that meta for so many years you know it's

kind of Switching gears a little bit reflecting on your time there you know what were some traits that the best designers and PMs had like who kind of grew their career the fast fastest head is it just I'm sure it's not just trying to like hit some qu metric each time right there must be some traits that you have observed so the number one thing I saw in high in the highest performing teams is that they rode together they were all rowing in like together if you've ever seen that's the Olympics right now so like if you watch the rowing team right like the only way a rowing team can get there is if their Strokes are exactly synchronized and together and the teams that underperformed or had chaos one person would be like you know rowing backwards the other person would be like each the engineer PM design were all like because they all thought they were doing different things they were not they did not have a shared objective

have a shared understanding I often uh I have a on my site I have a an article blog post however you want to call it called the definition of done right like how do we know if we're done here like do we have a shared like Finish Line and almost without exception the teams that did well they if I went and ask them I'm like what are you trying to do here I'd get that answer and then I went to the next person and said what are you trying to hear I would hear the same thing or pretty close to the same thing got it on the teams that weren't functioning i' asked that question of eight people and to get 10 different answers right that's when you knew like okay who time out we need to get everyone together here so I think the first thing for teams is are they rowing together right are they rowing in lock step and I think that where the designers and PMs and Engineering that Triad when those three people all had agreement on what they each accomplishing they all went off into their own disciplines and then started to work towards that in unison that was really great and so PMS that took the time to talk to their design partners and say okay what do you think we're doing here or and the designer saying to the PM okay what are you looking for and okay what about if we did this and then engineering contributing and then they all kind of go okay great you know break that was really good I think when I first got to meta the actually the Aaron carambula who's now at eBay he was working on profile and him I could see him and his pm and end partner they were at desks that were all you know basically side by side or kind of back to back and they would constantly just turn around and be like hey can you look at this what is this what you were thinking and there was a continual communication and Alignment going on and it was sort of always constantly course correcting it wasn't perfect but they seemed to move forward in unison really well and then of course the teams that were dysfunctional and I think this really happened as we started to have more people in different places because now it becomes harder for everyone to collaborate have shared goals it became much harder to do it and that's where I started to see things drifting or getting out of sync and that's where problems really started to emerge when you say definition of done is it usually lining on like solving a customer problem together or like agreeing on what the me metric is or I guess depends right what the team how we know if we're done right so I think that let's use the MVP as an example let's for example just say okay hey we're building an MVP and you asked the PM on the team okay well how will you know if we're done to ship this thing do they okay well I'd want to see a and c and you ask the engineer would they say the same thing or roughly the same thing and with the designer and I think that what often happens with definitions of done designers want their definition of d and it's different than maybe what the PMR engineer in definition of done is right so the designer wants the lovable product they want the Delight they want all that it'll be done when we have this well-crafted you know really beautiful thing the PM may be like oh no we'll be done when we meet this Branch cut the engineer may want some sort of performance you know I'm not shipping this until we meet this objective bar performance so each in that scenario each person has a different definition of done that becomes really hard you have to figure out how those all align in order to do and who gets to determine what the definition of done is right when is it done for and that's not completely done when is it done enough for this Milestone or this ship date or this launch date and I think that a lot of teams just don't take the time to actually align on their definition of done and it can be anything your definition of done can be like as you said it could be completely objective measures right like oh we're done when we ship it to a test group or the definition done could be subjective so for example you know I think at companies I think Apple's kind of the classic one the definition of d is when some VP says it's done yeah like you know just uh big event or something or yeah or maybe the definition of done is it's done what's done is what we can ship for you know WWDC or for a press event or something like that and so I often once again when I'm debugging teams that aren't working eight times out of 10 it's because they don't have an aligned defition them done they us think they're building something different right or you know they ship something and the designer is really unhappy because he like well it wasn't done it wasn't ready it's like well okay that's your definition was that like did they did not to put it on Zach did Zach have that definition or did the PM partner have the definition and often that's not what's going on there got it

how about your framework for like dude there's always crazy career ladders and boxes to check uh in these big companies and like I think you simplify it down to I think autonomy and ambiguity but I also want to ask you there's also like I feel there's a lot of pressure for high performing ICS to like hey I need to manage like 10 designers I need to so how do you what do you think about all this like how do you yeah so I think that you know at meta at the large companies there's a very sort of sophisticated complex Performance Management process right the PSC process is a lot of work and there's a lot of job ladders there's a lot of expectations documents there's a lot of both written and Unwritten things around managing career and in fact there's so much of it starts to eventually contradict itself and so it becomes really hard and one of the reasons why designers think the only way to kind of move up that ladder is to just manage more designers is because headcount or how many like recursive management chains or head count that's a really simple like oh I have 30 people reporting to me and it kind of cuts through all of the noise of the expectations documents any of that right so it's this like simple score card or scoreboard that people use because the alternative was like really confusing and hard to do and so one of the things that I did was I said okay this is too confusing if you distill it all down everyone's career is kind of defined just by two axes autonomy and ambiguity meaning how autonomous do you operate and how ambiguous a space can you operate in autonomously so for example if you take an inter right someone who's in college those people can't you're not going to leave them alone for six weeks and then come back and see where they're at because you come back they're gonna like spun off the planet right and you can't give them a super ambiguous you know problem to go solve you need to give them something that's very defined and say okay I need you to design this very specific thing and then going to come back in three hours and they going to see where you're at right and so their ability to operate in ambiguity autonomously is quite low you then take someone you know much more senior in their career and you can give them a really hard problem and leave them alone for a long time when you come back or when they come back to you they've probably made a lot of progress on that problem and I think that when I looked at all of the career expectations of I could pretty much distill it down to like how much ambiguity can you give this person and how autonomously can they work through that ambiguity and if the answer to that is we could give this person the hardest problem in the company that has no answer and in eight weeks they will make progress that's a very senior person that's a person that you want to reward and if you look at someone's impact almost in every situation they worked with a lot of autonomy on a very ambiguous problem now that could be a designer with high craft who's able to solve really complex UI problems in novel ways and they you know they did it on their own right they just went off and they figured it out or they off the small group and figured it out for a manager it might be that they were able to drive their team to deliver something without you know banging on my door every two hours right I was able to hey go do this raise your hand if you need help and they go and do that and so I always kept going man when I'd be in these PSC which is our which are met as the Performance Cycle like things we'd be doing these meetings and the debates would be going crazy I would often be like time out time I how ambiguous was this and how autonomously did this person do it explain that to me and it would just you know kind of focus everything down and we were able to also compare you know people being like well okay we heard this person how they work through that problem is this other person's is that problem as ambiguous more ambiguous less ambiguous were they as autonomous more autonomous less autonomous and you know that's it and I think that when young designers come in I would do orientation and I would draw you know that like you know autonomy ambiguity and then just a line that went like this and I'd be like you're here you're the only way like your career is going to be up here on the engineering side job carback if you don't know is the you know legendary he's an engineer right you could put that guy on the hardest engineering problems ever and not just leave him alone he wants to be left alone and he would solve him that's why he was like the most senior IC engineer or one of engineers at meta when he was that right design is the exact same and so I've always found that a really helpful framework I give it to people and it tends to work not just in metab it

anywhere and how do you work with your manager leadership chain to go up on this curve right I because you got to prove yourself the problems that they're giving you and then maybe you ask for more like difficult problems or maybe the manual just give it to like yeah I mean this comes down to so in managing you have to give people opportunities right and you have to kind of throw them in the deep end of the pool and see if they can handle it there's two types of people there are design are we talking about IC or managers let's just talk about ic's first yeah okay so for ic's I think there's one class of I's who literally seek out ambiguous problems like they actually find them themselves they're very proactive they see something not being done and they're like hey why is no one working on that and I would say that those ic's are incredibly valuable and will rise up very quickly because they F they sort of hunt down things they see the things not being done before being asked that is a real behavior of autonomy that is a significant merker of autonomy then when they find the thing whatever it is can they make progress to take it from the ambiguous to the known right from the unknown to the known and those people are super valuable they tend to get promoted very quickly they find problems to solve they solve them they don't need a lot of handholding there's then but that's not everyone and nor should it be there's then people that you have to like say hey I need you to work on this thing and they go and they grab it solve it and they don't need a lot of handholding and I think for managers the art is getting out of the way of the people who proactively find these things and giving them the space and the opportunity to go and pursue them right and then for the people who you think have more ability more um upside you sometimes have to give those to them and say hey I need you to go solve you know this problem and it's really hard and so I think that both of those instances exist but these are for managers this is where you can really help people grow in their career sometimes by giving them those opportunities um yeah because otherwise if you just practically go solve it especially in a big company like maybe some other teams working on it but they're doing like a shitty job and then you have to there's like a bunch of like don't step on my toes kind of things right yeah I think but once again I think that's the art of the ic's ability to identify a problem like I think the best ones find like hey why is no one working on this thing like you know in large companies even in small companies so many things fall through the cracks like there's just there's more work to do than people to do it and so I think good I see those things and they grab them and they run with them the thing you want to be careful as a manager is to grab things that aren't worth their time there's a great I don't want to go too deep in this because I know we're run our time and maybe we'll get a few more questions but there's a Jim burkdale who was the CEO of Netscape in the 90s if you don't know what that is go look it up he was sort of known for a lot of py kind of clever sayings he had a saying which was if you see a snake shoot it like and if and the first rule is if you see a snake shoot it second rule is don't play with dead snakes and yeah the point of that was like hey if you see a problem like get rid of it but don't spend a bunch of time playing with the wrong problems or dead problems right and so I think there's an art to for those ic's but once again ic's who do it well who always identify the right problems to go solve super valuable promote them reward them other people get them to that place got it okay I just have two more questions to ask so you know there's a lot of angs

right now with figma coming out of AI tools and lot AI stuff that like you know am I gonna lose my job or like is the industry GNA collapse a little bit and like what you have to say to those folks who kind of feel Ang so I have a theory and we'll see if it I have a hypothesis so I don't know if it'll be true that we may have reached not I mean overtime design jobs will continue to increase but we may have reached a kind of peak design job era meaning the hyper growth of design over the last 10 or 15 years depending where you want to kind of Market from we've probably capped out at that and we're going to see a decline in that and one of the reasons for that is the hyperscaling era is at an end at least for now in technology another reason for it is that the tooling is getting better meaning we're getting more efficient and also Engineers are seeing this as well where tools allow a designer to be more efficient right and do their job so let's just imagine for a second the figma AI or what photoshops or whatever makes a designer 20% more efficient right there is an argument that okay well you just need 20% fewer designers I'm being overly simplistic but like efficiency gains in any industry eventually mean that you need fewer people to do the same job to do it I also think to some extent there's a bunch of work that will be able to be done by other people aided by technology and so but that's not new right if you think about making websites right it used to be if you wanted to make a website you had to have someone who knew how to design how to code you know how to like put together a server FTP whatever and that's still true today but we also have things like Wix and Squarespace that can make a pretty damn good website with like a person with or canva or you know whatever like the tools have gotten pretty good that like a bunch of people can just do it themselves A store owner with a you know enough motivation can build a pretty good-look site without requiring all that and so arguably there's a bunch of design jobs that don't exist today that maybe you know due to technology with AI I think what's going to happen is I think that there's going to be a bunch of work that designers do today that's going to go away and I just think it's I think there'll be other work that will emerge that will be necessary and needed so but I think that ultimately we're probably going to go through a phase of contraction around design jobs I see people I hear from people it's harder to find work now than it was two or three years ago I see teams figuring out how to operate much leaner and lot of that is due to tooling not all of it but a lot of it is due to tooling and it's just going to make things a bit faster and easier and I think I mean I think in some ways that kind of sucks but in some ways it's also good like you know like enough of the like you know doubling head count triping head count and have to lay everyone off like a year after it's like very bad for people's C years yeah and I think that it's very like if you look back through the history of technological progress and Cycles in all sorts of Industries this is actually a very natural kind of part of the evolution that doesn't mean that it's not painful it doesn't mean that people's lives aren't impacted and that I don't have sympathy for that but I also think that it's a natural part of the maturation of Industries as new tools come in and like you can go through every industry and find examples of moments of like this but typically if you also look over time for the most part everything grew right like you know we don't make there there's many things that employ line of type if you know about how newspapers were typ set you know for decades is through these lype machines and there these lype operators don't op that job doesn't exist anymore right but did exist for a long time and that's a and that's just an example of like how industry kind of evolves and moves through so for the designers I think you're right design teams kind of got a little crazy because we were doubling and tripling to keep up with the scale of everything we don't have time to talk about this but there's a whole other thing about how teams scale and I think we made a mistake because engineering was scaling In This Very linear way we would scale design similarly and linearly and I think that was maybe a miss and so now things are shrinking and we're sort of recalibrating it but AI I think is just a tool in the same way Photoshop as a tool or was a tool like I'm now old enough to have seen a few cycles of this and while it sucks for in the short term I think in the long term it'll be fine but it'll take some time to play out got it so it's probably just like the most actionable thing just to use these tools and like learn how to be more effective with oh I would not fight these tools that's Insanity I think that also you have to remember that these tools we're going through a bunch of hype Cycles around this and so I think that like how often are you using AI to actually design things right now I only use like one or two AI tools mostly to write stuff not to design stuff I don't really yeah you know they got a ways to go they do definitely help and they're getting better and they're progressing really quickly but yeah like you should use them and I don't think fighting them makes any sense I do think there are some interesting questions about how they're trained and you know what that all looks like but you know I think that we'll work through those I think those are good debates to have and good discussions have but it doesn't mean you either like fully dismiss it nor do you like fully embrace it like oh yeah no it's totally cool that it's doing all these not great things and you have to find something in the middle to work our way through this makes sense so John I'm not you know where can people find you writing online so online if you want to a lot of the things we talked about are in written form at John lajla x. f framer doai and that's just where I just of pushed out a bunch of my writing you can also find me predominately nowadays on threads also J N LAX is my username I don't I'm not so much on Twitter X as much as I used to be but I do occasionally pop up there and that's J LAX and so those are all good ways to find me awesome joh thanks so much for your time I love how you know with so many decades of experience you cut through all the bu and say it like it is so yeah so I really appreciate that and thank you so much thanks Peter this has been fun