Rid (3:45)

Then we can jump back into it. So you know how I've been talking about how I use genway to do research with AI? Well, something surprising is happening and just for context, I use genway in two different ways. One is contextual interviews. So I prompt the AI with what I'm hoping to learn and it has a dynamic conversation with each person. And the second is usability testing. So I upload a Figma prototype and their AI agent helps me test them with people all over the world. I mean you should see the quality of the follow up questions. It's pretty crazy. But here's the surprising part. At the end of the interview, most people say they're more comfortable opening up to an AI agent than a real human. And it's just another reason why I'm hooked on the product. If you want to try it out, there's even a secret landing page just for Dive Club listeners which gets you two months free and 10 credits to recruit people. Just head to Dive Club Genway. That's G E N W A Y. Just when I thought I understood how powerful Raycast is, they released their all new AI extensions. So you can interact with all kinds of apps using natural language. And you can even connect actions to string together workflows. Like in a single command, I can start a Focus mode, change my Slack status and press play on my favorite Spotify playlist. And that's just the start. I mean, there's already extensions for Shopify, Linear Zoom, Google Calendar, and this is a pretty big time building block for the future of AI and productivity. And it's a big reason why I've never been more excited to be all in on Raycast as a product and as a team. So if you want to learn more, they have a really compelling video that you can watch at Dive Club. Slash extensions. Okay, now onto the episode. Maybe we could start with your early journey. And I actually recently interviewed Amar Reshi who was at Palantir, and one of the things he talked about how he really appreciated the level of autonomy that designers were given on day one. So maybe you could just start by talking about like, what was your early experience like when you joined?

Ashman Gagari (5:53)

Yeah, yeah, I think actually mine was pretty interesting actually. Amar was one of my interviewers, so he, he was the one of the few people to tell me that up front and I kind of didn't believe it till I experienced it and I think it was completely true. And some more in my first few months I was actually on this team called BD Design, which essentially is a of designers who work directly with the customer or like deeply embed with different customers. And so I was out here just kind of, you know, going directly to various customer sites and working with them on their products. And I think that's one of the interesting things about Palantir is a lot of the product is built in the field for quite a bespoke use case and then slowly generalized and brought back to the core platform. And I think what you get from this is like you're not solving a problem for a thousand different types of users in one go. You're really just like building this highly bespoke perfect thing and then worrying about kind of how to kind of bring it back. And this requires a lot of like first order thinking, problem decomposition, systems thinking, workflow diagramming, and frankly like the boundary between being a designer or a product person or a developer is quite blurry in these scenarios. Especially when you're with a customer, they're going to ask you any sort of question regardless of your job title. And I suddenly have to speak SQL, even though I've never really done it. And that's when you kind of realize that you need to be able to kind of Embrace the entirety of the platform and its capabilities, regardless of which team you're on or which product you're currently representing. That's kind of how my first few months were. I was working within the healthcare industry and it was just fun to see how they were solving a lot of the same problems on various different sides of the domain, the healthcare domain. And you're really looking at massive amounts of data that is hard to read, hard to parse and needs to be A, visualized, B, tangible. You should actually be able to filter it, do things to it, get to insights. And I think learning all of that on the job was definitely quite unique. Going back to your, I guess speaking about autonomy specifically, it's kind of most visible in the fact that we have only like 40ish designers and, you know, we have maybe I believe 2,500, 3,000 people right now. A little less than half is the product team. And by product team I mean essentially everybody who builds the core Foundry and Gotham platforms and Apollo as well. And I think if you think about this ratio, what this really means is like, we really do have like large swaths of UI or product that a single designer is owning from day one. It really isn't really about like your seniority, which, by the way, we do not have levels per se. We kind of have like new hires, industry hires and leads, and that's about it. And you end up kind of owning pretty much a whole app in your first six months. And that comes with, you know, all the complexity you need to suddenly internalize what this app is for. It could be something like a time series analysis product which allows you to first understand like streaming and data density and, you know, all these like, like kind of derived properties and all sorts of different, like, ontological concepts and then apply them suddenly to interfaces and it's like it's just been six weeks. Yeah.

Rid (9:11)

Is it pretty common that the new hires would start off embedded on these teams in the BD platform or so.

Ashman Gagari (9:18)

That'S actually less common. And I would say that I was definitely in a bit of an outlier, I think, at that stage because of Foundry not being mature enough, spending more time in the field putting together like exactly what the user needed with a kit of parts that we had. And by kit of parts you can imagine some sort of like workflow builder or website builder application powered by a strong data model and backend that is also designed and built in Foundry. That used to be a bespoke need back then because everyone had their own custom workflows and Obviously you need a designer to like, figure out information architecture, concepts, hierarchy, you know, layout, all that stuff, including even visual design. Now we have much better tools. Foundry is much more mature, and so the stuff you can do out of the box is so much stronger that you don't really need to kind of like send a designer directly to this place and have them build that end use app. An example could be, let's just say like a manufacturing company has a factory floor and each person on the factory floor has an interface that allows them to kind of scan apart and mark it as good or bad. Quite a simple interface. But back in the day you would have to kind of figure out exactly the ux, go to the factory floor, shoulder surf with the guy and be like, oh, this is what you're doing, this is what you're holding when you're doing this work. This is the resolution of your screen. Now it's like much more easy to kind of just like deploy an app out of the box that we call maybe template B of like triaging app or inboxing app. And you just kind of deploy that app. As long as the ontology is sound, you can customize it just enough so that it makes sense for the constraints of that user. So because of that, we don't kind of send designers directly into the field for one direct use case, but instead have them represent the product. They still go in the field and they still work with customers. But now you're kind of representing the product team more so than kind of representing the, like, business development team.

