Loading summary
Transcript46 lines
- [00:00]
A
So there's this debate that I'm seeing with the new wave of designers. What is your guys take on this? Design in code versus design in the
- [00:08]
B
canvas debate and the Overton window have shifted so quickly from my teams being AI curious to like banging down the door. They can't move fast enough without it.
- [00:16]
C
If developers have been accelerated, say like 10x designers have maybe been accelerated like 1.5 or 2x. So design can become the bottleneck.
- [00:24]
A
This is Ed Bayes, head of design for Codex at OpenAI. And this is Guy Seyad, head of design for AI at FIG. Where is the line now? These designer and engineer roles are clearly merging.
- [00:38]
B
The empowerment that has come from AI has meant that this idea of roles and rigid org structures is kind of slight. Starting to diffuse a little.
- [00:46]
C
Yeah, I would agree with a lot of that. I can then copy a link to this component and then I can just paste it in here and say update my code with change I made here. I also think it's like really fun time to be a designer because your imagination really is the only upper limit now.
- [01:01]
B
I don't need to now I can just ask a question and be like can you build this? And if it starts to do something I can ask.
- [01:11]
A
Before we go any further, do me a favor and check that you are subscribed on YouTube and following on Apple and Spotify podcasts. And if you want to get access to amazing AI tools, check out my bundle where if you become an anal subscriber to my newsletter, you get a full year free of the paid plans of Mobin, Arise, Relay App, Dovetail, Linear Magic Patterns, Deep Sky, Reforge, Build, Descript and Speechify. So be sure to check that out@buildle.akashg.com and now into today's episode. When should you start in code and when should you start in Canvas? What does this step by step roadmap look like for designing in the new AI design workflow? And how should PMs be working with designers and engineers in 2026? They share everything. There's a million people talking about design with AI, but few sit at the frontier like Ed Bayes and Guy Seas. Ed is the head of design for Codex at OpenAI and Guy Sayes is the head of design for AI at Figma. These are the two companies defining the future of AI design and today they're answering how you should design with AI, how you should move from Codex to Figma and back again, how you should start in code and when you should start in Canvas. They're giving you the roadmap so that as you are designing any product, you can design it with the latest and greatest tools. This is never before seen access and they rarely do podcasts. You're getting a once in a lifetime opportunity to learn design from the best guy. Ed, welcome to the podcast.
- [02:38]
B
Thank you for having me.
- [02:39]
A
So there's this debate that I'm seeing with the new wave of designers. One prefers the flexibility of designing with code, using Codex to actually lead the design process and maybe bring figment later. The other still prefers the free form of the canvas, the more traditional design process. What is your guys take on this design in code versus design in the canvas debate?
- [03:03]
B
Yeah, I, I think we're in such an interesting time right now where finally we don't really have to choose. And so the, this, the two camps to me are really interesting because I've often found the canvas to be a place where I can just quickly riff on ideas and do a lot of lateral exploration. And I, I still feel this the gold standard for that. Whereas code has just enabled me to go super deep and really make my ideas real very quickly. And before I used to have to choose like which kind of mode do to engage in to get to the thing that I want to do and now I kind of don't. And I think the new kind of shift that we have to embrace, that we should embrace is like navigating seamlessly between both. Which is why I'm really excited to be here and talking with Ed about how we enable designers and PMs and teams just to move fluidly between AI coding and agents like Codex to kind of move between exploration and convergence. And so yeah, yeah, it's a good
- [04:04]
C
question and I think it's a little bit of a false dichotomy in a way because as a designer, as a creative, you have a toolkit and there's the right tool for the job. So you know, if you can code and you want to test out some interactions, hopping into a code base, you know, is maybe the easier option, right? You can just even create a branch off main and you can kind of play with a prod version of what you're jamming around with and you can test stuff out and it can all be live. But just like there are still architects out there who still work by pencil, there's a sliding scale of how you represent ideas. And I think less than kind of getting into this kind of deeper philosophical debate around what is a designer today or what should they use. I think I just come at it really Practically, and I think most of the team here do that as well, which is if you're being super exploratory, you want to sketch stuff out. If you want multiplayer, you want to be able to collaborate and comment and show work and print it out and put it up on a wall and, you know, tear it down. But, you know, the role of a designer is pretty expansive. And if we're shipping a product and we want to get the last, you know, mile of the product up to this, you know, the bar that the kind of designer aspires to, then it just opens up the opportunity for designers to hop in and ship PRs and do that side of stuff. So, yeah, I think less of it in some grand philosophical take and more around, like, what's the right tool for the job. And if I was a young designer today, I would be like, so excited to hop in and like, have these insane new kind of like, box of toys, frankly, to just like, build all this fun stuff. So I also think it's like a really, really fun time to be a designer because your imagination really is the only upper limit. And now you have this, like, really broad range of flexible tools that can, that can help you bring your idea to life.
- [05:52]
A
So I'm hearing from both of you that it's a false dichotomy, really. It sounds like designers need to be able to use both tools effectively with each other. What are the tactical ways one should think about this? When do you start in code versus start in a freeform canvas? How do you go back and forth? How do I think about when to use which?
- [06:11]
B
It's a really interesting question because it's kind of grounded on this, like, dogmatic approach that we've had to the workflow. Historically, because of tool constraints, we've had to start in low fidelity and work our way up into high fidelity because it's expensive to do high fidelity. And so we've created this very standardized way of working that started from that, from paper doodles and lo fi prototypes all the way to code. And now our low fidelity start can just be jumping into codecs and doing a functional wireframe. The point is, can I start working from something that gets the team talking and gets us thinking about the shape of the material, the shape of the solution, and then, then from then I can start bringing that into figma and working into, like, okay, well, my wireframe no longer needs to be a doodle that I made with a marker pen. Like, it can just start being something that's functional and gives me a lot more dimensionality to the problem. And so it really just depends on the level and the scale and the type of problem. If it's like you're working on how to finesse a certain component, maybe you want to start shredding code. If you're trying to figure out how you might lay out a whole flow, it might help you visualize the whole flow in front of you and try to understand where it breaks versus building into a flow. If you're trying to go wide and really try to break a paradigm of interaction, you might want to just do a lot looser fidelity rather than try to wrangle a model to get to what you trying to do. So it really just now, like I said, you get to pick whatever tool helps you get further with your team. And I think that's. Yeah, it's a really interesting and challenging time for teams that have been reliant on a specific type of workflow that now you kind of get to invent whatever workflow you want because we're making it easy for you to extend that workflow however you want it.
- [07:57]
C
Yeah, I think just to add, I think it feels like we're going through this kind of rapid pace of change where weekly there's a new thing, there's some very cool new things we're figuring around this week, which we're going to chat about. But the underlying design process hasn't changed as well. You're solving problems, you're representing things in different ways, you're rallying teams and you're building a vision of a future and you're kind of bringing people into that future. So it really depends what your objective is when you're designing. Might be maybe you're designing a hero image to rally people around it, then you probably want it picked perfect. So maybe you want to step into Figma and inspect stuff out there, or maybe you're getting really crisp on design systems and you're thinking about how different components interact with each other and how they might look in different states. Again, maybe you want to be in Figma and you want to have all of your tokens or you want to be able to do all of the color tests and really in the weeds detail kind of draftsmanship type stuff. But then say you're doing something that's more responsive, so you're testing a product on how does it look on mobile web or across different breakpoints, or you want to really test a bunch of different kind of approaches to something or some really interesting interaction design paradigm and there it's like, well, you kind of want to get into the messiness of code and be able to play around with it, shapeshift things. So, yeah, it's funny, it's not as simple as kind of like, okay, let's start in, say, Figma. And then we end up in code. It is this often back and forth. And I see this on the team, when we bring people in, they're like, so, what's the current state of play for the product? And it's like, where's the figma? And it's like, okay, well, it's really well specified here at this early stage. And then there's other bit. You probably just want to bring up the product and look there. So, yeah, it's not as simple as start in one place, end up in another. You kind of weave in and out, out, and it becomes way more fluid. Which is why I think a lot of these cool new integrations that we're going to chat about today are really amazing because then the handoff between these tools is a little softer and it becomes like, way more fluid and just like, easier to work across these different materials.
- [10:07]
A
I think that's where a lot of people's heads are going to go, is, can't you have a lot of lossiness as you translate between these tools? How do I do this seamlessly? So instead of talking about it conceptually, can you show us, Ed, how you actually practically day to day are bouncing between these tools, what this design workflow actually looks like?
- [10:25]
C
Yeah, totally cool. So I've opened up Codex, which is our desktop app. Right. We have. You might have seen there's a terminal product, there's a, you know, IDE extension, but this is our kind of standalone app. And the way that it works is you basically just open up, you add a new project so you can open up your local, local folder. It could be anywhere. It could be desktop, could be downloads, could be like a, you know, like a repo that you already have open and you can kind of just get jamming. So I've opened this thing, it's called Codecs Composer System. So this is a good example, actually, about what we're talking about. So I've already specced out a composer in Figma, but I want to test out some interactions. And this is where I think working in code works really well. Right. So if anyone's used our product, we have this kind of dynamic composer system. So if the model is asking you for permission to run a command, for example, it'll pop up this, like, permissions kind of special composer treatment like this. Or if you're in plan mode, it might ask you some questions and you can kind of toggle through and go back and it's just like dynamic system. So I built this out in code because I wanted to test these interactions, right? How the buttons morphed into each other, how the size works, like, you know, where are the different, you know, tap targets and things. But say I want to like go deep on a particular part of this and I want to maybe go, okay, I've sketched this out now I just want to get really pixel perfect. I want to make sure the icons are my icons. I want to change maybe some of the labels, right? I could then basically bring up codecs and I'll use this fun thing that I use a lot, which is this pop out window and I can just drag it over the top and I can say, okay, I want to import my homepage and a few composer states. What should we do? Let's do kind of like composer permissions and plan into a new Figma file. In my default account. And then I'll just type in at and I'll tag in figma here. You actually don't need to type in Figma. It will just. If you say Figma, it'll probably just trigger it yourself. But this is another entry point. We also have this plus menu here and you can install a plugin which you install from the app itself and then you get going. And you know, because it's getting to know the file system first, it might take, you know, a few moments just to, just to get going and to read everything. But maybe as it's doing that I can just talk through what's going on here, right? So first it's getting to know what's going on. So I just have like a React app and then it's going to dig into the Figma MCP which has a few really cool things which you know, is probably better, better place to speak to than I am. But there's really cool functionalities that the team team has used, which is one is it will go into file and it will basically kind of pop open a window which it should happen, should happen any, any, any minute now. And this very call interaction happens and it basically like takes us, takes a kind of snapshot of what's going on and then it will take it and then you just kind of click open in figma and it will open a Figma file and it will kind of basically copy anything that you want. So you can do interactions you can do, you know, whole, you know, whole websites and then it kind of specs it out in kind of full flow.
- [13:47]
B
The other thing that you can do, especially given your prototype, is you're able to also select specific components. So in that example, for example, you only had the text box and you probably don't need the big white rectangle behind it if you're already working on that. So it also allows you the ability to go down your kind of nodes and select the one you actually want and just iterate on that. So we want to give you as much flexibility as possible to just work with the data that you want.
- [14:13]
C
Cool. So as I say, it's just popped it open and it's pretty cool. It's like. So, yeah, to your point, right, you can go in, you can choose to select an element. There's a whole bunch of other fun stuff that you can do here. You can do the entire screen and then I just click Open file
- [14:33]
B
and
- [14:33]
C
it will just open up a new file and it will have that composer stay in there. And I think that the thing that has been very cool for me as a designer, okay, it's doing a few different screens now, so in the background. Yeah, so it's pasted in these files here. And as you can see, it's based in the screens that I mentioned. And the very cool thing is as you click in, everything is like responsive. So all of the exact pixel perfect things, right? The padding, the border radius, it's exactly one to one with the file. Whereas previously engineers might have to go in and they have to look at the separate numbers and pull out the different, oh, what's the shadow of this? And what are these XY values? It just does that out of the box, which is, I think, very cool. And then user designer can go in and maybe I want to spec this out. Maybe I want to play with color and I can in here, test out a few different shades of green or change some colors. And then the very cool thing. So like, you know, this is just a small change, but let's say I end up changing the model and we've recently like recenter model. I can then copy a link to this component, copy it into selection, and then I can just paste it in here and say, you know, update my code with the change I made here. And now this will go the opposite way. So if I bring up codecs again and I just run localhost so I can get it running. Okay, sorry, demos. But yeah, you make some local changes and then you can Just paste that link back into Codex and then it will make that change in your code. So yeah, this handoff is kind of seamless. So like maybe you're a designer who can code and you can kind of weave between these, but maybe you're not. But this doesn't block you right now. You and your engineer can kind of collaborate in a more seamless way and it no longer becomes these like siloed areas. It's like way more fluid and the handoff is like much simpler.
- [16:45]
A
Here's the dirty secret about prototyping. You spend two weeks building a prototype, you validate your assumptions. Engineering loves the direction. Then what happens? You throw the whole thing away. Bolt changes this completely. When you prototype in Bolt, you're not building throwaway mock up. You're building real front end code that integrates with your existing design system. So when you hand it to engineering, they don't throw it away, they ship on top of what you've built. I use Bolt every single day. I host my land PM job cohort on it. And honestly I'm up till 2am some days just vibing in the tool, having fun and building. That's when you know a product is good, when you're using it past midnight, not because you need to, but because you want to. Check out Bolt at Bolt New Akash. That's B o l t.new aakash link in the show notes. Today's episode is brought to you by Amplitude. Replays of mobile user engagement are critical to building better products and experiences. But many session replay tools don't capture the full picture. Some tools take screenshots every second, leading to choppy replays and high storage costs from enormous capture sizes. Others use wireframes. But key moments go missing, creating gaps in your understanding. Neither approach gives you a truly mobile experience. Amplitude does things differently. Their mobile replays capture the full experience every tap, every scroll and every gesture with no lag and no performance hit. It's the most accurate way to understand mobile behavior. See the full story with amplitude.
- [18:10]
B
And on the lustiness thing, it's really interesting because, like, it only gets better from here. It's already like very good. But as you know, OpenAI releases new models. The better AI gets, the better all of this gets. And so we've just created the pipeline for this to work and it can only get better. And so that to me is also a really interesting thing because it feels like we're already at such a point where this is so much easier to do than have to. For example, like you know, in the past, I've inherited files from or surfaces from other people that have since left the company. And I'm trying to figure out where is the Figma file for this thing. Some of those decisions got made in engineering. They didn't even get recorded in the Figma file. They got all added in to solve some edge cases. And I just want to recreate all that so I can work on top of it. And just being able to capture all of that in the highest fidelity possible is incredible. And I think now with some of the new releases that we've made with the use Figma tool, were able to do that in relation to your actual design system. And so when you copy right now the stuff that Ed copied, because it's just a snapshot of a website, it doesn't yet bring in your design tokens. With this new tool, you're now able to actually reference your design library and have that pull in those design tokens and local styles. So you're not just working on a facsimile of the thing, you're working on a representation of the thing that is using your style guides. And I think that just unlocks a whole new level of fidelity where you can start having these aligned sources of truth. I saw an engineer actually not that long ago on Twitter showing their process of aligning their storybook to their GitHub to figma with these AI kind of like running the kind of loop and finding the diffs between them. And so now you don't have this kind of overhead of maintenance of like, oh, but we haven't updated that component in here and it only exists in there. You can just run a loop and have anyone, depending on, irrespective of their preferred modality, whether it's their engineers or their designers or their PMs, be able to like have the latest materials available to them. And I think this is kind of why we're talking about it doesn't really matter whether you want to start in code, like what do you want to do? And the tools will be able to interoperate between them totally.
- [20:31]
C
And you know, while you're chatting, I made a very dummy change. I just changed the string there, changed it to our newest model and ran it. And here it is in the model picker here. So a dummy example. But yeah, this point of you can basically go deep. You can build out the component in code and then in parallel, your designers can go deep and then you can just, one click, kind of update the master from there.
- [20:58]
A
So practically when you guys are using this day to day. How much do you have to update either the FIGMA or the code? How often does it get things wrong? Where things stand just technologically today there
- [21:09]
B
are limits to the kinds of things that it's able to infer. Right. There's going to be a bunch of stuff that just doesn't translate to figma. Like, you know, maybe you have some shader effects and we're not set up to run that kind of stuff. Maybe you have specific transitions that you're trying to dial in and you know, a static canvas yet doesn't support for that. But the reality is you can get to a lot through even annotations. Well, a trick that we use a lot is actually being able to read annotations through into the mcp. And so we were able to communicate a lot of this stuff back. But it is that point of, you know, the designer's job and that labor of love of being able to go in and, and do an absolutely like leveraged amount of work just from a design industry into code and then be able to also do all these things you used to have to like manually spec out and stuff. Just be able to do with natural language to say, hey, by the way, I want this to kind of feel like that because you know, it's hard sometimes for a model to infer kind of a lot of intention there. And so it often to us doesn't get a lot of the things wrong. Once you've set it up with your design systems and everything, you tend to be okay. It's going to be on the more kind of web specific kind of effects and that's kind of like an opportunity there for us to kind of evolve some of the tooling to be able to support you there.
- [22:33]
C
Yeah, I think my mental model is kind of like working with a colleague as well. To your point earlier about you bring in your colleague on and you have to kind of bring them up to scratch. And if your maybe Figma files are a bit of a mess or things aren't named correctly, then it's a little bit harder for your colleague to get up to speed. That kind of stuff I think is basically the same for agents in terms of hot tips. I think things like making sure that you name your components well and really thinking through. There's a lot of great stuff from the FIGMA MCP about aligning your design system with the CSS tokens in your code base. And once you get those foundations which are good for working with humans or agents, then I think it Makes things much simpler. But with our Most recent model, 5.4 as well, I have had like a number of designers internally reach out to me and they're like this model is like way, just like way better at working with these tools. And obviously there are limitations, but I do think if people haven't tried five, four, give it a go with the FIGMA mcp because I think it's materially better than things that we've released before. And I see more and more folks internally now using these tools in a day to day way. Which means I think that the reliability has improved and the interoperability and the kind of new MCP features that like figma have released really starting to help.
- [24:00]
A
So you guys have been involved in shipping some pretty important AI features used by tons of people. I'm curious if we can get a behind the scenes of what it looked like when you or someone on your team was working on one of these features. What the back and forth looked like between code in the canvas.
- [24:17]
C
Well, it's funny, I think you know, on the Codex team we're building products for developers so the designers who work on the team are pretty developer forward already. So you know, many of us code, you know, I probably spend around, I don't know, 70, 80% of my time coding. So like, you know, the nature of the role has changed. So there is less of this kind of handoff process on my team specifically. But you know, we're also, we've been building these zero to one products and we've been moving extremely fast. So it's kind of all hands on deck and hopping in from speaking with folks across the team working on other products or like products that have been around for longer or maybe folks who are newer to working in code. What I've seen is a kind of like gradual onboarding and a gradual change. So we have some work in progress like slack channels and design reviews and I just see more and more people arriving with like a hybrid of like there'll be a link to a figma, but there'll also be like a URL link and people will just like hop in and we'll click through and we'll show interactions or you know, the other day I was speaking to one of our, you know, content designers who typically you know, works through all of the like UX copy and like text across our products, you know, and she was telling me that she's been shipping to Prod and she's been like the submitting PRs herself. So I think it really varies. But I see a lot of people more and more like prototyping early stage, using some hybrid of kind of AI tools in figma. And then a lot of people at that last mile of helping bring the polish up and just getting in and doing very small. Maybe it's a starting tweak, maybe it's changing a string. But yeah, I mean, even if you look at how design has changed on codecs over the past year, I would say it's kind of radically changed. And I think particularly with the app, right. We released it, I think, gosh, I don't know, maybe six to eight weeks ago, but we've been dogfooding it internally and I think something changed in December when we were dogfooding the app. The models hit a certain capability threshold and just felt like anyone could hop in and change. And the pace of PRs and development was really moving fast. And I think there was. I forget where I read it, but someone had an interesting quote recently, which is, I think the challenge now for design is choosing when to go slow. If you're building AI products and if developers have been accelerated, say like 10x, which I don't think is an overstatement, designers have maybe been accelerated like 1.5 or 2x. So design can become the bottleneck if you're kind of not coding yourself. So then the trade off is like, when do you just kind of meet the speed of engineers and make sure that you keeping up with the velocity of shipping that's kind of required in this crazy, committed market. When you choose to go slow and actually go through deep design process, deep in figma, deep in collaboration and creds to make sure that you get those fundamentals right so that you can have some velocity rather than speed and you kind of can set a direction where you're going.
- [27:24]
B
Yeah, it's such an interesting moment. Even if you look back to even maybe just mid last year, I would have given you a completely different answer. And the Overton window have shifted so quickly from my teams being kind of, you know, AI curious to like, banging down the door. They can't move fast enough without it. And it's just this really kind of interesting kind of challenge because I have teams now that are working directly in staging. Right. And they're designers and, you know, like, they have now given you superpowers that are able to do this. And to Ed's point, it's like, okay, well come back a bit. Like, when are you doing the exploration? You're able to do stuff and you're Almost just so empowered by this that you have to think about like, okay, this is cool that I can, but then what should I? And I think that's really interesting. And so for a lot of our work, even just like mid last year, we were still working from designs to prototypes. We do prototypes and make. We would then kind of work with engineers to kind of put that into production. Now, you know, we might like put something, a flag into production and then we'd kind of finesse some prototypes in make and just try to get like little details right. And then we will bring that back out to GitHub and then use Codex to kind of work into that. And so it's this kind of constant jumping around between the right tool for the right job. That being said, the thing that surprised me the most is how kind of prevalent across figma this became. When I started, it was very much the, you know, I'm in this area called the build tools area. And so it has a lot of like very technical leaning folk. Whereas other teams, you know, they work on kind of the editor problems and they work on trying to help you give you better tools, more deterministic tools. And so suddenly now I look around and I have people from monetization building these incredible prototypes that are just so incredibly technically accomplished in a way that just as a designer that in the past might never have given themselves permission to do so. And so what we're starting to see is a sprouting of interesting concepts because people now have not just a vocabulary to do it, but the ability to get something in front of people without having to task an engineering team to them, bring that to life. And so we see projects starting at all different stages. Lots of new zero to one projects, lots of revisiting old projects that used to be P2s where we joked about there's no more P2s now everything can just be shipped. That cutoff line is almost arbitrary because you can just have polished stuff that you want to do. A designer can now just go and work on that polished stuff. And that's become just really empowering for the team where they have this kind of sense of self determination that they're able to ship PRs and stuff. And I think as a designer, as a builder, as someone that, you know, values agency, there's never been a more exciting time to be a designer.
- [30:37]
A
I think both of those points are massively illuminating. On the OpenAI side, people might say, okay, well OpenAI, especially Codex, they would be operating at the frontier. So Ed spending 70, 80% of his time in code. Maybe people would expect that, although I still think it's fine.
- [30:53]
C
Mind blowing.
- [30:54]
A
And then Today's podcast is brought to you by Pendo. Welcome to the SaaS plus AI agent era where every product team, no matter the size, can build world class experiences. Meet Pendo AI agents, virtual teammates that read your product data, chat with users and take smart in app action so you don't have to. With agent Analytics, Pendo shows exactly how those agents drive adoption, complete tasks and even customers cut churn no extra engineering lift fully SoC2 and HIPAA ready. And because Pendo's behavioral insights sync straight back into your BI stack, you get AI ready data to fine tune models and prove ROI in one place. Smaller team, bigger ambitions. You no longer need an army to deliver software your customers love. Grab early access@pendo.comakash that's P E N D O.com/AAKASH Today's episode is brought to you by Nia1 in Tech, buying speed is survival. How fast you can get a product in front of customers decides if you will win. If it takes you nine months to buy one piece of tech, you're dead in the water. Right now financial services are under pressure to get AI live, but in a regulated industry the roadblocks are real. NIA1 changes that. The Air gapped Cloud Agnostic Sandbox lets you find, test, test and validate new AI tools much faster from months to weeks from stuck to shipped. If you're ready to accelerate AI adoption, check out nayaone@nayaone.com Akash that's n a y-a O-N-E.com A-K-A dash I hope you're enjoying today's episode. Are you interested in becoming an AI Product Manager? Making hundreds of thousands of dollars more joining OpenAI and Anthropic? Then you might want to do a course that I've taken myself. The AIPM Certificate ran by OpenAI product leader Mikdad Jaffer. If you use my code and my link, you get a special discount on this course. It is a course that I highly recommend. We have done a lot of collaborations together on things like AI product strategy, so check out our newsletter articles if you want to see the quality of the type of thinking you'll get. One of my frequent collaborators, Pavel Hearn is the Build Labs leader. So you're going to lie. Build an AI product with Pavel's feedback if you take this AIPM certificate so be sure to check that out. Be sure to use my code and My link in order to get a special discount. And now back into today's episode. You building upon that that even at Figma we're seeing the new wave of designer. They are putting things in staging, they might even be shipping polish on their own. That is what the new wave of design looks like. But the funny thing is I talk to designers every day, PMs every day, engineers every day. And a lot of them are maybe at a more traditional company and especially true in compliance or regulatory heavy industries. So I'm thinking specifically about our colleagues over in healthcare and financial services. You know, if you're working at like a UnitedHealth or a ginkgo Bioworks where there's huge design teams, you don't, you aren't working in this way yet. You may not even have access to these tools yet. But if you're listening, what is the step by step roadmap to get to this new way of working? If you're kind of still stuck in the 2024, 2025 way of working at your guys companies, how do you come into this new way of working?
- [34:10]
C
Yeah, I just say give it a go. I mean it's, it's kind of, you know, it's a kind of, maybe kind of simplistic statement. But like you know, I think to, to, to some of the examples that he was talking about folks all the time kind of DM me questions about it and then you know, I look at kind of what's their role and it's like you've got people in gtm, you got people in finance, you've got people from all backgrounds, technical, non technical hopping in and trying these things out. And it's kind of like once you start using them you kind of realize how you know, creative you can be. So you know, just to give you a few examples, like someone on our GTM team like just built this whole iOS app that was like on her phone that she showed me at a, you know, at a work event and you know, as. And she's like I don't know anything about either. And then you know, just this morning someone from our comms team, like she wanted to design a seating plan for events so she like designed a HTML file and you could like drag people around, you could like type in their name. And I think you know, having chatted to folks across the org, it's you know, it's like how did you, how did you learn to do this? And like oh, I just downloaded it and gave it a go. So you know, maybe you don't have access in the company for whatever reason. But, you know, in the evenings and weekends, you can still download these things yourself. You know, try it in the terminal if that's a little intimidating. Like, try, you know, try the app or, you know, if you've. If you've ever coded in, like, you know, an ide, maybe try the extension, but just get going. And if you're not sure what to do or, you know, it's a kind of similar problem that we have with ChatGPT all the time, which is it's this kind of, like, blank box, and you can do anything, and then the limitation becomes your imagination. So I would just say kind of like, remove that limitation, and if at any point you get stuck, you know, just ask. So, like, you know, I'm going to Japan next week on my honeymoon, and my wife and I are, like, building this little app, so we're like, mapping out our, like, you know, the cafes we want to go to and the restaurants. And my wife is, like, not technical, but she's hopping in and she's making stuff and, like, you know, sending prototypes over. So I think just, like, really kind of like removing these ideas that, like, it's not for me and just, like, giving it a go, I think is, like, the best place you can start that.
- [36:19]
B
It's also worth pointing out that, you know, you don't have to start with code. You don't have to start with, like, that has to be your thing, you know. You know, we all have access to, you know, chatgpt on our phones. You're able to ask it any question. I remember when I was trying to learn how to code the hard way before AI and doing all these bootcamp courses and trying out to, like, figure out how to keep up to pace with new frameworks in HTML and CSS and, like, what do I need to learn? And, like, where do I actually invest my precious time into building a skill and a muscle? And now I don't need to. Now I can just ask a question and be like, can you build this? And if it starts to do something, I can ask, how does that work? Help me figure this out. And so it's really up to me how deep I want to dive into. If I don't care about how it's built and I just want it to work, I can just keep asking it for new stuff. And so there's never been an easier way to get started because it's just like, if you can ask a question, you can do the thing. And I think that to me is really interesting. And the question doesn't always have to be about code. Maybe you're asking about strategy, maybe you're asking about how your team dynamics can be improved, maybe you're asking about your org chart. You can ask anything and that will build confidence to ask more complex questions. And before long you're asking questions about code. You're asking questions about, hey, I've just inherited this system. Can you help me explain the data architecture of this? Just so I understand where we're making calls to are there any systems here that are redundant? Please look through all my code base. You can ask a bunch of stuff that before you'd have had to ask someone incredibly proficient in this to do, but you can gain at least a surface level understanding of the problem. And it's just through the exposure of that. As Ed was saying, you're going to build facility with this. What happens at places like figment, I imagine OpenAI is that you're constantly doing this as part of the thing and so you build that facility very quickly. And I think there's going to be moments where we're not asking designers and healthcare companies go and start shipping updates to main. But at the same time, I think you can start interrogating the systems around you and you can start finding where opportunities for me to contribute or to think differently about something, whether that's in code or not. I think what's really interesting is that we've tried to do a figma for a long time is try to make design bigger than design and say it's not just about designers, it's the people that we interact with as PMs, as researchers, as writers, and how do we build tools for that. And I think the same is true with AI. And the way these two things are connected is all these people can ask interesting questions that can make interesting artifacts, whether it's figma, whether it's in Codex, whether it's through Figma into Codex and codex into figma. What's important is you feel comfortable just asking a question. And I think that's a really interesting place to start.
- [39:05]
C
Oh, I was going to say, yeah, I think that's a really great point. And one other maybe kind of thing I would kind of cherry I'd put on that cake is there's also, I think a great way of thinking about these tools as well, is thinking of them as a tutor or a kind of partner. And even if you don't know how to code and you start coding, you shouldn't kind of Like, I don't think the mental model should be. I kind of like release control and I don't need to know how to code and I can just build this thing. I think it's like an amazing on ramp, right? Like, if you're a designer working in a company, you still work across the software development lifecycle and there are still a lot of really important parts of software engineering hygiene that you're going to have to go through. You're going to have to go through PR review, you're going to have to understand the code base. You don't want to introduce foot guns in the code, you want to respect the data model. And all of that actually requires knowing how to code. So it's a very empowering new technology to give people an on ramp. But once you start going down this route, you can also just start asking questions. You're like, okay, I've built this React app. Like, what is React? Like, what do these different pages do? What is the difference between a layout page and a normal page? Okay, how does CSS interact? And it's this way of kind of basically kind of getting over this hunt, initial hunt, which I think can be a bit scary for folks like, you think, I've been to the same boot camps probably that guy has, and it was a lot of time and investment to go to these things and frankly, quite scary for a lot of people if your kind of background isn't in engineering, but now you can kind of have this on ramp and you can slowly ramp up. Because I do think it's really important to understand the underlying systems that you're designing within. And none of this basically obfuscates the need to do that, but it's a really great tool to basically bring more folks into the fold.
- [40:54]
B
I really do think that curiosity is going to be the defining skill of people that succeed in this kind of new era. Because A is changing so fast and you just need to have enough of it to ask, okay, what does that mean for what I'm doing? And if you're already asking that, you're already in a good place. And then to Ed's point, what does that mean? This thing that I've just done, how can I find out a little bit more? And if you have that curiosity, you're adaptable and you're open to new information, you're open to trying out new things. And I think that's going to be the thing. Things are changing so drastically that if you think it's a small shift that you can adapt slightly you might miss the actual bigger picture. So to be asking these questions, to be trying these tools to be, it's hard to keep up. And there's a lot of. Sometimes I feel the anxiety of like, oh my God, there's too many things launching at the same time and I still have to do my daytime job. But there is this kind of mindset, let's ask questions and let's see. And now I have this incredibly patient tutor, like I said, that never gets tired, never clocks out and I can just ping. But I don't get it. But I don't get it. Just explain it to me in simpler terms and I can get it to work with me at whatever level that I need it to work in terms of abstraction. And so I think if you can just develop that curiosity instinct, it's probably to your question, like, how do I get started? Just that just like, see yourself as a curious person and start asking questions is what I would say.
- [42:24]
A
I saw this funny meme on Twitter that I'd rather hire a new grad that has been using these tools to their full extent than somebody with a ton of experience who hasn't tried them just because their company hasn't procured them them. And I hope that you guys all get that message, which is like, even if you don't personally have your company paying for Figma, MCP and Codex, yet, if somehow they're not doing that and allowing you to do that yet, it's not a reason to not do it on your own. Ed gave the story of how him and his wife are building an app to go on their honeymoon. You can use personal use cases to explore some of these tools. And when your company finally gets on the bleeding edge, then you will be the first person to be able to take advantage of those tools. And one of the things that's talking to you guys is such a privilege is you guys are basically operating at the frontier. A lot of other companies are going to be operating at the way you guys are operating in a year, in two years. And we've been talking about how designers might be in a staging environment. Designers might even be shipping polish to production, or Ed might even be shipping whole things to production that he creates on his own. Where is the line now? These designer and engineer roles are clearly merging. And then there's always been this third leg of the trio, which is a lot of the people watching this podcast, which is PM's. I would love to know. Not your guys prediction of where these roles go, but actually just your description of what it looks like inside OpenAI and Figma today. How are those roles working together? Where are the lines drawn?
- [43:53]
B
I mean the, the, the boundaries between these roles have been blurring for, for a minute, right? And I think AI has really accelerated that. And so for us, the way that we're thinking about this is that there are people with spikes, right? But there is no like kind of territories. There's things that people gravitate naturally to do and that's now broadened. And so I have designers shipping code, have PM's shipping stuff and prototyping stuff and working into designs. And so one of the things that we found really interesting is with this advent of things like skills and that you're able to kind of guide models to do something, you have this almost like pedagogic nature of writing, kind of like how do I think about this thing? And we have this kind of collective wealth of information that we're like, some of it we're using to train, to add to our tools that we've released, but some of it we're using internally. And so what you end up having is designers writing skills on how cool, how to coach AI to design. Well, you have PMs working through skills on how to make interesting product decisions and all this kind of stuff, which means that it accelerates that blurring even more, right? Because now as a designer I can make use of a PM's mindset to work through some decision making, whereas a PM is trying to figure out how to debug something and it creates this really interesting thing where I have a natural spike in design, not so much in engineering, but I now have the, I'm standing on the shoulders of giants of a bunch of engineers that have helped me kind of have guide, you know, codecs into a certain way of deploying or something. And so for us, we're now just becoming more, you know, in football, soccer in Holland in the 70s, there was total football, where every position played every position, you didn't have a specific thing. And now we're in this thing when someone moves over here, you can cover over here and you have this thing or you don't know how to market, you're a much kind of bigger threat as a team. And so for us we're starting to move into that where teams have a natural interest and spike in things, but they're able to inter navigate and help each other in problems where sometimes someone goes out for a day or they're sick or whatever, and that's now no longer a bottleneck. You can start making progress here and there. It doesn't happen on every team yet, but we're starting to see the signs of this becoming a thing. Where the empowerment that has come from AI has meant that this idea of roles and rigid Org structures is kind of slightly starting to diffuse a little bit.
- [46:29]
C
Yeah, I would agree with a lot of that. I think that. So first, different roles can kind of blend a little more easily in terms of just the day to day work that you're doing. But I think one counter perhaps I would provide is I think the role of a designer doesn't go away. The role of a product manager doesn't go away. The role of an engineer doesn't go away because you actually play very different roles, right? Like if you're a product designer, you're arguably the voice of the user. You're trying to build products that people love and use, same as product managers. If you're an engineer, you're perhaps more focused on systems and, and performance and designers care about these things as well. But even though the different tools that you use are more accessible or even if now an engineer can hand something off to Figma more easily, I don't think that kind of impacts actually much of the day to day work. That kind of happens in terms of the different value the different roles prefer. And I would actually kind of look more to the past and the future on this point. So one way of thinking about it is we look to the future and these roles converge. Another is kind of you look to the past and actually all of these roles have very different roles within an organization and you bring each other together and maybe your toolbox is the same. But the role of product managers and product is building great products. And the mandate of an engineer isn't necessarily that. So it is like great engineers are great, great, great product folks as well. But you know, I think bringing, bringing these different skills to bear at a more kind of like conceptual level. I think like is even more important than the kind of low level implementation side of things.
- [48:14]
A
So what I'm hearing from both of you is that we have always seen the roles converging, but you do see both of these three roles staying separate kind of conceptually or in spirit, representing sort of different elements where the engineers represent more of the quality system and engineering, the design represents the voice of the user and a great user experience. And the product manager, it sounds like, is bringing in that business angle to make sure that these are all driving the business goals. Is that roughly the mental framework I should have or how should I be thinking about? Well, even if you can do some of the elements of somebody else's job, this is what a person stands for.
- [48:52]
B
Yeah, I'd say, yes, I'd say to the point about spiking is that you have things that you naturally gravitate towards doing and that kind of has in a way informed the trajectory that you took your career on. But there was moments there perhaps where you were arbitrarily siloed into that perspective because of the amount of time it took to become proficient in a tool. So if I wanted to learn a specific tool, that would kind of gate me in a specific thing, unless I had so much time and the facility to also learn, let's say, code and design and then somehow spend a lot of time thinking about like the intricacies of, you know, SQL for like querying, you know, data sets, et cetera. And so you kind of ended up funneling down one thing. And now that the tools are becoming easier and these abstraction layers are being built on it so that you can step into slightly other domains you're able to do that doesn't mean I'm going to start becoming a designer and becoming a PM or become an engineer, but it means that I no longer am working with only like a third of the picture. And so what it means is I can start working into product decisions and into shaping strategy roadmaps and having a higher seat at the table, but also working much more in the implementation thing if I want to. But my role as a designer and how I would self identify is still, as Ed said, I want to figure out as the voice of the consumer, what is the kind of the ergonomics of a thing, what are the ways that I want someone to work through this problem, problem. And then, you know, I will put in enough of my energy into, you know, bringing some of that to life and also creating a narrative and a business narrative around it. But I have teams to help me do that. But for sometimes I'm working on my own zero to one projects, let's say, and I'm now able to step into that and write a much more coherent executive briefing, let's say, without having to have gone through the, the pm, the, you know, indoctrination of like, how do I like, like think about these mental frameworks, mental models and all that kind of stuff. A lot of that can just be surfaced up for me to take advantage of. And I think that's kind of what I mean by people being able to kind of lean a little bit further into another one of the kind of the pillars to ship products. And so, yes, I don't think people are necessarily jumping ship from one end to the other because they like what they like and they're good at what they're good, but they're now able to be better at more things.
- [51:19]
C
Yeah, I think similar. You know, I can only really speak for myself, but like, even though I'm spending most of my time coding, I would still self identify as a designer. And I don't think that has changed. It's just, you know, you're still solving the same problems. You're still trying to, you know, uphold a, you know, high bar of craft. And that just means that you, you know, work in this different medium and you can kind of collaborate more easily with folks. And same with PMs that I work with. It's like, you know, a lot of PMs still do write PRDs, but there's this great phrase that I've heard a little bit, which is prototypes, not PRDs. And many of the PMs on our team, I think, are good examples of this. And they'll bring a working prototype that they're thinking about or they'll ship a PR for a feature that they were thinking through to stress test it with some engineers before maybe someone else takes it on and takes it further. So I think it's about, like, how can code help you in your role better achieve the types of objectives that you're trying to do? And for product folks, that's a little bit different often actually than engineers. But the medium that you use kind of might change.
- [52:30]
A
I could probably ask you guys another hour of questions just on this topic, but we're going to leave it there. This has been a fascinating insight into how I think two of the most important companies shaping the future of product development, how they work in the inside. Gigi, Ed, thank you so much.
- [52:47]
B
Thank you. Thank you for having me.
- [52:49]
A
All right, everyone, see you later. I hope you enjoyed that episode. If you could take a moment to double check that you have followed on Apple and Spotify podcasts, subscribed on YouTube, left a rating or review on Apple or Spotify, and commented on YouTube. All these things will help the algorithm distribute the show to more and more people. As we distribute the show to more people, we can grow the show, improve the quality of the content and the production to get you better insights to stay ahead in your career. Finally, do check out my bundle@bundle.akashg.com to get access to nine AI products for an entire year for free. This includes Dovetail, Mobin, Linear Reforge, Build, Descript, and many other amazing tools that will help you as an AI product manager or builder, succeed. I'll see you in the next episode.