5 Jun 2025 · 63 min
Henry Modisett argues designers need engineering knowledge to avoid losing insight during product development. He critiques design education for neglecting technical fundamentals and describes how curiosity and the impulse to "view source" transformed him from a struggling computer-science student into a designer. At Perplexity, he's building AI tutors to democratize learning by accelerating access to information.
Chapters
First of kind, Season one would not be possible without the support of our sponsors.
Thank you.
To Perplexity, Cursor, Framer, Granola and Linear.
Maybe we should go through each of the interviews. Yeah, yeah, yeah. And talk about why they fit that.
Mold of first of a kind.
Henry Modiset.
Henry Modiset. Henry Modiset was a designer who I came across when I was digging through the bowels of Google for top design talent on Facebook. And he ironically, Google was hiring really great designers to their iOS products, which always struck me as extremely ironic. But they had two great designers working on Gmail for iOS. Henry was one of them and Henry ended up at Quora. But he always struck me as a designer that understood the importance of the medium. He was unapologetic about being technical. He definitely fit the core mold in this regard, but he always viewed it as a strength, as the ability to just make the software do what you want it to do and to move quickly through opportunity spaces as a result. Rather than theorizing, he would go and instantiate new ideas very quickly with the work that he was doing pre product market fit at Perplexity and how he helped navigate that team into the business that it is today. I felt like not only was he a great case study in this archetype of designer who treats software as a material to be shaped and reshaped and reconfigured, but I think also as a leader of a design practice that is inherently AI native. There are no design teams that are AI native that I'm aware of before teams like Perplexity. So Perplexity is part of this first generation, first of a kind design practices that have to answer to what does AI allow us to do and how does AI shape the way that we do it?
Right.
So I feel like I want to start selfishly with the here and now of Comet, because I think for a lot of folks who might have already tried a bunch of startups might have tried out these crypto browsers or Ark, or have a friend who's working on a browser, there might be some fatigue there. And yet I have some ideas around how this might make sense from a business strategy standpoint. Kind of want to start with why would Perplexity even get into the game of a browser to begin with? And what are some of the things that you're discovering in real time trying to innovate in that particular space?
There's something that I'm pretty sure is true is that most people in the world can't tell the difference or couldn't tell you the difference between a search engine and a browser. And that's, you know, because like, Chrome is the most used browser in the world, and it just has Google baked into it. It's also because if you try to use a browser on your phone, like even on Safari, it just hits Google, right? And so I think, for the most part, like, the. The idea that, that a search engine and a browser are this sort of separate things, that's only if you understand the tech. Another thing that's true is we want Perplexity to be available in, like, every possible manifestation, right?
Where.
Where are people going to get information or take actions? Is it, you know, whether they're on their phone, whether on their computer, whether they just want to use voice? We want the product to be available everywhere. And so there's a lot of, like, reinvention, reattribution of how the product works, which is very fun from a design perspective because you get to sort of distill it down and then adapt to the context. So given all that, why not build a browser? Why not build, you know, hey, what are the most used types of software in the world? Everybody that has a computer or phone is using a browser, like, probably once a day, at least. Why not do that? Why not be a part of that? And why not give people essentially a way for them to download Perplexity? And then once they have that, it also just lets us do more interesting things because we're not just contained within being a website. We can own the Chrome of the software as well and just kind of build a more enriched user experience.
What do you think are the key pillars for that? Because I tend to apply what I call Facebook Brain to a lot of pieces of software. And one of the central tenets of Facebook was the software was often oriented around information rather than people. And so in my head, it sort of starts with the personalization of the web and positioning the individual user relative to their social graph. Right? But when you sort of apply, like a Perplexity lens on the same opportunity space, what sort of like, how is this an expression of Perplexity's design philosophy and product philosophy?
There's sort of one piece which is from a design perspective, we really want to meet people where they are in terms of their, you know, how they think of the world, in terms of how software works, how they think about information. I want to go create flows that, like, feel familiar to them, even if they, in a later stage, do things very differently. And we actually kind of get to play in two different ways. We've got our. We've got Comet, which is, it's just going to work the way that you think browsers should work. It feels very familiar from like a paradigm perspective, right. There are URLs and you can manually go to websites if you'd like to. We also have the Mac app, which is, I would call it an inversion of all of that.
Right.
It's a layer that obscures the Internet from you completely. So you're just interacting with Perplexity entirely. And the Internet is just this sort of way for us to connect to data and research for you. Some people are happily jumping into like what I would call, you know, the future. And other people are just like more comfortable with where things are now. You know, we get to kind of do both. And in general, I think it's important to not overshoot with design, especially interaction design. People have a lot of expectations with how browsers should work, even down to, you know, how tabs should work and how do you close the tab and the keyboard shortcuts.
Right.
There's like a, you know, whatever, 30 years of muscle memory that you can't really fuck up.
It's kind of like a Tesla car owner's like, first month with the vehicle that has place things in the wrong places where they find themselves fighting their own muscle memory. Right.
As a designer, you really need to be able to discern the difference between, you know, the possibility and necessity. With mass market like consumer design, you probably want to say no to most possibility and just go with necessity. And the browser is almost like the clearest version of that. You really have to, you know, be able to tell the difference between what's an innovation and what's just an arbitrary change. Just because it's like fun to change old things. And I think, you know, there's a way to build a path for people, but you really need to, especially for, for a new entrant to the market, we have to make something that feels pretty familiar.
Right.
So in some cases that's not like sexy and fun UI design, but it's practical and it's high impact. So that's why we do it.
I'm glad you brought up the example of the Mac app. When you first started at Perplexity, I would argue it was pre product market fit.
Yeah.
And now you're zoomed towards the present. You're overseeing a team. Tell me a little bit about how you set up a team to work across two very different surfaces and still be aligned on a common vision. For perplexity as a product experience. Because what I just described there sounds extremely hard, right? Both from a coordination standpoint, but also from an end user standpoint. How do you ensure that it feels like it's coming from one company rather than two teams at one company?
Totally. I actually think we have it easy in this regard because one, I don't think things need to be that similar across products. I actually think it's more effective to make things feel like they belong in the context, like in the operating system, in the form factor or whatever. And the other benefit we have is that with search, there's very little collision on product experiences. Users show up and say exactly what they want and you show them what they ask for. And so therefore we can work on essentially like infinitely horizontal experiences that will never show up at the same time. And they don't really need. It's okay if they look a little bit different or work a little bit different, you know, in large, large parts. And as long as, you know there's the same colors, typeface spacing, a few familiar components, like, it all feels like the same product actually.
But how did the team members actually negotiate a lot of these like little micro trade offs though? Because there's a coordination problem which is simply like somebody's kind of making the call and saying like, this is the way it's going to be. These are the models that we support at this point in time. This is sort of like the general purpose frame for perplexity. And then you guys sort of figure out the instantiation on your respective products. But sometimes they do kind of create some misalignment around like flows or around like, well, where do we kind of end up deeper in a particular workflow? Should we end up on a perplexity page? Should I be able to instantiate, you know, from selection inside of a browser, a new perplexity query. And if I do that, like, where, where does this interaction kind of live? Like, how do you kind of negotiate that as a team? Because it often feels like it's. There's a hundred ways to do it and 99 ways to do it poorly.
Totally. One thing that helps kind of keep things okay, we do a lot of small chunk projects, right? And so there's not, there's not like much that lives in kind of an exploration phase. There's not much that lives in a beta testing phase. It's usually like idea to shift in a matter of weeks. And so the possibility of divergence is like very limited. So it's not like one Team can go really far in one direction. It would just, you know, the ground truth is something that I remind the team always is the ground truth is the product. And what can you use? Right now? We don't, you know, we use mocks and prototypes and stuff as like, kind of a starting point, and then we get it into the product, and then that's the new, you know, that's the rule. And so therefore, there's, like, it prevents a lot of diversion.
Yeah.
I also, frankly, like, I, like, I encourage divergence because I think it, like, lets me see how other designers are thinking about things. Like, I'm okay with, you know, things kind of breaking patterns here and there, because if we're. We're really good at this sort of rapid iteration, you see this kind of, like, divergence convergence, like on a weekly basis, it's essentially like a refinement process and a group refinement process. And I think the other way benefit is just the team's not very big. There's only, like, you know, six product designers.
Okay.
And so keeping everyone kind of staying in touch with each other and through just like, we have, like one meeting a week. There's no crit. There's nothing like that. But the one meeting a week is, I just call it traffic control. Doing what? Who needs to talk to who?
Okay.
And what do we want to prevent?
Yeah.
You know, is there a collision? Is there an opportunity for collaboration? So every week we just, like, everyone talks, like, lists out what they're working on, and. And then, you know, I'll be like, hey, you talk to you. You talk to you. Or most of the time they're like, I'll talk to that person.
Yeah.
You know, it's not really all in my head, thank God, because I couldn't do it.
Yeah, yeah.
But I think everyone has the kind of the maturity and the trust to. To prevent those bad outcomes. Right. It's working so far, but like I said, we're small.
You know, you've transitioned into managing the team. You're still doing a fair bit of, like, IC work. What's some of the conventional wisdom that's just fallen really flat? Like, being in this role today, what do you feel like is not being shared or said or what are you learning about design management in this particular context that maybe defies your past experience, either working with managers, managing other teams in different companies, that sort of meets.
The moment of today before the perplexity. I did management for a few years at Quora, went back to being ic. I did the Kind of oscillation, trying to stay sharp on both sides of things. I knew at some point in my career I would hoped. I hoped I would get lucky enough to get to build a team. And I wanted to do it from the perspective of. Everything for me is like, how do you find the best talent and how do you keep them? And then you can kind of build everything backwards from that. And I mean everything. Like the product development process, the investment in branding, everything to me is, like, about talent acquisition and talent retention. And then you can kind of reverse engineer that. Right. Like, what are the best designers? I know. Like, why did they quit their last job? Or what makes them like their job? And when you reflect on that, when you deconstruct that a little bit, you don't end up describing how, like, most companies do management.
Yeah.
And so, like, what the hell is up with that?
Right.
Like, why. Why are people, you know, I know a lot of people that left the job because they were, you know, maybe asked to become a manager when they were an IC or they felt obligated to. Suddenly they found themselves on a team with, like, five other designers working on the same problem. Or, you know, just like, there's all these things. And so what I've learned or what I believe is that there's kind of these, like, maybe three things that matter. There's ownership, trust, and accountability. Designers, the best designers, they want to be trusted. They want to get hard problems, they want to own them, and they want to be trusted to figure it out. And they want to be held accountable to impact, and they want that of each other too.
Right.
You don't want to just. I know I've seen this a lot where there's this dynamic of maybe a designer who's really experienced and everyone is kind of looking up to them, but then that person feels a little bit isolated because of that. And so the kind of mutual trust, not just management to IC trust, I think that's really key too.
But let me push on this idea because you're like, okay, accountability, trust. These sound like pre GPT conventional wisdom. Is there anything about the tools or the way in which you guys are doing work today that's kind of making you approach managing a little bit different? Or that sort of maybe is reconstituting the archetype that you look for. Perplexity, for example, I think that the thing has been most surprising to me and that I just bow down to you and say, like, wow, you really crushed it on this front, is pulling together a team that has as much capability in terms of brand marketing and creating a visceral language for perplexity that sort of like, occupies the headspace of a lot of people that may or may not use perplexity in a way that kind of almost precedes the product and creates a promise. And I would have never guessed at the onset when, like, you had, you know, first joined up with the team and got started, that that would be true for this company.
Right.
But it's become, like, one of its pillars. Is it because of, like, who you brought aboard? Is it because of the toolkit? Is it both?
Totally.
How is it sort of shaping the way in which you're adjusting to managing in 2025?
Yeah, maybe the first half of your question. To me, the key difference is I think a lot of design management operates from a place of anxiety rather than trust. And, you know, there's a lot of, like, crits and gatekeeping and hand holding and coddling and, you know, kind of like fear and. And that's, that's in product design, but it's, I think, even more true in brand design. I mean, think about how terrified everybody is. It seems of like, violating the brand guidelines.
Yeah, yeah.
And so you see this, like, to an extreme sense in big, big companies with, like, established brands where you have, you know, all these designers, really talented graphic designers, went to great schools, you know, can make the most beautiful shit, and then they have to stick with, you know, the same three colors and the same typeface all day.
Right. Yeah.
And, you know, guess what? Those people don't. They either get, like, apathetic or they just leave because they're bored. Because someone like that, like a truly kind of creative person. Yeah. They're just gonna slowly die inside.
It's kinda like design wordle, you know, it's like it's such a constrained system.
Yeah.
That, like, it'll scratch yours for a certain amount of time, but totally, it's kind of the same.
Yeah. The incentives get all weird. There's something similar on product design. And one way in which I really kind of have embraced trusting people and just like asking them to go do their best work is like, we have a lot of designers coding. Some of them came into perplexity, as I would say, like great engineers, and some of them, they kind of like, were tinkering on the weekends in a previous life, and. And now I'm like, hey, you can write production code. If you want help, let me know. I'll do your code reviews. We'll teach you how to use cursor whatever. That's, like, I would say a risky endeavor.
Right.
Because we could end up with designers slowing the company down in, like, a kind of unprecedented way by being bad engineers. We could hurt trust with engineering by writing bad code.
That's completely unfamiliar to me.
So, you know, there's a, there's, there's a lot of risk in, in, I think this, and, and, But I, I, I believe that it is the right thing. And, and actually, I think it's, like, worked really well. And with brand, it's sort of like, you know, my strategy. With brand, we benefit from the product being about knowledge and.
Right.
And knowledge is everything. And how could you possibly build an aesthetic around something that's everything.
Right.
Without. You could either go super constrained and unopinionated and, and stoic and be like, black and white where everything is nothing. Where I'm taking the other approach, which is like, how about our brand is everything and can manifest in every possible way. Like, we're not beholden to a palette. We're not beholden to a style. The only through line is really like, how do you feel when you use the product and how do we want you to feel? And I've always felt like the true benefit of perplexity is we are helping people learn things. Right.
Right.
And we're encouraging curiosity through, you know, if you habitually use perplexity, you will become a more curious person. I believe that. And I also believe that's a good thing. Like, yeah, almost for, like, a moral perspective. And so to build a brand around the feelings of curiosity, discovery, and empowerment, I think that also matches really well with how I see AI and it's not this sort of, like, entity, fake human entity that you're, you know, telling to do things. We are, we just built, like, a faster bridge between you and information.
Yeah.
So to build a brand around that is, like, almost easy. It's a downhill problem, especially, you know, in the market that we're in.
Right.
There's, you know, we get to kind of saturate every surface area we can with these feelings.
Yeah.
And we get to reinvent. And then given that, hey, that's the. Imagine you're a brand designer. You work at one of these big corporate companies with a lot of rules, and I say, hey, there's no rules. Yeah, that's the pitch. And, hey, then I end up with these really talented people who are just.
Thriving and doing amazing work. I mean, if somebody created a super cute of the brand language of perplexity over the last 12 months, it would be sprawling and you wouldn't necessarily see any rigid structure to it. The content types, the colors, the palettes. It just roams around like wildflowers. But it does somehow cohere just in terms of its volume, just by virtue of it being so numinous, so varied, it kind of creates an overarching brand impression.
Totally. Yeah. This is like an intense reference, but I call it like scorch, like a scorched earth strategy.
Yes.
Where like we, if we're every aesthetic, then no one else has room to breathe.
Yes. Right.
We like take over everything. And it's important for there to be a little bit of the individual and in the art because it lets kind of, you know, I think I want to get years of wonderful creative output from everybody and the type of people that are doing this job, like, they want to express themselves, obviously.
They want to hide their little thumbprint in their work.
Yeah.
And so I want to encourage that because that also allows for this sort of like cross pollination and inspiration from each other. And it's just like, you know, our brand design channel is just a wonderful place because of that. Everyone's like in awe of each other's work all the time. And so that makes me very happy to see.
As you're aware, I work with startups and I'm often talking to founders who are like, how do I hire a Henry Montesset?
Right.
You know, it's challenging to find people who have the courage, frankly, the courage to join a startup pre product market fit, which I feel like you did. Tell me a little bit about that process, that phase, like, what did it take for you to make that decision? What were sort of the circumstances of context in which you're like, I'm gonna make the jump.
Yeah.
And then how did you personally navigate, along with the team, this journey to finding what ended up being provably like product market. But there was something there to it.
Yeah.
And what do you feel like can be generalizable from that experience?
I started my career like in college just making stuff. There's nothing to me more satisfying than making something, sharing it with somebody and like seeing them use it.
Yeah.
Even if one person's using, you know, the dumb to do list app you made, like, it's deeply satisfying. And to me, it's kind of like the whole point of what we're doing. You can very easily lose that when you're at a company in a bigger company and you kind of lose the connection to the thing that you're making for a Million reasons. In my case, I was just like a manager and I was ready to go back and make things with my hands again. So that was my main kind of impulse, is just getting back to that. So I went back into building startups almost in like an indulgent way. Worked with some friends, we built, spent a year building some stuff.
The transition to Perplexity, like, what was it that first drew you? Because I have this theory that software designers may have a lot of the distinct qualities necessary to be good investors because they can kind of squint their eyes and peer into what might be. And I feel like so much of like early stage venture is like seeing the possibility in something that other people just cannot fathom in a very specific and almost prescriptive way. What was it about the Perplexity team and that opportunity space? That space that they were kind of like probing at, that drew you?
I was kind of winding down with that last thing. And I'd worked with two of the co founders of Perplexity before at Quora. I knew them to be some of the best engineers I'd ever worked with. And that matters a lot, right? So one of them I worked with pretty closely, his name's Johnny. When he joined Quora, he was like 16. Okay. And like a world champion competitive programmer. Truly, like one of the best engineers.
I've ever gotten to work with.
Yeah.
And so, hey, someone like that wants to talk to you about working together. Like, you. You talk. And so I think what, to be honest, when we were at Quora, there was a lot of playing around with early LLMs. And it's funny to say now, but we even experimented with Truly in an R and D way, generating answers and generating questions. Obviously they sucked at that time. I remember using an OpenAI Playground LLM playground thing to do that. And it's funny, we were using it to. We regressed to using it to write silly poems, which I remember when ChatGPT came out, that was like the big novelty effect in a lot of ways. I got the novelty effect out of my system early by getting to play with it, like behind the scenes. So. But when these guys reach out to me, they kind of show me like just some tech demo stuff of what they were working on. I extremely agree with what you're saying. And I think the opportunity of a product designer is to recognize the potential value of naked technology. And so when I saw just the first version of the product and even the company was this text to SQL thing where you could basically talk to a database, correct but even just kind of having a natural. And I've used a lot of Python notebook stuff for data science, I know that that market needed to at least a new idea in there.
Like a sort of notebook thing.
Yeah, exactly. Like there was obviously some opportunity. Especially the natural language as an interface is like obviously so universal. And if you could build something with that, it's like that actually works.
But how do you get from there to an answer engine? What was the journey there truly?
Iterative experiments. We had it working with SQL, which was hitting a database, but then we were just adding more stuff into the database, like more text. And eventually it was like, oh, the more text we add into this thing, the more questions you can ask it that are beyond what you thought that it would do. And so we weren't thinking about Google, we weren't thinking about search, we were just thinking about asking questions to a large data set. And then eventually, I don't know, I don't even remember who tried this or why, but we changed the backend and plugged it into a Bing search API.
Yes.
Suddenly you could ask anything and it would do it. And having thought about. I worked at Quora for many, many years and thought a lot about knowledge, how people obtain knowledge, how knowledge and information is organized and categorized on the Internet. This is kind of like what we always wanted.
Right.
You could just on demand ask a question and get the answer instantly.
Right.
And this was in a slack bot. Like this was not a product, you know, and. But just the fact that that worked immediately was like, oh yeah, we can. This just needs to be an iPhone app and we've got a company. Like, it just seemed very obvious that if everyone had the ability to ask a question on their phone and get the answer instantly, how could that not be valuable?
But why is it, why do you think that Perplexity was the first to arrive at this and not say, an intrepid designer at Bing? This is just the folly of large tech companies. Or was there more to that insight?
Maybe it's a question of like, why don't big companies take risk or do this sort of R and D? Because we really, you know, we had six months, a six month project of like really not having a plan other than a hunch.
Yeah.
And just kind of being in this like hyper iterative cycle. And we were, you know, maybe I'd say incredibly lucky, but we were, we kind of were onto something like a month before ChatGPT came out.
Yeah, yeah.
So we were right behind them.
Yeah.
You know, and how many Other startups could say that.
That's true. That's true, that's true. Because even then their models were dated by several months.
Yeah.
You know, in terms of like the last training. Training run.
Yeah.
And so there was definitely a differentiator there in terms of like real time results.
Yeah.
But you start with the kindling that is Bing API and there's like all the rapid iteration from there. How do you make that kindling become a roaring fire? Like what was that process like from a design standpoint?
Just product shaping, like rapid product shaping. And so we were basically every day I was just writing code, tweaking things, trying it, just constantly using the thing, seeing where it sucked and then we would change it. And that was just a daily, like, you know, seven days a week of just product development and experimentation and just decision making. And I think what really worked everyone in the company is like a super engineer or like an AI researcher type of person.
Right.
There's no product people in the company, you know, like traditionally.
Yeah.
And there's no front end engineers really. It's just me making decisions about like how it should work, how it should look and how, you know, just like building the interface for all based on those decisions.
Right.
And so there's a lot of. There's no oversight on my work.
Yeah.
Which I needed.
Yeah.
You know, to go through that process of like shaping.
Yeah.
Because it needed to. It took a lot of reps. Like, you know, you look at my GitHub page and there's a lot of pushes for the first two years of me just trying stuff and going through that process. So I think that that kind of like rapid, rapid iteration and doing it in the code especially, you know, with our product being fully generative. Right. Like how could you. There's nothing to mock up.
Yeah.
I don't even know what it should look like. I don't know what's going to happen if I ask these questions. So that kind of rapid iteration in code was essential.
Do you think dog fooding in this manner is kind of essential to building a great breakout startup?
Totally.
I mean, I feel like that's also been something that I've noticed has been thematic with, I mean, figma being designed in figma.
Yeah. Right.
And sort of you feel the pain of where the product is lacking because you're forcing yourself to use your own stuff. What is it about dogfooding that you feel like is essential to this kind of work?
The practice of dogfooding, but also the ability to react and respond. You Know, within minutes or hours or whatever that is like whatever the opposite of a doom loop is, that's what happens. Because. And especially if a designer has that agency and that ability, because there's so, I don't know, there's a million things that you find and you change. And it's particularly important for a product with a dynamic experience.
Right.
Because there's nothing to think through. There's an infinite possibility scape. Not only do I need to dog food it, but I need to get it in other people's hands because they're going to ask questions that I never would have thought of.
Right.
Or break it in ways that I didn't predict.
Yeah.
And I need that so that I can. And that's. That becomes, you know, your, your kind of process moat.
Right. Yeah.
That differentiates you because you're. You may like look the same from the outside to another company, but you're, you're evolving faster than anyone else.
Right.
And so just like you project that.
Out and you get.
And I think that's like, we've somehow been able to scale that and that's why we have like so many irons in the fire.
When you look at people that are making software today, how do you identify, like this boom looping quality.
Right.
Or that impulse, that ability to kind of work in that manner?
I have, I would say, an archetype, a person that I look for when I find them. They're like either, I guess maybe in three camps. One, they're a founding designer.
Yep.
And hey, like been having been a founding designer, you gotta do everything, you know, say yes to everything. Things that you don't even know how to do.
Yeah.
And you're either gonna do it yourself or you're gonna hire somebody else to do it or contract somebody. There's that kind of, you know, almost like small business owner. Like, you know, deal with it. You need to convince everybody about like, not only your ideas, but like the kind of point of design. You know, there's a lot of like, deep education and just like, you know, not only getting people to believe what you believe, but also defending your decisions. Because, hey, there's no counterfactual, there's no data. It's just like you're gonna make some hard choices and then you're gonna have to defend them. There's like a grit that comes from that and a confidence and then also the reps. If you're a founding designer, you're gonna make a thousand decisions every day. If you're at a big company you're gonna make five decisions a month.
Right.
And I need people that have made a lot of hard decisions and are happy to own them and defend them, even if they're right or wrong. It doesn. And you know who else has that experience is solo freelance designers or small agency freelance designers.
Okay, say more about that.
Because those guys. Guys or girls, the people that I've talked to, they're going in, they have a week to design a whole app.
Right.
And that's amazing. You know, and they're pretty good at it because they do that every week.
Right.
You know, you go talk to someone at a big company, they added a feature to the setting page, you know.
After months of research.
After months of research. You know what I mean? And so I want people that have the reps. I mean, that's what it really comes down to. And especially the 0 to 1 reps. Yeah. And I'd say that the third kind of background that I've found is someone who's somehow like going succeeding above and beyond in some crappy organization. Somehow the work is good in spite of all the things stacked against them.
Right.
You know, kind of a boring product or an organization that's not really like supporting of design.
It's like exceptional work in unusual places.
Right?
Yeah, exactly. And so even if they're putting all their energy into dumb shit, someone on my team, when I was talking to him about joining, he was like, yeah, I'm putting together a pitch deck for the board so they can approve the redesign of the app that I'm. The product that I'm working on. I'm like, you're pitching to the board the redesign. Cheers to you staying up all night working on that. But do you want to just ship stuff instead? So there are people like that that are just fighting through whatever they're in. And so you take someone like that who's so used to working hard and putting them in an environment that actually accelerates them. That's the benefit. I see. So those are the archetypes that I look for.
It's funny because of everything you said. We didn't talk about taste, we didn't talk about craft. Those words didn't come up. But they're all over my timelines.
Right.
And so I feel like I have like a two hour rant on that topic.
Yeah.
But I mostly want to hear your perspective on it because I would argue a lot of the work that your team produces has craft.
Yeah.
Has taste. And you look at the individual bodies of work behind each of those team Members, they're tasteful, they've got incredible craft.
Yeah.
But those weren't like hiring heuristics. And what you described totally help explain that to me.
Yeah.
I mean, to be clear, it's there. The things I describe are the hardest things to find and to suss out. And what's so easy about hiring designers? Having hired other people to the work of a designer is like something you can just look at.
Right.
You can even look at it before you ever talk to them.
Right.
If, if someone applies to a job and their resume is like weirdly ugly. Like what? You know, you had complete control over this.
Yeah.
It's just typography.
Yeah.
And you phoned it in.
Yeah.
That signals something to me. So, you know, there, there's how you represent yourself.
Yes.
As a person, as a designer looking for a job. You're so lucky because you get to, you get to flex, you get to signal with in the smallest ways because you're trying to get a job from someone who's like very detail oriented.
Yeah.
And all you have to do is show the detail. It's like, hey, show me what you got. Because it's right there. And you know, whereas hiring, maybe hiring a product manager, which is like sometimes the hardest, it's a lot more to talk through and figure out their worldview and what they really did and stuff like that.
Right.
That's why when I'm looking for designers, I mean, definitely someone with the reps and someone who can show me their work that they actually did. You learn a lot about their craft and their taste and whatever. But I think like, look, I need someone, I need people on the team that can do good type spacing and color. Like in the end all software is that gotta fine tune.
Yeah.
And I can't have that being way out of whack with other people's work. So that's table stakes.
Yeah.
But not the only thing that matters.
I want to go back to something you once said to me, which is that there's way more great software designers than great software design. Why is that? What's going on with the state of the field right now?
I'm going to answer, but I want you to answer too because I think like I don't obviously don't really know, but my I, I think my main perspective is most of the time the reason why a product is not well designed kind of has nothing to do with the design team.
Yeah.
It's like, because I bet if you peer open, you know, open the hood and look inside that company and go into that figma file. I bet it looks pretty good. Yeah, like it's not that hard to make nice ui. It's pretty easy to, you know, get to find someone who can get the basics right. And so really the question is like my assumption is like why is, why is, why are good box not being built and why are products probably overly complex? So my hunch is that like the kind of two root issues are product management not being decisive. Right. There's a lot of shipping, the org chart, there's a lot of. Yeah, you know, kind of like whatever, everything can go wrong with, with a company. But in the end it's very hard for a company to be opinionated enough to build a product that feels simple and straightforward and confident. The other piece of that is UI engineering is like, I think a practice that has been somewhat abandoned by like the engineering field.
Interesting.
I think like a lot of great engineers like don't bother learning how to do css.
Is it because like front end is viewed as like low class work or it's just like, oh, this is the kind of thing that we would farm out or like, you know, machine learning is just way more interesting and novel. Yeah, harder engineering problems lie here rather than trying to wrangle a web browser.
I mean, I think like for the most part it's not even, I don't even think of it as engineering. Like putting the buttons on the screen is like, you know, there's some like nice system syncing that you get to do and you know, writing good modular code and stuff like that. But you know, if you study computer science, like you're not getting to really flex the most interesting concepts by writing css.
Right.
And so I totally. And that's aside from the job market, like obviously if you're, if you're a great engineer, you should take the best job and change the field. Right. I remember when it was iOS engineers, you know, writing Objective C and like that was like the premier thing to do. And then it became machine learning engineers and now it's AI whatever. Yeah, it just front end engineering kind of got left in the dust I think. And that's why it makes a lot of sense for designers to just like cover that. But I think that's obviously not true in most companies. And so for whatever reason it's sort of phoned in. And so then I think a lot of the reason why a lot of products don't feel very nice is because they're not. The user layer is not engineered very thoughtfully and Certainly not with the level of finesse and detail that probably the designer had imagined. Right. The hover states, the animation, timing, stuff like that. And to be honest, most of the time when I'm building that stuff, I don't go into it knowing what I want. I build something and tweak it and throw it away. So, truly, that craft comes out through some iteration and close to the metal iteration. So I think a lot of products are overly complex because organizations are not opinionated and confident and, you know, whatever. There's a million reasons. One. One paradox that I love that I. That I kind of like to remind everybody is there's a lot of terrible software that people use every day, and there's a lot of beautiful software that nobody uses.
Yeah.
And so there's the paradox of, like, design is really important, but it doesn't matter either.
Right.
You know, like, no one would describe Amazon as a beautiful product, but, like, it's really useful.
Correct.
In a very successful business.
Yeah.
And so there's a dissection that should occur and the introspection of, like, what's the purpose of design and what is the impact?
But I feel like, for me, like, there's. I often wonder if software design is falling into this trap of, like, modern architecture in the 20th century, where a lot of bad stuff ships because the profit motive insists on it.
Yeah.
And designers forfeit their moral authority because they're not at the wheel of development, at the wheel of deciding, okay, what property are we going to buy and what are we going to put here? They're not the business owners, per se. And maybe bringing it back to software design. I wonder if it's. The thing that I'd observed as Facebook grew and scaled was that we were starting to retreat from production.
Yeah.
And part of it was because you just have so much surface area, so much abstractions to the front end, and you're almost being like, abstracted away from the metal that it kind of prevents you from being able to ensure that quality control. That is the reason why you were there in the first place.
Right.
You wanted not just to make something that's good on your computer, you want it to be great everywhere it instantiated. I wonder if the industry writ large got comfortable with producing blueprints rather than making, like, shining buildings, skyscrapers, things that tower over you and you can marvel at and say, like, that is beautiful and it's majestic and it is big.
Right.
And, oh, my gosh, it's just like a. It's a conduit for, like, human Energy.
Right. Yeah.
Instead we just kind of made more spec homes.
Yeah.
Or made renders of, you know, hypothetical towers that will never be erected.
No, I get it. Like, I don't like it, but I get it. It's. It's cheaper in terms of man hours to make a mock.
Yeah.
And so especially if, you know, there's a kind of an anxiety in an organization or an uncertainty, it's nice in leadership to be like, okay, let's mock up three options.
Yeah.
Three directions. Yeah. And. And then design becomes this sort of service organization to like, visualize possible outcomes rather than, you know, a important part of the sort of strategic and launch process. And something that I'm pretty intense about in our company is like, we don't make mocks for things we're not actually going to build.
Yes.
Mocks are like a starting point of a project.
Interesting.
Not like a we don't like unless we really believe this is something we're going to build and launch. Like, it's not worth exploring and certainly not worth my design team's time.
Yeah.
And something that I'm pretty intense about and maybe overly intense, but I just.
So no blue skying. No. Like, what if we made a car?
Right.
If we did something that's way afield of what we're doing.
Because that gets out of hand so quickly. Because it's fun. It's fun for the person prompting the designer to do the work, but it will kind of kill the energy of the team eventually.
Yeah. Right.
Because a back to like something that I was saying earlier. What? What do people care about, really? They care about, like, the best designers actually want to make things that people.
Yeah. Yeah.
Not just be like a visualizer for leadership.
And now that I'm thinking about it, it reminds me of like the concept car where you have kids growing up loving automobiles, deciding they want to design automobiles.
Yeah.
But they end up being part of like this concept car factory.
Yeah.
And they never actually get anywhere close to shipping products in the world that people drive.
Yeah.
They sort of like instantiate.
Yeah.
An aesthetic or an idea space that maybe sits upstream, you know, years out from like a vehicle that may eventually arrive at the market.
Yeah.
But we're a whole separate class of engineers and designers are responsible for that vehicle that goes to market.
Totally.
And I feel as though, like people like yourself, people who are on the front lines of software design, need to say, like, folks like that way of making software is going the way the dinosaur. I at least think.
Yes.
You know, maybe it's cynical to believe that. But like, I just think it's just going to get obliterated.
Totally.
And it's going to become a world where only the builders remain.
Yeah.
Only the folks that are bringing things to production, bringing things to market remain. And it will be a blend of design and engineering and marketing and a whole grab bag of skill sets made possible by new tools.
Totally.
Right.
But if you don't have that impulse to ship, then you're just concept carring for an automobile manufacturer that's going out of business.
Totally.
Right.
And an understanding of how things actually work, I think, because there's so much lossiness right now and if a designer doesn't really know the constraints or the upside or can see the technology and maybe in a different way than the engineer, but while understanding it, there's a lot of, there's a lot that's lost. So I went to engineering school. One of my best friends is a mechanical engineer who worked at Apple. And his job was like the kind of the next step after industrial design at Apple. So they, they would give him basically prototypes.
Yeah.
And then go make this technology, do something cool.
Essentially. Basically, like figure out how to build it.
Ah, I see. Okay.
And so then he's like, yeah, yeah, yeah, yeah, yeah. He's like, you know this, he'll, he'll look at a prototype and be like, okay, you know what? Like, you know, you're using this metal but like we can't get enough of it.
Right.
So he's like, hey, there's only so much aluminum in the world.
Right.
That we have access to. Or I need to go build a new custom CNC machine in Germany to like get the watch, you know, dial right. Or something. I remember seeing him always just like scratching his head like how, you know, how are we going to do this?
Yes.
Because he really understood the true constraints. And so I kind of think like sometimes front end engineers are in that spot.
Yeah.
And he actually is a great designer too. And so he was able to like take that and, and you know, take the design thinking and actually like make it more realistic.
Right.
And I think he probably could have just done it end to end.
Yeah.
But that's why I really, you know, I think the notion of like design school not teaching engineering is like you're kind of cutting a lot of people off from being successful and.
Right.
I think that's less bad than like all these like HCI programs. Right. Because.
Right. Yes.
You know what? Nobody's innovating on interaction design. Nobody really needs to, I mean you know, that's like a. A broad thing to say. Like, obviously some, some companies are and should but for the. The average junior designer joining the workforce, like, yeah, if they just knew, you know, learned 50% graphic design, 50% engineering.
Yeah.
We would have a lot more good software.
Yeah, yeah, yeah.
And I think, like, that's. That's what's missing right now.
When you look back on your own experience, like starting off in engineering school, maybe, like myself, like, finding that people are calling you a designer and you're like, sure, I guess I can be that too, right? Yeah, I'm good with web browsers, but I guess I am designing the app and sort of like ending up in the field of software design. Like, what are the things that you look back on now with the perspective of what you've accomplished and say, like, you know what? I can attribute being here and having this conversation to these life experiences, and this is how I'm now seeing these dots collect.
So I studied computer science, and I was never very good at it, but I. I loved it. And all the, like, kind of big concepts and, you know, things like all the algorithms and graph theory and, like, I just, I loved learning about it and just, you know, basically failed most of my tests. The most interesting thing for me was getting to figure out, like, how this stuff actually worked, not, not, you know, having to do the hardest engineering problems just for the sake of them. But, you know, building something that someone could use was really, really, like an enlightening experience.
Right.
And also I was adjacent to students that were studying what we were calling. They were calling product design, which is like physical product design. I think, like, maybe that my worldview expanded just with the basic realization that everything around us. So all my friends were either product designers or architects, and everyone around everything around us is made by somebody. You can pull back the curtain and look at every object and every piece of software and realize that actually it was designed by a person. And that also means that everything around us could be better and could be improved and could be iterated on with someone who has an idea. And I find that deeply empowering. And it's like, I think an optimism that a designer should carry is like, you can. Maybe you're anxious about how things suck or how systems are crushing, but you could also have the perspective of, like, I can change everything. That is the kind of deepest feeling that I find interesting as a designer and that, you know, I think being surrounded by people who are. Who were looking at architecture and looking at products and my, My roommate Was like, he worked at Hasbro, and so our house was like, you know, in Toy Story, like, Sid's house, where it's like a bunch of broken toys that are, like, put back together.
Yes.
Like, that was our house because he was taking. He would go to Target and buy all these toys, take them apart to see how they worked.
Amazing.
And then, like, try to, you know, make new stuff. That energy being around that, I think, and then kind of seeing that, like, hey, I can kind of think that way about software, too. But also software is way easier to think. You know, you get to apply that same belief. And I think a lot of people at that time, too, were starting to think of software as products. There's a lot of dita Rams type of things getting thrown around on top of software. So I think that was maybe interesting for a moment and inspiring for a moment, but I think didn't last very long as being truly applicable. But the basic thought that, hey, I can look at all the apps that people use, and if I have an idea, I can make. Make the same thing or make it better. Anyone who feels like once you kind of flip that switch, then you're a designer.
Right.
You need to learn how to make stuff.
And I hope that, like, you know, I obviously wish Comet super well. I think one of the things that I fell in love with was that moment of hitting View Source.
Yeah.
And you're like, open up the underbelly of this whole new medium.
Yeah.
And you're like, oh, my gosh. Like, there's like a. An inherent logic to it, but it's malleable. I think the great poverty, you can learn from it.
You can just read some guy's code.
Exactly, exactly. You can just literally just read the material and be like, okay, if I move this thing around, this is what's going to happen.
Right.
And I feel as though, like, the great poverty of the web today is that I think that that View Source impulse is being lost. And my hope is that a new browser maybe could act as a bridge for how you can make the web more malleable again and more. Like, instead of being inscrutable, be like, something that you can not merely, like, change and edit, but understand.
Right.
If you're so curious to do so.
And especially if you have that worldview of, like, everything is made by somebody.
Yeah.
I can deconstruct it.
Yeah.
And I can learn from that and build my own stuff.
Yeah.
And to be honest, like, the. When I've talked to some people that are in school now, like, that energy, I feel like, is there. There's a wild idea to artifact generation happening, like, rapid generation. Like, nobody knows how anything works, but they're making stuff. And I think that's better than nothing. And there's an excitement on how easy it is to put something together. I think we're gonna see an explosion of that type of designer if we can proliferate that idea. Like the.
The.
I think any notion that, like, design is, like, a diminishing field or something, I just, like, completely disagree. Like, we're actually more empowered than ever.
Yeah.
To, you know, if someone in a company needs to be able to believe something and. And manifest it.
Right.
Like, who's going to do that? Who's the best person to do that, if not a designer?
Yeah.
Because, like, most of our job is, you know, kind of being decisive when there's a lot of possibilities.
Right.
Yeah. Yeah.
Essentially, that's all taste is.
Right. Like, and instantiating it. I think that's the other thing. It's not like you're drawing a concept or an abstraction of it. You are making the actual thing.
Yeah. Right.
And so once you're there, it's like, might as well just get it in the hands of people.
Right.
Totally.
Yeah.
That's a short, short path there.
Exactly. Like, you know, you went from. You know, we could solve infinite problems. You pick one you can solve. If you have infinite solutions, you pick one.
Yeah.
And suddenly you've got the result of that faster than ever before.
Yeah.
You need a designer or, you know, whatever. Somebody who has, like, the characteristics of a designer.
Yeah.
To guide through that. Because what I've seen is, like, it usually is the designer who's, like, willing to, like. And for whatever reason.
Right.
The practice of design, the grit that kind of comes with being a designer. Someone like. It's usually the designer that's, like, the one that's most confident in the unknown, in the scenarios where there are so many unknowns, I find that there's, like.
An archetype clash where for every designer that is comfortable with the ambiguity and is comfortable with the improv, the experimentation, you're like, I'm just gonna make something up. And it may or may not land, but I can kind of exercise a good judgment to say whether or not we should kind of continue to apply energy towards it. I feel like our field has started. Become littered with people who want the certain paycheck, the certainty, the structure that I think that highly profitable software companies can offer you.
Right.
As a countervailing point. So what is the argument for the startup.
Well, I think because the reality is in most companies, you can't apply any of that stuff. You know, you don't get to. You're part of a machine and you do one piece of that, or maybe you get to really contribute in a small way, infrequently. You know, I mean, I'm diminishing it, but I think, like, in comparison, it really is true.
Right.
If you, you know, and if you want to make something special, then you're going to have to go into it really not knowing what you're going to. What you want to make and not having the burden of like, communicating, approving or getting staffed on the right project. Like most of startup is just jumping in and trying to swim and going through the, the rapid exploration and getting to own every decision because you have to. Because it's costly to explain every decision to another person or get it approved or, you know, it just in the end, like, it's a completely different lifestyle. And I think there's. There's a type of person that I think is, I guess it's ambition. Like, I want to take a. I want to take a crack at big ideas. I want to see, like, okay, can I do something different if I just had more control over everything? Right. So I think anyone that's even remotely ambitious or curious or, you know, wants to test themselves.
Right?
Yeah, definitely. You're not going to learn until you try a startup.
Right.
But I think if you just want to be a great designer, you need the reps and you need the, the reps of making hard decisions, shipping those decisions and seeing the results. And if you can do that a thousand times in a year versus 100, you're going to be a better designer. You're going to be a smarter person.
Yeah.
You have more information. I think, you know, more people should take a crack at like, big problems and the ownership that comes with that. Yeah, more people should do that and are capable of that than I think are doing it.
Seeing as you have that perspective, how do you stave that off? As perplexity continues to grow and as you start to continue to expand the empire and expand the product suite and expand the team, like, what are the active measures that you envision? It's almost the folly of every good company, totally. That they become the villain, Right?
Totally.
And maybe that's fine. Maybe that's just like every tree's got to come down eventually. Seeing as you already have that perspective and you've lived through it in different contexts, you've seen it firsthand. What do you think are the mechanisms for keeping people close to the metal?
I think about this a lot, like how long can we do this? But I certainly want to, you know, it's important to me and it's important to me to protect it. So a big part of it is talent, like retain, like retaining the right. The right type of person.
Right.
Because not everyone can have that ownership and can actually like earn it and keep it. What I've seen happen a lot of times at a lot of companies, regardless of whether it's design or not. Right. You start a company with a certain type of person and they scale out. There are people who, you know, there's engineers that could like, you throw them into anything they can. First principles, build anything. It doesn't matter what language it's in, whatever. Right.
Yeah.
Suddenly you're a thousand person company and like there's not like room for that kind of person.
Right.
Which sucks because those are actually like, those are the people that you, if you ever want to innovate again.
Yeah.
You need those people. And a lot of companies, I think what happens is they need to innovate again and they don't have the right type of person to do it. To me, it's important to not lose those people.
Yeah.
And the way that you don't lose those people is you, you keep that like high level of ownership and trust and accountability. You keep the process that got you to where you are. I actually try to keep us a little bit understaffed.
Right.
Because I would rather one that puts a lot of pressure on the projects that are coming up.
It creates a good constraining function. Right.
And, and hey, I can't ship something without my team.
Yeah.
It doesn't work that way. So that's one part of it. But the other part of it is like there's always enough to do. There's always just a little bit too much to do for the designers that we have. We're bigger than I thought we'd be, than I thought we would need to be. Only because we've added enough surface area where there's just like a lot to do, a lot to go around. And I think at some point we'll essentially top out because there's only so many places that software exists in the world and only so many devices.
One of the things you said earlier that really just resonated for me personally was I remember, you know, Google's mission statement of like organizing the world's information.
Yeah.
And making it accessible and useful.
They have an about page. You can read it. Which is amazing. I didn't.
Yeah, yeah, yeah.
And I always thought that there was an elegance to it.
Totally.
And so when, when. When Facebook went through that same exercise of like, articulated mission statement, you can sort of look at it cynically and say, oh, it's kind of frou frou. It's silly. You know, it's like corporate speak. Or it can be like a. An alignment of effort and energy, a sort of a view on what the world should be. And if we don't exist, the world will not sort of organically arrive there.
Yeah.
I love that you sort of described like a moral impetus.
Yeah.
For making people more curious.
Yeah.
When we were early on in the company, you know, we didn't start from a mission or a vision. You know, there wasn't like, we're starting the company to like, you know, defeat this problem or whatever.
Right.
It was really just like, let's tinker, see what we pull out of it. And I remember that there was a moment where we. Where we kind of got something working and it really felt like you could ask any question. And then we kind of reversed engineered, I guess, like a mission or a vision out of that. A lot of that early kind of like writing that down. That was coming from me and what I was inspired by just like, you know, sort of the access. Access to knowledge and that being kind of a fundamentally good thing to work on and kind of being proven out as being valuable for society. I believe strongly that there's two. There's two properties of our product that I think it has. One is the speed to knowledge. The kind of like an epistemological advancement. You could know something confidently, faster than ever before.
I wonder.
I know.
Yeah.
I wonder.
In human history, right? And especially it's like, all things considered, it's a pretty robust information. Right. It's. And that's actually like directly as a result of our. Our original innovation of like using sources. Right. So just believing that and kind of getting that to more people, that's like the biggest thing you can imagine. Like, hey, if everyone in the world had access to robust information on demand, you know, what does that mean? And I think one. One amazing property of, you know, LLMs and AI or whatever is you can build a personal bridge between you and information.
Right.
And I think about all the time how I, I suck at math. I always had a math tutor and, and, and it worked. I actually, like, I would do well. I did well in math with, with a tutor. And, and only because I kind of could ask questions and get answers and get things explained in a different way.
Yes.
And if you imagine everyone in the world has that mental model with the information that's available to them, everyone's building these personal bridges, everyone can learn. There's no stupid questions you can ask. You know, I could have been asking calculus questions. Can you explain it to me with this metaphor or can you, can you represent it in a more visual form? I also, I really didn't understand core programming concepts until I wrote ActionScript with Flash.
Yeah, buddy.
You know, like, I didn't get object oriented programming the way that it was taught was taught for basically kids that were also good at math.
Yes.
As soon as I got into action script and rendered a circle on the screen and, and, and it had a property of being read, I was like, oh yeah, I get object oriented program.
It's a big unlock.
Yeah. And, and, and, and that's my story. And I just believe that like everyone's got some version of that story. You know, there's so many people that say, oh, I'm bad at X. And I just don't believe that. I just think you haven't been taught in a way that resonates with you.
Yes.
To me that's gotta be the most interesting, important thing to contribute to. Right. It's not just us. I think that's generally the trajectory of all the AI and a lot of students are using, whether it's us or chatgpt. But I love working on that and contributing to that. And to me that's a really big thing. So that's maybe the kind of high broad statement more in the trenches. Think about all the things that people, all the information and actions that people take on the Internet. Why can't we do those things? Because why should, why should we do those things? The answer to that is because we can, we can make it feel faster.
Right.
And the most fundamental property of like a good consumer product is how fast it is in terms of not only how fast do things load, but like how, how much time does it take the user to accomplish what they want.
Right.
And we can essentially, you know, we've made the research part of clicking on websites faster and we can do the same thing with the actions that people take.
Right? Yeah.
And, and that's just, that is like a, you know, a lofty goal, but I think it's one that's going to be the best for, for users is just like everything you need to do, you can do it through perplexity faster than before, easier than before, more in a. More like a reliable way. That's like everything, right? That's every. Every software action.
Yeah.
So.
And I've always felt like, you know, I don't think I've ever said this out loud, but I've always felt that more so than writing essays or writing policy, sometimes making software is like the best expression of like an idea set, a philosophy, a way of interacting with the world that can reach the most people.
Yeah.
And reach them in direct and practical ways, but almost like subliminally.
Yeah.
I feel like that was the romance of Apple, of yesteryear.
Totally.
Right.
That you realize. Oh, wow. Like this is clearly made by people out there that expect the best from me.
Yeah.
And expect the best of themselves. I appreciate you chatting with me, man.
Yeah.
I mean, we could go all day. Just keep getting more coffee.
Sam.