Rid (11:15)

It's fascinating because you truly are having to account for like an almost unprecedented amount of use cases. And to do so with the least amount of software created possible, I'm sure, is like one of the core challenges of being a designer in this environment.

Ashman Gagari (11:31)

I kind of see this internally, maybe more as a joke, but, like, it really can be used for anything. Like, theoretically, you can build all of Airbnb on Foundry. Like, we have the back end infrastructure to allow that level of application to exist. And we have an app builder that would let you actually build something obviously not nearly as beautiful and usable, but still would functionally achieve a lot of the same workflows. And we do have data pipeline applications that allow you to view the lineage of all the data that's passing through. We have an IDE application within Foundry that lets you actually code these transforms and these data pipelines if you're the data engineer. I think what's interesting is that the core product that we're building is A product building application in itself and is the thing that allows you to spawn end new units of software. So I think to your point about in as little software as possible, I actually don't think that's true. It's almost like front end is cheap. It's just this thing that you can emit as much off as you need in my world. And this is maybe a bit of a segue now I'm not speaking for Palantir as much as just myself, but I believe that bespoke artisanal software should be all around us. Think about Costco coffee versus small batch coffee. Which one is more valuable and fun? There's a reason for which is the one you prefer. I want small batch bespoke software that's made just for me and my use case. This is vaguely what Palantir is kind of achieving when it comes to you're an energy company and you need to understand a thousand sensors emitting tons of gigabytes of data per second and you need to kind of understand there is no other template out there that helps you understand it. We're just going to need to build this for you. And it's not a dashboard, it's not a read only view that's just like oh yeah, like things are going up, things going down, something bad, press red button. It's not that it's like write back based. There's entirely like multi step workflows, inner loops, outer loops. People are making artifacts in this stuff. People are like collaborating on this stuff. There are security concerns. So I think like at the end of the day, the most powerful part of Foundry is that it actually enables the existence of any of these things. And hopefully in the future, if we do the developer experience right, it would allow anybody to build on top of the Foundry like developer platform and really start crafting these artisanal apps for their org, for their companies on their own with relative ease.

Rid (14:01)

Okay, I think I'm probably going to summarize a little bit more than I normally do for other episodes and just give you the opportunity to be like, okay, let's make sure that everyone understands where we're at. So we have BD where the designer is like really embedded on the team. That's where you started. And then we also have Gotham, which is kind of how Palantir started, which is more of like the kind of the government contract origin story. And now we have Foundry, which is like this very open ended kind of like dev tools platform on steroids. And you're a design lead on Foundry. Now, do I have a correct correct?

Ashman Gagari (14:37)

Yeah. And I would be remiss if I didn't add Apollo in there. It is definitely a smaller 0 to 1 product right now, but I did spend a chunk of time on that as well.

Rid (14:46)

Okay, cool. So now I want to add a little bit more clarity in terms of like, what the heck are you designing on Foundry? So is there some kind of like an example project that we could talk through to understand what it's like to be a designer in that world?

Ashman Gagari (15:05)

Yeah, yeah. I think Foundry I can maybe analogize to like the Adobe Creative Suite a little bit, where, you know, there are like seven or eight marquee apps and you kind of become an expert in each. Like, you know, there's not that many people who are like, oh yeah, I'm like a Adobe Premier expert and Photoshop and Illustrator, it's like you kind of become like one or two, like one or two workflows become your domain. So you're like a raster imaging guy or like a motion design person. So I think Foundry also has these Personas. You have like the data integrator, you have the data analyst, or you have the data scientist. So my point is there's like many different, like categories of people who use and play with data, and they range from slightly technical to like, extremely technical. Now, one of the projects that I worked on, on Foundry was around making the data integration story clearer. As you can imagine, Foundry's pretty much just an empty shell when you first land on it, and you need to hydrate it with data and the more information you give it, the better it gets. And as such, that's kind of step one. So I spend a lot of time working on exactly what type of data integration we need to provide, what type of different sources people are trying to connect from, and what are the first few steps people take when they are actually bringing this raw data and starting to clean it, transform it, join it, and turn it into what we call the ontology, which is essentially kind of an object aware, like data model that helps you make sense of the nouns and verbs in your organization.

Rid (16:34)

What have you learned about designing effective new user experiences, especially when your product out of the box is that empty shell that you were talking about?

Ashman Gagari (16:41)

Yeah. I think overall my philosophy on onboarding is that when you are designing for somebody who is willing to spend the time and willing to kind of get those economies of scale by first struggling through the learning curve, you just unlock a lot more. And I think I'm almost comfortable like following that Approach of like, this is not TaskRabbit or, you know, something where in between me downloading the app and me Getting value on TaskRabbit is like 10 minutes, 30 minutes tops, you know, and that's pretty amazing. It's a testament to their team that they've been able to optimize my click path so well that I don't even realize. And I have somebody at my house. And I think in the case of applications where you're literally buying this expensive, powerful Ferrari and you're going to like, use it to do Ferrari things, you know, you're not going to use it to like drive to the coffee shop. You're going to be like taking laps of like a racetrack. And I think, like, to me that allows you to kind of like take more time with the onboarding and add more complexity upfront without really worrying about like walk up usability in its pure sense. That said, we are obviously optimizing heavily for walk up usability. And from like a strategic standpoint, Palantir is obviously pivoting away from sending tons of people to your deployment to help you like, wire it up and instead allow you to wire it up yourself. And this is abundantly clear in the kind of earnings call data where, you know, we're literally starting to see people, like, time to value is getting down to like, days. It used to be months or maybe even years in some cases. These pilots used to take a long time. You need to wrestle with the, you know, the company's ID or you need to wrestle with their C suite. You don't even know how many other like, skeletons there are when you enter an org that you need to maybe like, deal with before they accept your solution. And I think this has become easier to do now. And I think, like, that is a testament to design.

Rid (18:38)

I would also imagine there are instances where you have to make decisions that try to strike this balance between abstraction in the name of some semblance of simplicity versus preserving the raw power of the Ferrari. Can you talk about that piece of the design puzzle for a second?

Ashman Gagari (18:57)

Yeah. I think one tool we use often is progressive disclosure. In these cases, there is some amount of concealment of the final thing where let's say you want to, you want to build a streaming data pipeline that requires something to be live. Like, the concept of liveness is suddenly very important. But we don't need to suddenly, like, just because you wanted to build a streaming data pipeline of stock data, let's say, like, I have a stock ticker, it's updating every millisecond, the price is changing. You know, all these things are happening and I want to just visualize that and maybe take some actions based on it. Now I don't need to understand throughput and all these concepts of streaming and like stream transforms and pipelines to just be able to put that together. I should technically just be able to do some sort of connect stream to dashboard workflow and then if there is a problem or a roadblock or additional complexity or configuration needed, click some sort of advanced button or go one level down and then play with it. And I think that's one approach which is just like slowly disclose what's needed instead of throwing the kitchen sink at the user's face. Right? And obviously that's easy to say and hard to do because it's easy to conceal something for the first time. But for the returning advanced user they're going to be quite mad. But that's where you get into kind of redundancy. So to me, the other angle here is you should be able to achieve similar workflows in multiple ways or at least from multiple entry points. So today we have essentially one application where I may do some sort of run or build or some sort of write based action like a big blue button that leads to the computer doing a lot of busy stuff. Now that button can either take me directly to the result of my computation, let's say I like filtered some data set, or I can click some sort of view progress button and be sent into a whole new app. Which is the only job of this app is to show me the build progress in excruciating detail. That's basically to me like opening the hood of the Ferrari and watching the engine as you're driving it, if that's even possible. But that's kind of my point. So I think like this is another kind of like escape hatch that's available to somebody who cares or knows or wants to debug. And if you don't, that's fine too. You can just hit build, look at the results of your data set, go on with your life. But if you happen to be that like data engineer guy who wants to optimize this pipeline a bit more, you might need to see like the spark build profile or like see exactly what kind of compute is being dedicated to this build. Mess with those constraints, tinker with it, look at the logs, stuff like that. So I think there's a way to serve both user types gracefully.

Rid (21:36)

I want to go back to something that you said earlier, then you talked about this idea of problem decomposition and maybe you could just unpack a little bit more about what that looks like in practice, especially as you're working through deeply technical problems. And for most designers, it's probably pretty unclear where the escape hatch is even could exist.

Ashman Gagari (21:57)

Absolutely. This, firstly, this is a good one because we call this internally, we say the word B comp a lot and everyone's always confused by it, but it basically stands for decomposition and I think is basically one of the most important differentiators of a designer's life at Palantir than compared to other places. And I think, I think this is because there is an abundance, like no shortage of complex problems. And maybe I'll just pick one in Apollo just because it's a little more recent. But essentially we have a software that allows you to manage and ship releases to various environments. And now the problem decomposition part here is that you will have a backend developer who will kind of maybe come to you with some sort of problem statement, which is that users need to be able to reliably ship the same software to a hundred different places without breaking a sweat. Now, that's a very generic prompt. But then you start breaking it further down and you realize, okay, I need to be thinking about who are the people doing this? Where is this journey starting? How many verbs and nouns is this person encountering on the way? You know, like, now maybe there's primary concepts like a release or an environment within the secondary concepts, like recall, where you can recall a release if it's bad, or maybe like promotion pipeline. This is another one where like you basically are like moving a release through these stages of like software quality. But it's like initially it's like a dev state, then it's a release candidate, and then it's stable. Now these are secondary concepts. So I think the first thing that I would do in terms of problem decom is understand and create some sort of mental taxonomy of all of these concepts and give them some sort of weight of like, what is the main thing that people care about and what are these like secondary properties or metadata that they may or may not need to encounter? And if they do, we can maybe wait a bit before we teach them. So I think those are the things that I bring to the table when talking to the backend developer about the ultimate goal. And the way you do that often is by whiteboarding together, really just kind of going through these steps. You know, often it's just boxes and words. We don't really need that many pictures. We can all Have a shared understanding of what things might look like. And I think what's most interesting is you do that with a backend dev, but you also do that with a customer user and then you may do that with some other like stakeholder who is maybe more product oriented and you'll find that the results are always slightly different. And you as a designer, you kind of need to triangulate between these three approaches and either be in the same room and hash it out or understand the delta between these and consolidate it. One of the most interesting things I find as a designer in rooms like this is to, you know, you're sitting there and there's like six people arguing about something and they seem to be agreeing on some aspect and they talk about it as if it's this, like this assumed thing that everybody understands and imagines. And then I draw it out immediately on the spot and screen share or put on the wall. And then they look at the mock or the design and they're like, oh, actually we're all talking about subtly different things. And the difference is actually more than subtle. When you bring it down to the back end layer or the implementation layer, it's like to have this information visible at this stage requires so and so API update. So just the power of an image as the uniting thing that brings disagreement onto one surface is to me maybe where the decomp shines the most.

Rid (25:24)

You have a pretty wide spectrum of fidelity levels for what that image could look like.

Ashman Gagari (25:28)

Yeah, so I used to do a lot of whiteboard sketching literally on live whiteboards in meeting rooms. And then we got into remote land. I then briefly spent spend time with concepts and on the iPad. Amazing app, by the way.

Rid (25:46)

Oh yeah, that's such a good app.

Ashman Gagari (25:48)

So I would screen share my iPad directly in these rooms of like 8, 10 folks and just be like drawing live ever since. My figma skills have just gotten faster than Concepts. So I'm like, I just basically do live figma. Everyone else's cursors are already on there. And we have a blueprint design system that makes it pretty easy to just like plop in the relevant components and assemble a collage of roughly what I'm thinking about. So in terms of fidelity, I would say it's all stuff that looks high fidelity but is not. And this is a disclaimer that I need to always make when I share these things, which is like, hey, we put this together using existing components, but that doesn't mean it's like ready to ship.

Rid (26:29)

Is there anything else that we should touch on just in terms of your personal process, maybe even outside of the meeting rooms. I mean, it feels like you are often being handed these pretty hairy problem opportunity spaces. What are you doing to make sense of that complexity and get momentum in the very early kind of onset stages of a project?

Ashman Gagari (26:53)

Yeah, yeah. And you know, this is something. It took a little longer for me to learn than I would have preferred. But asking dumb questions early and often is critical. And I think like it's easy to get intimidated, especially at Palantir where there's, you know, the subject matter is complex and the words being thrown around are heavy and obviously everyone you meet is very, very intelligent. And so you think, oh, this is not the right forum to ask this question. It is. You should absolutely just go ahead and get those clarifying questions out A and B, kind of find the right partner. Because we have a relatively flat structure, we kind of grow our PMs from within. There's a lot of fluidity in the roles and the titles. It's never clear what kind of org chart you're like looking at. And that's fine. Frankly, you shouldn't even worry about that. It's more just like suss out who cares about this and who has the right instincts to actually fill in kind of the gaps in your knowledge. There's three kinds of knowledge gaps that I typically find. One is domain specific. Literally just like, oh, I've entered this new world of healthcare or manufacturing, obviously I need to learn the kind of world they are in, what they are thinking of, their level of technical prowess, all of these things. The second one is like the completeness of the actual system. I think sometimes I design an interface and it's good enough. It does like 60% of the job and the workflow is clean and it demos well. But then I show it to the guy who's about to build it and he's like, these are the 15 edge cases out of which 4 are actually not even edge cases. These are just like generic cases that you haven't even accounted for. And so I think the completeness part is just like being able to poke holes in the system and the concepts up front. And it's really a game of whack a mole of like, hey, if I move this thing here, something else is going to pop out and become a problem. So then I have to squash that. And so I think you need to like be able to like traverse the 5,000 foot view, 30,000 foot view, zoom in and out and make sure that the whole thing works. But also the details work and you're not stuck in these degenerate cases with funky error messages that don't make sense. So that's the second one and I think the third one is just like proximity to the user flow or what I would call the golden path. So this is the opposite of the second one, which is like, worry about edge cases. The third one is like, don't worry about edge cases, just focus on the golden path and then worry about the smaller cases. Now I don't really know if there's some order or science to this. It's just something that you kind of need to suss out case by case. Sometimes it's easy, sometimes it's not. But I think these are the kind of three things that I personally try to bring to most projects.

Rid (29:31)

I love the call out between the golden path versus the edge cases because in my experience that's like one of the hardest parts of being a designer is knowing when to let edge cases steal from the golden path versus when to say, nope, we're going to prioritize the golden path here.

Ashman Gagari (29:51)

In our case, maybe we're a bit fortunate we're not building an app that is used by 3 billion people for one minute a day or whatever. You know, like that level, it's more like it's 100 people, but they're all PhDs. They're using a 9 to 5 and they're making some crazy stuff on it that's like going to have more downstream impact than you can fathom. And so I think like, I have the luxury of being able to sit next to that so called PhD person and just literally bother them and be like, why did you click that? What does this word mean to you? Why are you even here in the first place? Why don't you go do this this other way? You know, like really get down to like that level of conversation. And I almost don't even call it like user research at that point because it's more just like I'm just like trying to be best friends with this one person.

Rid (30:37)

Yeah, you're like an account executive almost at that point.

Ashman Gagari (30:40)

Exactly. Except I only know I only care about the design part and not whether or not they pay us money. And I think that's kind of the interesting part of the user side. So I think if you do more of that, these priorities become, they kind of become clearer through that process of like this edge case was only visible to us internally because of the scale of the data we were hosting. It's not even a problem for our user because they have three environments and we have 200, so maybe let's stop designing for that. So I think it's like basically just seeking the truth really helps winnow out all the unnecessary edge cases and then focus much more on the ones that are truly going to be blockers. When you work with developers, they come up with these cases immediately. They have this amazing systems thinking way of just looking at your design and immediately talking about the three things that are missing from it that will result in a funky state. And I think that is its own great exercise, but I like to balance that against the user side as well. But it's like, yes, obviously we can spend all day ideating the thousand ways in which this can go wrong, or we can just find the two ways in which this will go wrong and design for those.

Rid (31:53)

Well, on that note, I have multiple unread emails in my inbox like right now from people who are trying to figure out what good systems thinking looks like and how to grow that muscle. And I'm wondering if I can just outsource that question to you.

Ashman Gagari (32:09)

The typical things I find or failure modes I find are like not zooming out of the problem that's been given to you. And maybe we can just use a simpler example like I don't know, like Uber or something not simple but you know, at least user friendly app that everybody knows consumer space. And let's just sort of break down the Uber app through a systems thinking context. What are the main primitives of this app? The rider or the passenger and the driver. These are two things, two sides of the coin. And there's the actual route or the destination. And really these are kind of the three main primitives. Then there are like sub primitives, like the, the number of the car, the destination, like the estimated time, maybe the type of Uber X versus Excel, what have you. We're already creating a mental model of all of these things. So that's kind of one type of system that you're creating. Literally just a taxonomy or mental model of like what are the main objects, sub objects, what are their properties? Are there many to many relationships? Many to one? One to many. That's important, right? Like when I call my Uber, it's one to many, it's me and 50 cars, one of whom will be my ride. Then it goes from that to one to one and remains that way until the ride ends and there's a life cycle attached to it where it's like this thing has a timestamp of like the moment Me and the driver are now aware of each other's names, details, locations, and the moment the ride ends, that is severed again. So there's a life cycle aspect. So I think if I were to do like a systems breakdown, one system is the actual nouns, verbs, objects, primitives, whatever you want to call them, and how they relate to each other. The second system is much more transient or like time based. This is typically what people call the user journey or the user flow. But it's not just the user journey. There is like the user journey and the computer journey, if you will, and both are actually traversing this thing together where it's like, if you ask me how was my Uber ride, I would be like, I was the passenger, I called it, I then waited for it, I got in, I drove, and I got off. Those are maybe the milestones of my Uber journey, right? If you ask the rider, it's slightly different, but it's similar enough. But if you ask the computer what was the computer journey for, like the Uber backend or whatever crazy alos they had, they would be like, oh, yeah, we had to run a matching thing for somebody here and somebody there, optimize it based on so many conditions, including pricing, geography, what have you. And then we had to turn on this essentially security switch, which allowed the rider and the passenger to know a lot of information about each other, which is obviously quite scary from a security perspective. And then we had to toggle that switch off in a way that will prevent them from ever meeting again, which is also a security issue. And this is a crazy complex story from the engineer's perspective. And so I think being able to draw both these journeys together will A, make it easier to design for technical spaces and B, actually, I don't know if this is the right way to put it, but like, empathize with the computer a little bit and see how your human concepts such as wait time and like, I don't know, estimated time of arrival actually, like, are derived and how you can actually design for those lags or delays or errors or whatever. So anyway, that was the second one, I think, roughly speaking, there is the system or the data model. The second is like the timeline or the story from the computer and the human's perspective. And the third one, I think from a problem decom perspective is the domain. Just knowing the domain is critical after a certain point. And this is again easy when it's an Uber, right? You've taken one, I've taken one. We can empathize with each other ad nauseam. This Is not true when I'm designing some sort of hospital interface for a doctor who is every night or a nurse who is every night submitting some amount of information about diagnostics or available beds or throughput or something. And so I think understanding these words, concepts, what's going through the user's mind when they're doing it, what are the other tabs on their computer? Are the other tabs like GitHub and VS Code or are the other tabs Slack in Asana? That's going to change the data density I designed for. That's going to change the like what we were discussing earlier about like the progressive disclosure. Like I can maybe throw more information at you if you already know a lot of computer science terminology, for example. So I think like, obviously user empathy is really what it boils down to. But I think shoulder surfing, being friends with this person, learning that domain, like I became really into manufacturing just like by mistake or I became really into like drug development. And I was just like reading books about it and then covet hit after that and I was like, wow, like everything I've learned about like drug development is suddenly like really topical and valuable. And I think this happened because of just like deeply embedding with the domain.

Rid (36:56)

I have a smile on my face because just listening to you talk like, it's so clear that you have put in the time collaborating directly with backend engineers. Yeah.

Ashman Gagari (37:06)

Oh yeah, I love them. I must say that's like one of my favorite parts of the job is just like, like being able to honestly articulate my own problems. Like, you know, I think it's like two, it's almost like slightly different versions of the same language, like Spanish and Portuguese or something. But it's like we're both talking to each other in this like similar ish language, but we can't get into the nuance together. And that's where my like drawing comes in. So I draw and the engineer kind of talks over it. And those are some of the most fulfilling partnerships.

Rid (37:36)

Anything that comes to mind in terms of how you've grown over your now almost six years at plant here, in terms of like how you foster those relationships with backend engineers and communicate more effectively.

Ashman Gagari (37:47)

So I, I never like, not ask questions up front. Like even if I'm in a new space, new room, maybe I'm junior or out of whatever, I'm still going to just be like, forgive me for the dumb question and ask it. And I think that goes a long way just to like format of asking instead of asking you like a, like, you know, an asshole. You can just say it a bit nicely. And I think that's, that's critical. But overall, in terms of growth, I would say the reps, the reps really matter the most. I think when you design similar ish interfaces across various domains, across various technical competencies for different users, and with slightly different, like technical, like power, you kind of realize that a lot of these things can be broken down into kind of a catalog of workflow types or archetypes you can think of. I'm on my 10th inbox view and it's like this inbox view comes with a list of notifications which are transient, where if I act on them, they disappear, versus an inbox view where I act on it and it remains. So that's a case management view, right? And they look the same. It's just like stuff on the left, preview on the right, click on the thing, take an action. But the state machine is very different because the notification, the moment I click it, it's gone, it's disappeared, it's transient. And that has implications on the API. Whereas if I'm doing a case management work, let's say I'm like a lawyer or a law firm now I have an inbox item called get Ashwin's visa to Spain. And that's going to live for like one month till I get my visa. And it's going to have like states of like, okay, visa in process, visa delivered, visa waiting, whatever. And so I think even though these things look the same, once you start breaking down them, breaking them down into kind of these typologies or archetypes, you can start to apply them regardless of domain. And I think that's the thing I learned maybe like two, three years in and has been very, very useful for me ever since.

Rid (39:39)

Hey, it's Rid. I'm constantly asked about my favorite product, so I'm going to take just one minute and give you a quick rundown of my stack. Desen is how I ship design changes without having to code. Framer is how I build my websites. Genway is how I do research. Jitter is how I animate my designs and Play is how I design and prototype mobile apps. Visual Electric is how I generate all of my imagery and Raycast is my shortcut every step of the way. Now I've hand selected these companies to partner with me so that I can do these episodes full time. So the best way by far to support the show is to check them out. You can find the full list@dive.club, slash partners. Okay, now on to the rest of the episode. There's a density to this conversation that I so appreciate. But again, I kind of want to like double click on things just as a way to really help it take root for people. So, yeah, I want to return to like, the data model piece specifically. Do you have any tips or mental models or just general advice for someone who maybe hasn't spent that much time thinking about the way that the data model impacts their design process?

Ashman Gagari (40:51)

Yeah, I think before I do that, I just have a disclaimer which is it's a privilege to have these problems to design. Like, I interview a lot of people and I look at a lot of portfolios and you know, obviously I'm not out here asking for Palantir shaped projects because there's a finite number of those. Like, I'm more than happy to look at your, like, design for a calculator app and get to why you made a certain decision and use that to understand whether you're going to be a good candidate for Palantir. That's completely fine. But going back to my point, I think it's just that there really isn't that many of these complex data model issues out there. Like, even if you think about, let's say I'm designing a food app, the concepts are already clear. There's already a lot of stuff that's optimized, like E commerce, like, you know, the gig economy. All of these, all of these applications come with like predefined templates and like, you kind of don't really need to like rebuild from the ground up. The place where this gets novel and interesting is A, in the enterprise, where you're designing something for something crazy bespoke, where it's this industry that has not really encountered technology in its full form yet for whatever reason, there are many of them. Y Combinator is out here trying to get all of them. But I think fundamentally the idea is like, okay, if you're in one of these complex domains or industries, then the data model topic suddenly becomes important. It's like, what are the actual things that the people who use the software think about on a daily basis? Again, I'm sorry to keep talking about the verbs and nouns, but really is that like, if you can articulate A, what the nouns or the primitives of your business are, and B, the actions you can take on them in a holistic way that you're already halfway there and then you just need to kind of stack rank them of like, which of these are More important than the other. And like, for example, like as a rider of Uber, I want to ride to my destination. That is like far more important than, you know, I want to sit in the Camry and not a Corolla. And so I think like to me creating these narratives, or I like to put it as a sentence, some people don't like to me, like, if your thing doesn't work as a sentence with like a subject, verb and object, something's wrong with your mental model. I think if you start to do those types of things, you can start to pressure test if you got the concepts right. And I think Apollo is a great example here because it really was a novel platform. Maybe I can do a quick summary of what Apollo is, please. So it is essentially internal tool originally actually, which was used by Palantir to deploy all of our software to the various disparate environments and deployments landscapes out there. And that includes we have Palantir software running on like the edge, so like a satellite or a drone or a submarine, but also a data center, also the basement of a bank. And there really isn't any software out there that lets you, in a few clicks, manage the deployment of the same package to these 50 disparate locations reliably, securely and predictably. Right. And so I think when we were designing that, that's when we were suddenly reckoning with so many new concepts that had never been like in one place before. That was really interesting from like a design decomposition perspective. And I think I went back to kind of the release management one where like I have a Release, let's say iOS for simplicity now, before it actually goes out to the billion users, it goes down, it goes out to like a subset of 100k users and it like sits there for three months in the release candidate state and then it gets bug fixed and then it gets shipped to prod or production. Now this is a promotion pipeline and your releases are being promoted through this pipeline. And as such, the noun we have now is a release. The verb is like promote or recall. So it's like move up or move down. Now when I recall, it's going to have massive second order effects on many other releases because this release has 50 dependencies, which by the way is a secondary primitive, but also a noun. Right. So I'm just out here like underlining the words that are like, you know, the data model versus just words that are like filler grammar. And so I think if you can start to articulate all of these as actions on objects and the RAMIFICATIONS of each of those actions. You suddenly get like an end to end user story or computer story and you can start to like, then design the interface around that.

Rid (45:18)

I feel a little bit of conviction because I'm working on a new project right now and I still haven't nailed down some of the core pieces of language. And so like even talking with engineers, like I don't know what the core nouns and verbs are, and yet I still have a lot of UI created.

Ashman Gagari (45:32)

And I will say, by the way, that it's not a linear process. Like it's completely fine to just emit tons of boxes and not be sure about like what goes where and why. And that's, that's, that's kind of, to me, the generative phase. And that's actually one of the things I love to do is just make the wildest vision version first, frankly, without knowing how the technology works in my mind. Speaking of Apollo, actually, ironically, the best Apollo is no Apollo. You should not need a software to shepherd your releases from your computer to the target. The computer should do that if you define the constraints well enough and don't even think about AI, even just in a pre AI world, if you design your constraints well enough, design these pipelines and these rules and policies, it should just flow and it should just ping you when you're needed. It's like, oh, I tried everything as a machine and now I need human help. And then you get a little notification on your iPhone and maybe you just like slack it, you know, And Apollo could just be like a chat interface at that point. But instead it's, you know, obviously this like massive enterprise app with like many tabs and low padding. But I think like, overall that's, that's kind of where I would start. So going back to your project, I think it's, it's totally fine to kind of go from both ends of the spectrum and then like meet in the middle. And that's when these like nouns and verbs start to harden, I guess.

Rid (46:55)

You mentioned the hiring piece. I want to touch on that briefly. Like, let's say someone's listening to this, they're inspired, they want to join your team, but they have exactly zero enterprise design background. What would you want to see in their portfolio that would make you confident that they could succeed at Palantir?

Ashman Gagari (47:13)

Yeah, so this is quite a common scenario, obviously. I think firstly it's completely fine. Like, I think we already, we get a lot of people who have four projects and one of them is a dashboard and it has some Charts and they're like, this is the Palantir project. It's like, no, I do not. We've got that figured out. Like, we've, we've got dashboards figured out. You know, we, we don't need the 55th histogram design. Like, we are good. I think what we need is somebody to be able to talk about the data that led to those charts. And what happens if I filter that chart and what happens if I, you know, hover on this thing or if it happens to be a billion rows instead of 100 rows? Or like, how does your table work? Can I group by, Can I sort? So like, basically, if there isn't that much to work with, I'll go deep and I'll ask like highly specific questions about state machines to understand if they've really thought about the details. Because often I'll just see like a tab with a table. And let's say, let's just use Ramp as an example. Beautiful app, has lots of tables, nice ones. And I think like, simply speaking, it's a table. Cool. Doesn't look like much, but there's a lot of nuance in there. You know, there's like certain things they allow, certain things they don't. Some types of sorting and filtering are good, some are not. That's opinion. And I think that type of opinion being built into just a generic table is actually enough to talk about for half an hour or whatever the interview length is and gives me enough signal on whether you are like thinking thoroughly about the system and b, interrogating the actual data and the structure of the information that's being presented. And it's not just like a UI exercise of like cells and columns and rows. So I just picked the table as a simple example because, you know, there's, there's so many of them. But let's say the designer doesn't even have a desktop app in their portfolio. They just have like some mobile app that's fine too. Like even if it's a calculator app or a weather app, there's so much that you can, you can kind of derive second order complexity questions out of anything. Like even the weather app, if you just keep scrolling, there's like so much more in there. There are 50 ways to show feels like there are so many ways to visualize highs and lows. There's like a visual design angle, there's a typography angle, There is like the systems angle of like, which information do I show where there is the usability angle of what you Said of do I even care about feels like and wind direction or do I just want to know what if my weather app was just like wear a sweater today. That's all it said. No temperature, no color, nothing. All it says is just a picture of the outfit I should wear. That's the weather app. And that's a conversation I'm willing to have for half an hour of like, hey, I made this insane weather app at the media Lab at mit. I just assumed that somebody there would make an app like this and I would happily discuss it. You know, I think that's fascinating to have a weather app that's just like gaslighting you into wearing clothes. Anyway, I think I got, I lost track.

Rid (50:03)

No, no, it's good, it's good. It's like even some of the action items that I'm kind of taking out of this is maybe there is an opportunity for designers to stand out by proactively getting incredibly deep into one portion of a set of designs in order to demonstrate their ability to communicate that level of specificity and where the micro decisions existed and why. And in doing so, that maybe would speak more to what you were looking for than even the holistic presentation of the entire project.

Ashman Gagari (50:37)

Yeah, and I would say that that's more out of necessity. Like just to be clear, like, it would be really nice and ideal if you also had a more holistic platform level project. But the reality is that not every 21 year old is going to A, have access to a platform level design problem and B, have worked at that job long enough to have designed it. So I think it's unfair to be to somebody out of school to be like, where is your foundry? You know, why don't you have like six years of ramp ui? So I think to me it's like it's completely fine for you to show us your college portfolio. And if it's not about the details and micro interactions, it could be about the user empathy. I would be more than happy to spend 20 minutes going about, oh, we were trying to design a UI to book classes. You know, every college student has an app that's like book class. Booking UI for my college because the current one sucks. Cool, Sounds good. I mean, even though this has been built 10,000 times, I'm down to discuss this now. It's not about the fact that it's just like yet another like booking ui. It's more about like, what are the nuances that makes this booking UI different from the one at five other universities? And maybe it turns out that there's a, there's a sudden certain like, like weirdness in the calendar or like there's a, like for example, I went to RISD our first year. We didn't have any sort of classes. We just had to. They just told us what we would do. We would do these three types of studios the whole year. We don't pick anything. You just show up eight hours a day and come back. Now the class booking UI there is very different from like somebody at Brown up the hill who were just spending half their days in this tiny little calendar app trying to pick the right classes and you know, trade offs and stuff like that. So I think like proximity to users and talking about like their problems and how that reshaped your assumptions is also an equally valid and fun interview conversation.

Rid (52:36)

When we first talked, you mentioned spending some time mentoring younger designers at Palantir. Yeah, and you know, we've covered a lot of ground in this episode, so I kind of just want to have like one final catch all. So are there any other ideas or learnings that you're instilling in other designers to help them succeed at Palantir?

Ashman Gagari (52:58)

Yeah, I mean very practically I manage six designers, so that's, you know, obviously through that I get a lot of FaceTime and one on one time with them, I work directly with two or three of them. So we are actually co designing. We're in the same Figma files, we spend hours together just literally like you know, doing good old designer stuff. And then the other three or four I would say are in other parts of the org. But obviously I'm like well versed in roughly what they're working on. And so with them it's a slightly different like relationship. About half of it is like Palantir shaped stuff like org navigation, the autonomy piece, you know, like the autonomy is a blessing and a curse. Like if you are the kind of person who's like shy or like unsure about asking questions up front or like, you know, being uncomfortable in large meetings, maybe that's something to work on. And so it's like, okay, like as a designer you are like a first class citizen of this meeting, even though you may sometimes be the only one. And there's like five other technical people saying technical things all the time. And it's very common to only understand like 20 minutes of a one hour call. And that's fine, like it's okay to do that and it's okay to just be like, hey, I literally don't understand half of what you said, but this is my question. And these are my problems as the UX designer. Can we work on it together? And you'll find obviously everyone is more than happy and helpful. So I think like a lot of the work is like empowering designers to operate in technical spaces where they may sometimes feel like outliers. I think another piece is. And so that Autonomy piece obviously has other angles too, depending on the profile of the designer. But it's like again, asking questions early and often. Drawing being generative. It's better to make 10 things without knowing how it works instead of just versus making one thing after spending one week reading 10 books and 15 documents and internalizing it. We don't want academic PhDs. We want just like doing. And I think creating interfaces, no matter how shitty, is a much better way to get to the truth than to ideate and use words and like, you know, kind of talk to people. Like 10 meetings is not worth it. And if you are having 10 meetings, take a picture to each of them. Take 10 pictures, show all 10 of them. Let the work speak for itself and only speak when the work is unclear. And I think that creates like, that starts to become faster over time. Where like it used to take me like four designs to get to good, now it takes two. And it's the same idea of like, how can I short circuit the iteration process? Because I've been there before. So that's kind of the like palantir specific stuff. And I think there's a lot more that falls out of it that's, you know, like, hey, like this team operates this way, that team is more structured but operates, blah, blah, blah. And I think those are just like tribal knowledge things. But the other thing that I like to focus a lot on, and this is maybe a Palantir thing, I don't know, frankly, I've only had two jobs. But I think the thing we optimize for are generalists, design generalists. So maybe you can call them full stack designers. I don't know. Obviously there is no such thing as a designer who's good at all of those things. You may be a user research person. You may be a creative coder who actually loves the CSS and the JavaScript. You may be like a UX decomp person who just revels in the diagrams and you know, the 0 to 1. Or you may be like a visual craft person who just like playing with the drop shadow for like six hours, like that's fine. All of these are good things. My job is to like identify those spikes and let you lean into them while also creating some level of baseline on the other things. And I think that's something I actually derive a lot of enjoyment from. Because it's funny, like, every time a new hire joins or like, somebody, you know, I get a new person. They. They kind of. I asked them, you know, what. What do you think are your core competencies? And then you watch them, like, evolve and realize, like, the difference between what they thought they were and what they actually were.

Rid (57:03)

That's cool.

Ashman Gagari (57:03)

Or they. They just lean really into the one thing that they knew they were amazing at. Like, I had somebody who was just like, been doing graphic design since he was, like, 8, and you could just tell, like, you know, you can tell when somebody grew up using, like, CorelDRAW. That's a different type of designer than somebody who's like a Figma native, you know, and you can kind of, like, start to, like, suss that out. And so we spent more time on, like, typography, and just, like, you know, I showed him, like, Paul Rand and I was like, read these books. And then with another person, it was much more about, like, like, dogfooding the software we actually use and, like, business strategy and, like, you know, like, maybe almost like a product management Persona. And so for that person, I spend more time talking about, you know, the actual business and how Palantir is, like, organizing itself around, obviously, as, you know, like, the crazy, like, surge we've had in demand and value and what does that mean for the business? And I think it really just depends on their interests and how I can grow them as well. Obviously, I have to, like, balance this against the business needs. That's obviously something that I, you know, it's like, oh, we need X Designer and X Place, cool resourcing game. But that's different from the kind of growth conversation that you asked about.

Rid (58:18)

Well, this has been cool. I really appreciate you coming on and you've definitely, like, 10x my knowledge of Palantir. And it's really, really interesting the types of problems that you're dealing with there as a designer. Super inspiring stuff and appreciate you taking the time to share it with us today.

Ashman Gagari (58:33)

Of course. Yeah. I feel like I definitely just, like, spoke too fast and went through a lot of stuff, but hopefully there was something valuable in there for everyone.

Rid (58:42)

It was a very practical episode and exactly what I was hoping for.

Ashman Gagari (58:47)

And I mean, for anybody listening, I think we love design at Valente. We really need to have a healthy, strong design. Org as we enter this next phase. And yeah, just would love to have tons of new applicants or something, you know, coming up.

Rid (59:02)

Well, you can check the show notes and I will include your Twitter careers page, that kind of a thing.

Ashman Gagari (59:08)

Perfect. Perfect. That would be great.