An inside look at how Figma builds product | Yuhki Yamashita (CPO of Figma)

There's something controversial about this idea that everyone can see what you're doing, or that multiple designers can be in the file at the same time. We like to say that one of the first responses we saw on Stigma was, if this is the future of design, I'm quitting. I'm changing careers. And there's that kind of tension of that narrative tension, but that is signal that you're kind of part of this revolution. when you're trying to change something and when you can equip your customers or user base with that, then I think that's something that they can really get behind and champion. So it's not just that they're championing for a tool, they're also championing for a new way of working. Obviously that's a tall order. So I wanted to come up with that. But hopefully, if you're a founder and you're working on something, your vision is so big that you have those kinds of ideas and it's like, how do you actually equip your customers to want to talk about that.

Welcome to Lenny's podcast. I'm Lenny, and my goal here is to help you get better at the craft of building and growing products. I interview world-class product leaders and growth experts to learn from their hard-won experiences building and scaling today's most successful companies. Today, my guest is Yuki Yamashita. Yuki is Chief Product Officer at Figma. where he's been for almost four years. Prior to Figma, he was at Uber, both as a product leader and also interestingly as head of design for one of their bigger product teams. Before Uber, Yuki spent time at Google and Microsoft, even taught an introductory computer science course at Harvard. In our conversation, we explore Figma's product development philosophy, how they build such consistently great products, how they hire, what habit Yuki has found to be the most instrumental in in his success in his career, and also what Yuki and his product team have learned by building a product-led growth business. This episode builds on a newsletter post where I interview Yuki about how Figma builds product. So if you enjoyed this episode, or even while you're listening to it, I highly recommend you check it out. It's currently my fourth most popular newsletter post of all time. You can find it at lennynewsletter.com With that, I bring you Yuki Yamashita after.

A short word from our wonderful sponsors. this.

Episode is brought to you by Notion. If you haven't heard of Notion, where have you been? I use Notion to coordinate this very podcast, including my content calendar, my sponsors, and prepping guests for launch of each episode. Notion is an all-in-one team collaboration tool that combines note taking, document sharing, wikis, project management, and much more into one space that's simple, powerful, and beautifully designed. and not only does it allow you to be more efficient in your work life, but you can easily transition to using it in your personal life, which is another feature that truly sets Notion apart. The other day, I started a home project and immediately opened up Notion to help me organize it all. Learn more and get started for free at notion.com/lennyspod. Take the first step towards an organized, happy team today. Again, at notion.com/lennyspod. /lennyspod. This episode is brought to you by Vanta, helping you streamline your security compliance to accelerate growth. If your business stores any data in the cloud, then you've likely been asked or you're gonna be asked about your SOC 2 compliance. SOC 2 is a way to prove your company's taking proper security measures to protect customer data and builds trust with customers and partners, especially those with serious security requirements. Also, if you want to sell to the enterprise, proving security is essential. SOC 2 can either open the door for bigger and better deals or it can put your business on hold. If you don't have a SOC 2, there's a good chance you won't even get a seat at the table. But getting a SOC 2 report can be a huge burden, especially for startups. It's time consuming, tedious, and expensive. Enter Vanta. Over 3,000 fast-growing companies use Vanta to automate up to 90% of the work involved with SOC 2. Vanta can get you ready for security audits in weeks instead of months, less than a third of the time that it usually takes. For a limited time, Lenny's podcast listeners get $1,000 off Vanta. Just go to vanta.com/lenny. That's V-A-N-T-A.com/lenny to learn more and to claim your discount. Get started today. Yuuki, welcome to the podcast.

Thank you for having me, Lenny.

I am quite honored to have you on this podcast. For folks who don't know, we actually collaborated already on a newsletter post that has quickly become my fourth most popular post of all time, which you can find if you search for how Figma builds product. And so I am really excited to dig into a lot of the stuff that we maybe didn't cover in that newsletter. Also just like how product works at Figma in more depth, how the PM team works, how you think about product, and things like that. So again, thank you for joining me.

Hey, Tim is a huge fan of this podcast. So I'm really honored to be here.

Wow, that means a lot. I really appreciate that. So you are currently Chief Product Officer at Figma, which is such an epic role. It's such an epic company. Could you take just maybe a minute or two to high level share your career arc, how you got to where you are today as CPO at Figma?

My first job out of college is actually at Microsoft and I was the product manager on Hotmail, if anyone, any listener remembers Hotmail. And, you know, I didn't really know what product management was at the time, and I kind of viewed it as a kind of interdisciplinary function that will give me exposure to all the other functions so that I can actually decide which function is interesting to me. And so I spent a couple of years at Microsoft, through that also moved on from Hotmail to Windows. and at the time they were working on Windows 8. And Windows 8 was really interesting because it was like a very, like, touch forward version of, of Windows. And so there's just a lot of conversation about UI and ux, and that was really fun for me. And, you know, as I was thinking about what's next, I really dropped the draw of Silicon Valley, and I ended up at YouTube, and I believe Sisir has been on this podcast before. You Yes, so Shashir was leading YouTube at the time and he continues to be a great mentor of mine. But, you know, had the opportunity to lead the YouTube app on iOS over there. And it was really funny because I had never touched the iPhone before my first day, so my manager on my first day just sent me to the Apple store to buy an iPhone. But, you know, that was kind of like my next job. And that was kind of like a really interesting change for me too of like, and we can talk about this later as well as different companies and different styles of product management. really kind of figuring out, you know, I think it was a place that taught me a lot about some of my product philosophy today. And this is also around a time where there are a lot of interesting companies that were working in the physical and digital space. And so, you know, Airbnb was one of them. Uber was another. So I kind of felt this draw just because, you know, it seemed just like a really interesting space to be in. So eventually kind of ended up at Uber, like Uber was another kind of company where I feel like a lot of my philosophy that hopefully we can get into today around how to build products, how to build products in the kind of environment that's really fast moving. And so that, you know, I learned a lot from there. And, you know, to date, like, all those companies has really been, like, focusing on the core experiences on consumer products, and that's really been most of my career. And as part of that, worked with a lot of amazing designers. But at Uber, I kind of realized that I wanted to dip my toes into design directly. So the tail end, I actually switched from PM to design and managed a few design teams working on our bikes and scooters efforts just to understand what that's like. And it was around this time, around my Uber career, where we encountered this so-called Figma. You know, I happened to be working on a project that experimentally brought Figma into the company. It was a time in the company where we were trying to transform our culture to be much more transparent and inclusive and Figma was the perfect fit for that. So, yeah, I got to watch how Figma changed the way it worked, how it spread within the company. We got to know the Figma team a little bit as well. And yeah, it's really drawn to that mission. And as a product manager who's been straddling that boundary between design and product for all my career, I really loved how Figma proactively blurred that boundary and opened up that process of participating in design. So I really got behind that mission and that's how I ended up here at Figma.

It's so fascinating that you moved into design from product and then back into product at Uber. What was the role you were ahead of design for the mobility team?

Yeah, it's called New Mobility, focused on just, or micro mobility efforts basically.

Yeah. Do you recommend this path for PMs to like switch into design? I know it's not like something anyone can do, but do you feel like that is an important skill role to experience as a PM? You encourage people to try that.

Well, you know, I just said it's not for everyone, but I think that it's first of all, a really great empathy building exercise of, you know, understanding that point of view and also kind of pushing yourself to post on the product from a different angle. Because I think as a PM, you're kind of in the center facilitating all these different trade-offs. And when you go into design, you kind of have to ignore some of those other aspects to really be insistent on pushing on the best experience possible. Like just kind of suspend everyone's, you know, disbelief in business feasibility or engineering feasibility to push on a vision. And that's just kind of like an interesting exercise to do. and then I think the last thing is like, I actually think it's an opportunity for design and PM to learn from each other, right? Like when I became a manager of design teams, one of the things I coach designers on are like how to win over PMs, you know, and like how to speak in PMs language. And, you know, likewise, it's important for a design to understand that as well. So those are some of the things that I thought were helpful. But again, you know, it has to come from a place of passion that, you know, you really want which job.

Would you say is harder, design or product management?

They're hard for different reasons. I would say managing designers is harder than managing product managers.

Interesting.

And I think part of it is that designers are, it's really important to focus on growing their craft, right? And helping them develop as designers. So, you know, it might not be that the company's biggest problem is one where you can actually learn this new kind of thing you're trying to learn. as a designer. And this probably happened for engineers too, right? Like you could be working on the onboarding funnel and that might not be the best place to be learning, you know, micro interactions. Or maybe it is, but like, you know, those aren't always aligned. Whereas with PMs, it's a little bit more like PMs are just hungry for impact and so you can point them to the biggest problems a company has. And while PMs also do want to understand different kinds of problems or have the experience working on different kinds of problems, at the end of the day, I feel they want to be working on the thing that matters most in the company. So from that perspective, it's easy. But as you know, and the reason this podcast exists is because PM isn't easy. And so the discipline, I think, is harder in a sense that it's sometimes hard on a day-to-day basis to know if you're doing the best thing you could possibly be doing. And so I think that makes it a little bit harder. as a PM as well.

I had a designer friend who moved into a PM role. I had a product role at a startup and she's like, Holy shit, I had no idea how hard being a product manager was and a product leader. I have so much more empathy for the PM role. And so it's interesting it works in both ways. Similarly, I was actually a manager of engineers at one point and I felt the same way where managing PMs was a lot easier than managing engineers. So it kind of translates to a lot of different roles.

I can see that.

Folks listening to your career arc and just all the places you've been, all the wonderful things you've done. Imagine many people are like, wow, how do I have a career like that? Microsoft, Google, Figma, Uber. If you had to think back and identify maybe one habit or one skill or behavior that you think is most contributed to your success as a leader, as a product leader, what do you think that would be?

People who work with me know that I often talk about storytelling. And in fact, if you've ever reported to me, storytelling has showed up in some kind of performance review, I feel, and that's how much I care about it. And I actually think that a lot of being a great product manager is being a great storyteller. And I know a lot of us have already talked about it out there. I think the importance of storytelling is understood, but maybe I which there are two things that are specific about it that I think are interesting. One is just understanding the power of synthesis. And it's this idea that maybe even as kind of like a early career PM, you're inside some of these reviews and a lot of people say, hey, at least you could take some notes for the meeting, right? So that you're adding value. And so that's common advice that here, but I think the most powerful part of that is that in some ways you can synthesize what happened, right? And a lot of things are said in a review and there's still this kind of like bring it all together into a good distillation of a message. And even that's like, that's a lot of power, I think, you know, what do you take away from all these different opinions that all these leaders had? And like, how do you push that, you know, push the project forward from there? So that's kind of one example. Or another example is I really love thinking through frameworks and offering ways of talking about a problem or ways of thinking about a problem. And that's kind of synthesis to figuring all these different disparate parts and kind of, you know, coming up with a way to a lens to look at something. And I feel like it's something that was, I learned mostly through kind of literature classes almost, you know, where you're doing kind of literary commentary and you're reading like William Yeats poem and you're trying to kind of like, you observe all these interesting things. But then you have to take those different observations and distill it into a thesis, into something cohesive. And I think that's what a good PM can do. All these different ideas and opinions and problems and how do you distill it down? And so I think that's one aspect of storytelling that's really important. And the other aspect of storytelling, of course, is a story is only as good as the accident that's capable of driving. and a lot of times that I often coach my product managers are, we're living in a world where everyone is constantly distracted, right? And you kind of get like these 30 seconds of attention at a time. And so just the ability to kind of like really tell something powerful that sticks is really important, kind of like the memorability of it. And I often talk about mementification, which is this idea that like, I found this out most at Uber, I feel, where There are certain insights, data insights, research insights that were memified to the point where someone like Travis or Dara would just cite this insight in the middle of a meeting. And you know that you've really done your job as maybe a researcher or a data scientist or product manager if people are able to do that and draw from that in that way. And that's what ultimately sticks. And so when you start thinking about it from that perspective, it's really powerful because it's the way in which knowledge is transferred within a company and you compel action for it. Or when I'm kind of like being maybe asked questions by other readers or stakeholders, the thing that's going through my head is like, okay, there's this kind of story that that leader is trying to develop or like a meme about what this project is about or what the biggest problem is. And so what kind of story are they trying to kind of like create in their heads so that they can kind of like remember or talk about what's happened. And as you kind of take that mice that you just realize that it's a really useful way to think about everything.

I'm really excited to chat about this idea because it comes up a lot. The power of storytelling, it's similar to like being good at vision. It's like PMs are always told like, Hey, you gotta improve in vision. Here's like a skill that's the great PMs are really strong at. And I feel like storytelling is similar. It's like a, this vague cloud of a skill that you build over time. And you mentioned a few things that you recommend to people that you work with. Like, think of it as a me maybe. Is there anything else, like when you're doing a performance review with a PM and they're, they're like one of their skill gaps is storytelling. Is there anything else you recommend they specifically do to get better at the skill? Or is it just do it again and again and watch me do it, watch other people do it and you'll learn?

Yeah, I think of it as kind of like resetting the internal computer of my brain a little bit so that I start from scratch again. And when I'm starting from no context at all, can I build up the story from there and explain what's happening? And oftentimes you're just caught in the middle of everything and you have all this context that might not be obvious if you step away from it for just a second. I guess the way to think about it is put yourself in another user's shoes. and that user is someone who has no idea what's happening and still wants to understand in a nuanced enough way what you're grappling with. And so that kind of greets that moment and to pull yourself out helps you tell a better story in many cases. So that's one thing that comes to mind.

Got it. So it's kind of escaped the curse of knowledge a little bit and just assume people don't know anything about the context, the background, why this is important. Come back to the beginning.

Yeah, I think that another thing that I, where I learned storytelling is through teaching. So when I was kind of like a course assistant for a computer science class and I had to explain pointers, you're like, okay, like I really have to borrow on real world metaphors or something that is like much more grounding because if you assume a lot of knowledge, then like it can be inaccessible to a lot of people. And so if you can tell a story that any student can understand, then you've really done your job. And once you've learned that skill of being able to tell anyone who has no context, then it becomes much easier to kind of turn to these other audiences that are kind of closer and closer.

When I asked you in our newsletter interview what one of the core philosophies of product managers is and the way you think about product and the role of PM at Figma, an interesting thing that you highlighted is that to you it's really important that PMs own the why. of a product and an idea. And I think it connects to what you're talking about now. I'm curious just why you think that's so important for product managers and why that's so core to the way you think about product and Figma.

I really can't remember where I heard this, but it really stuck with me because oftentimes there's this debate about, well, is the PM person who comes up with the idea? And the answer is usually, no, it doesn't have to be at all. And in many cases, in our case, like your customers come up with a ton of different ideas, right? and certainly the what and the how are things that are shared within the company and not something that PM uniquely drives. But I do think the why is something that I really always hold the PM uniquely responsible for. And I think the place where I learned this, the importance of this the most was actually first at YouTube. I had been working at Microsoft for a long time and I was earlier in my career, so I was just really focused on my, what we called our feature crew, like our engineer, designer, our tester, and just writing specs that really specified exactly how everything works. And so that was kind of the Microsoft culture back then, and your specs had to be perfect. Then moved over to YouTube, and all of a sudden, you're responsible for an entire app, and you have a pretty big team, and you cannot specify everything that happens. And so naturally, designers and engineers are just making their own choices, right? Like maybe it's an error handling situation and, you know, in Microsoft culture, you would have had a table that specifies exactly what happens during that error, right? But in Google culture, it's kind of like, okay, well, the engineers and designers, they can kind of figure it out. So then it's like, how do they make a really great decision? How do they, you know, the all these local decisions that you're not a part of, how do you make sure that the great decisions made. And if everyone has an understanding of why we're doing this, what problem we're solving, then people can make really great decisions. It's the only way you can really scale. So that's kind of where it came from. And then since then, I've started to realize also that there are other functions that do this well. So for example, the engineering team at Figma, whenever we do a retro or post-mortem, we do this thing called Five Whys, right? And it's kind of the idea behind it was like, well, why did this happen? How did it happen? Okay, and why did that thing happen? And go deep enough where you can kind of find the root cause and go fix all those things. And I think a PM can do this too, which is, you know, a customer is asking for a feature, but then you say, okay, why are they asking for it? And kind of back up the problem. But I think there's one more step you can take, which is like, why do they have that problem in the first place? And maybe there's something there and that could be an opportunity to, you know, make a bigger product impact by fixing kind of like that underlying condition that created the problem in the first place. That's so cool that you actually do the five whys.

I hear people talking about the five whys all the time, and I don't know, I haven't heard people actually using it. So you actually do this at your postmortems, you said?

Yes, I'm an engineer in team. That's interesting.

Can you talk a bit more about these postmortems? Is this just like when something goes wrong or is this just every project you do retrospective postmortem sort of thing?

As it relates to FiveWise, it's more when something went wrong. But I do think we have a retro culture as well, where there's always opportunity to make things better. And if you don't create the environments to talk about it, then some of those will go unaddressed forever.

Cool. Okay. Another attribute of the product team and how you build product at Figma that was really interesting is you mentioned that you just have an obsession with proximity to customers, that you make sure your PMs and product team are really close to customers. When you hear that, you're just like, I imagine everyone listening is like, oh yeah, we're really close to customers. We talk to customers all the time. Of course, you got to talk to customers. I'm curious what it is that maybe you think sets you apart in terms of how you think about being close to customers and if there's a story maybe of just like, wow, this is how close we are to customers and maybe something that emerged out of that.

That'D be really cool to hear. Well, I think a lot of it starts with our origin story in many ways, which is that Way back when, when Dylan, a small group of people were building Figma, this was a time when no one believed that it was possible to have a design editor in the browser. And so it just seemed like science fiction almost. And yet, what Dylan did consistently throughout was just put the product in front of designers, ask them for feedback, come back to them the next time with that feedback implemented, and it becomes better and better and better. And at no moment was there kind of this expectation that the designer suddenly turns around and implements that tool in their organization. It was really just about listening really carefully to what the community had to say and through that process making them evangelists. And that's kind of where a lot of how Figma came to be and why we have such a strong connection with our community, where We've actually, you know, they've really helped shape, you know, the product to date, and there's a deep belief in that. And they're the ones that are now advocating for Figma and helping us spread within the community, within their company. So, you know, that's kind of the backdrop for why we have such a strong connection with our customers. And, you know, there's a lot of things that you see. So, for example, there's someone on my team, Sho, and oftentimes Sho will tweet out to the community, like, here's what we're thinking, or, you know, we're actually thinking about focusing a lot more in prototyping. What are the top problems you're seeing? And, you know, people come back with all these different answers because everyone's passionate and we kind of go in there and just look at all the feedback and understand what people are saying and just have a stronger pulse on how people are feeling. And that's not to say that everything is then implemented verbatim, but, you know, we really find it useful to feel like we have a sense of what people are thinking. And I think the most crazy version of it maybe is, you know, Dylan's always reading customer feedback. In fact, he reads the most customer feedback of all of us and has been doing that for a decade, right? And oftentimes, you know, there used to be this thing where he would drop in tweets that he sees into different Slack channels to be like, Hey, this seems concerning, or we're getting this feedback. And it kind of got to a point where we got big enough where people would feel like they had to drop everything and deal with that tweet. So Chris, our CTO, and I kind of like intervened. We created this new channel, private channel called Concerning Tweets. And it just for this small group of us that Dylan can kind of like drop those in. And these are tweets that aren't going viral by any means. They're just things that he sees with one likes, sometimes zero likes, but he feels there's an essence of truth to them. And we make sure that, you know, we look at what's going on there and see if there isn't something, you know, much bigger that we should be focusing on. But that's kind of like the extent to which, you know, someone like Dylan from the, you know, from top down implements this idea that, like, we need to be staying close to what our users are saying.

That's an awesome idea for a channel, a way to kind of contain that potential madness that it creates. Is there anything else you've learned around hearing feedback like that in a tweet, let's say, or just a few loud voices and deciding what to actually work on? Do you have kind of an approach there just deciding what's worth paying attention to?

As we've built out our research and data functions, it's really important to kind of balance out the vocal minority with what's actually happening, right? So I really view some of those tweets more as kind of like canaries in the coal mine in a way. and inputs into many inputs we have around, you know, everything our customers could possibly be experiencing. And, you know, it's important to realize that, you know, we have certain forums like our support tickets where customers are tend to be much more dissatisfied. And we have other kinds of inputs that are kind of sales conversations with prospects, you know, where it's really more about perceptions around fake bar in some cases. and I think it's just important, especially as a product manager, to feel like you have this balanced portfolio of different kinds of feedback to know that you don't have any blind spots. So I think that's one of the things that, like, I, I focused a lot on when I came in, which is like, you know, the Figma team is very good at Twitter and, you know, staying on top of the sentiments. And luckily for us, a lot of designers are on Twitter. Right. But the reality is that most of our audience at this point probably aren't. And so, you know, building our capabilities to extract feedback or More insights from those other sources as well.

That reminds me, I think Twitter was really instrumental to the beginnings of Figma. I believe Dylan made this kind of social graph of the most influential designers on Twitter, and that was kind of his go-to market strategy, get those designers on Figma. And then I think he open sourced his code to do that. Is that right?

Yeah, yeah, that sounds right to me. And he's very intentional about which designers we need to win over. I think it was very novel at the time.

What is it like to work with Dylan Field? He's, you know, as an outsider, he's a legend. Feels like he's an incredibly smart, talented, hardworking CEO. There's always tension a little bit between a chief product officer and a CEO. And so I'm just curious, what's he like to work with as a product leader? And then is there like, I don't.

Know, memory that comes to mind of just like a way that encapsulates what it's like to work with Dylan? We're very different, actually. And, you know, Dylan, it's very, is very based on intuition and instinct. And that intuition is actually built off of, you know, thousands and hundreds of thousands of customer interactions where he might look at something and be like, you know what? This isn't gonna land well or, you know, here's the biggest problem right now. And you're kind of like, well, how does it conclude that? And, you know, part of my job is kind of like build out that logic tree for him of like, how did you arrive at that conclusion? so that people can kind of understand that at scale in a way. But it's very much about that. Or, you know, I think there's a way which sometimes as a product manager, you kind of want to lay out a problem and say, okay, we're going to first focus on this problem, and then there are these three approaches. We're going to take this approach and have a review at every step along the way. But for Dylan, I think it's very hard for him to really kind of like, fully get bought in until he kind of sees the end implementation to literally feel like if this is a good solution or not. And so I think that's kind of like the kind of thinker he is where he really needs to see it to kind of feel it. But it's not totally random. It's based on all these interactions with customers and somehow encoded in him to kind of like build up some of those kind of intuition. and I think one of the things that's really interesting about him is that he actually really cares very deeply about any given user and how they're feeling about Figma. And I remember when during the height of the pandemic, we were doing a 101 walking around Dolores Park, because this is the era where you would take meetings, if you take meetings, they're all outside, right? And then he needed to use the bathroom, so he came over to my house. in the Castro. He used the bathroom and I came in my partner and my partner was on Figma and Figma pulled up because he is doing work. And then Dylan just went straight in there and wanted to ask what the biggest problems were or like what's not working. And they started kind of like geeking out on some issue around Google Fonts. And this is like the first major interaction between the two of them. But it's kind of one of those things where like, that's how much Dylan cares. And on one level, it's just, you know, it's easy to say, hey, this is like a single user who just happens to be using your product and be dismissive of it or not care that deeply because you think you already know, like all the biggest problems, but that's not as they did. And so that's kind of the level of kind of, I guess, customer obsession, if you will, at the exhibits and, and then in turn informs his intuition.

That's amazing. Figma is like 10 years old at this point, right? Like he's been at this for a long time, like a decade. And the fact that he's still so obsessed with just like a random person just using Figma and he's taken the opportunity to like experience it in real time every chance he gets, sounds like.

Yeah.

Hey, Ashley, head of marketing at Flatfile. How many B2B SaaS companies would you estimate need to import CSV files from their customers?

At least 40%.

And how many of them screw that up and what happens when they do?

Well, based on our data, about a third of people will consider switching to another company after just one bad experience during onboarding. So if your CSV importer doesn't work right, which is super common considering customer files are chock full of unexpected data and formatting, they'll leave.

I am zero zero percent surprised to hear that. I've consistently seen that improving onboarding is one of the highest leverage opportunities for both sign up conversion and increasing long-term retention. Getting people to your aha moment more.

Quickly and reliably is so incredibly important. Totally. It's incredible to see how our customers like Square, Spotify and Zora are able to grow their businesses on top of Flatfile. It's because Flawless Data Onboarding acts like a to get them and their customers where they need to go faster.

If you'd like to learn more or get started, check out Flatfile at flatfile.com/lenny. As an outsider, it feels like Figma's just like always firing in all cylinders, shipping the best product. People love it. I use it, I should mention this, but I use it probably every day for my newsletter, for illustrations, and banners, and all the stuff. Yeah, like I don't know what I do without it. and it always feels like they were just killing it. I know that's never the reality. I'm curious, is there a story of something that just maybe didn't work out the way you hoped, whether it's a feature or launch or something like that, that just kind of shows people that it's like not everything always works out.

We run experiments all the time that don't come back with any results, you know, and we certainly have built a lot of more complex features that took a while to take off. So a good example of this is In a design system space, we have something called branching and merging. And branching and merging is this workflow of maybe you're building a really complex design system, and then you don't want anyone ever randomly touching your components that are used by thousands of other projects. So you kind of create this workflow of someone maybe effectively suggesting a change, you're reviewing it, and then pushing it in. And so in theory makes a lot of sense and things that our customers asked us for. But once we built it, in the initial stages, didn't really see that much adoption. And it didn't feel great because it was a really big investment for us. It's a lot of work that we put into it. And there's just many different reasons. Some of it was performance, some of it was like, this is a foreign workflow and it just takes time. And us helping customers implement some of those workflows, we realized some gaps because we don't really use it that much ourselves. And so I think as we're getting bigger, one of the things that I'm realizing is that we're starting to build a lot of features that are not necessarily for organizations like ours. And when we do that, we really need to be creative about how we understand how effective those are because we've had such a strong culture of internal testing and dogfooding. And those are the things that really help to make sure the quality of our product was good enough. But now we're working with really new types of customers and needing to push ourselves and build that muscle as well.

Speaking of high quality software, again, I'll repeat, I think Figma is one of the most beloved software products. It's kind of become central to a lot of the ways people work. It's also, I think, one of the fastest growing SaaS products in general. And I don't know, this may be the ultimate softball question, but I'm just curious, what is it that you do At Figma to build such high quality software, because it's rare for B2B software especially. What do you do as a product leader, as a product team, to just set this high bar, make sure that the stuff that you put out is great consistently, and the more tactical the better.

It's so important that you're using your own products. And I think we're in a very lucky position where all of us can get creative around using Figma in some way. And obviously designers are, you know, the internally within Figma are kind of the most vocal and the ones who are in the product like six hours a day essentially. But even for PMs, like one of the first things I did when I arrived was we're a little bit more of a memo culture. And I was like, you know what? We should be a deck culture because we can build those decks in Figma. And, you know, just that act alone allows you to kind of encounter a lot of issues and for you to get familiar with it. And so I think there are ways in which sometimes you have to get kind of creative to enable your company, your entire company, to use the product more. Or as an example, recently we just did calibrations for performance reviews in FigJam. And our head of design, Noah, kind of came up with this amazing template and we distributed it through HR. And that was another reason for everyone to use FigJam. And so that's the biggest thing. The more hours people are spending inside your product internally, I think it just naturally becomes better because A lot of times it's not just about people raising their hands and saying this is a problem. It's more about like, you just want to make your own, own workflows, your own day to day better and derive satisfaction from improving that. Right?

So the takeaway there is get your product teams to use the product as often as possible. That is a really clever way of doing that at Figma. Like I was, I know you mentioned in our newsletter interview that you switch from memos to decks. Usually goes the other way around and now I get The kind of the second order effects of that where people are building their decks in Figma. That is very clever. Not everyone's building collaboration software, but that is a really clever idea. And I think there's probably a bit of trickle down from Dylan's obsession with the product and making it just continuing to just like be obsessed with making a great experience combined with that, right? Like people using the product and this trickle down of we really need to make this as awesome as possible.

There are other companies, for example, when I was at Uber, you know, especially working on the driver's side, of course, like we want how they're driving and that kind of speaks to some aspects of it. One of the things that I've realized is when you are logging a bug and you kind of like add some engineers to it to have them look into it, the degree of motivation is so different if that engineer has somehow experienced a problem in some way. So for example, everyone at Uber would take Ubers into work, right? And if an engineer working in a driver app saw a driver struggling with something, they would find a kind of like, Find it embarrassing and kind of feel personally accountable to go and fix that. And like when you can create that sense of personal accountability, then like all these crazy things happen and, you know, all this progress happens. So I think for us is getting creative at Uber about, okay, well, how do we kind of increase those interaction points to the point where like, if someone building feels like they have some kind of personal relationship with the end user. And this is what happens at TIGMA too, where a lot of our designers feel personally accountable in a way because All their customers are, you know, people they already know in the community, like on Twitter and all those kinds of things. So they feel like they have to put something out there that's defensible or that they're really proud of. So I think that kind of personal accountability can really make a difference. That begs the question of, I imagine this engineer at Uber coming back to.

Their desk and like, I'm gonna fix this bug. And then their PM's like, no, we got a goals to hit. Here's our priorities. We got this roadmap. We don't have time to fix this right now. It's just one random bug. And so there's kind of a two-part question. Just like you have an approach to that. Do you encourage engineers, designers, just fix stuff that seems broken slash you mentioned that you have a fun experience with OKRs and how you've approached OKRs at Figma and you've kind of gone back and forth a little bit. And so maybe as a second part, just like talking about your experience with OKRs at Figma.

On the first part, I would say that I think one of the most powerful things, especially for startups, is that kind of bottoms up energy, right? And maybe a developer noticing something is wrong and just going off and fixing it. And for the most part, I try not to get in the way of that because if people are doing that constantly and every other company is kind of trying to make the product better, that is sometimes a way more effective way to improve the quality of experience than this top down of like, oh, let's define this quality experience metric and try to change all the things because you might miss these things. So that's one aspect. And the second thing is, I think a lot of PMs have grown to realize this, which is like, if you ask an engineer about how much time it'll cost to go and build something, and it's something that they came up with or they're advocating for, it's almost always half the time. as something that you are asking for as a PM, right? And that kind of motivation is so different. And that's why getting the buy-in of developers is really important, right? Because you want to feel like they're personally invested in this problem and then all of a sudden their willingness or their creativity or all these things kind of spike. And so when you kind of think about all those things, when there's a situation where an engineer or a designer is trying to fix kind of a real custom problem, I'm kind of like, by all means, right? So that's on that. OKRs are like totally bigger topic and maybe I'll kind of set the context of why I have such a love-hate relationship with it, which is that a lot of my career, I've actually just worked on core experiences and OKRs are kind of like the bane of my existence in a way, right? Because when you're working in the core experience, sometimes you're just kind of like, I'm just trying to make the experience better, and sure I can come up with this BS way to measure what that looks like, but that's not what I'm thinking about every day anyways. It just seems very performative and there's just a lot of work that goes into it. And you kind of encounter one of two situations. One is you come up with some secondary metric that nobody actually cares about, that technically you can measure and technically you can move, but you haven't actually proven that it really matters. so maybe it is some kind of like satisfaction metric that you kind of have on a survey, but you haven't actually done the work to show that that actually has correlations with retention or anything that actually, quote, matters for real in the business or, you know, it's some kind of weird usage metric or something like that. Right. And then the other extreme is to say, like, no, we're going to be ambitious and we're going to send it for business goals. So for example, you know, even if I was the PM for the rider experience at Uber, I'd be like, you know what? We're going to contribute incremental trips because the experience is going to be so good that we can get more people to come back. Right? And I think the reality for a lot of that is it's kind of a metric that you don't have full control over, or there are many hops until it can kind of affect it and like, okay, well maybe we can make the experience better. Maybe that kind of improves or touches and then maybe it's, you know, and by the time you get there, you actually can't even prove that you moved, like, the top level metrics. So either you anchor on something that, like, matters, but you can't move, or you anchor on something that you can move, but doesn't actually matter. So that's kind of the relationship I've had with OKRs. And so, you know, it's really frustrating. Right. So when I write that thing, you know, one of the things I realized is that, you know, we had OKRs, but people were kind of treating it almost as like a to-do list or a task list of like, okay, here's how by the end of quarter I need to complete these tasks, and then I will feel like. I did my job kind of thing. And we would have these dreadful meetings where we go through these spreadsheets and have people stand up in front of everyone and talk about those commitments or those key results rather. But they were dreadful for a reason, which is that you just couldn't really understand what the team actually really cared about. And it kind of got to this point where we had all these, and this kind of is Similar to the secondary metric problem, but like either you can approve that you actually moved it or you're trying to work on something that like, I don't actually understand why it's useful. And so that was when I kind of deprecated it on the, you know, and said, I just want to understand, like your headline, like what are you trying to do? Like philosophically and just like, don't stress about whether you can measure it or not. I just don't understand what you're offering. for, right? And let's first have that debate, right? And then once we get there, then let's talk about, okay, well, what are some ways that you can measure it? And some of it is qualitative, some of it is quantitative, and that's fine. And I almost kind of feel like sometimes it's better to take the report card like approach of saying, Hey, just give yourself a score. Tell me how you derive that score. Let's all understand that like the metrics and those inputs that go into it can change over time and we're gonna get more sophisticated on how we measure it. Right? But at least everyone understands what on earth you're trying to go for. So that's kind of where I moved in my first year, I would say. And then we hired a head of data who is a friend of mine from Uber too. And one of the things she felt was like, okay, but it's still very loosey-goosey and super subjective. So let's just try to bring OKRs back and see if we can just do them better next time. And so we've done that. and they were definitely better than when they first arrived, just because we had a data science team and we had more rigor around metrics and things like that. But again, this time it was less about not understanding what people were doing, but more like not understanding if teams are actually committed to moving those OKRs. And one of the problems that you find is we have these OKRs, but they kind of feel like these post-rationalizations of the projects that you're working on anyway. and at the end of the quarter, you kind of come back and see if those OKRs move, fingers crossed. Right? But like, if you stop an engineer in the middle of the hallway or the virtual hallway, so to speak, and ask them, okay, like what are your team's biggest goals or OKRs? It's like, often times, like they wouldn't be able to say it. They're just like, well, I'm working on this project that's really important. Right? And so it's like, well, what's the point of kind of publishing this OKR if like you're actually not thinking about moving it on a daily basis almost, right? And so that's when we tried to experiment with this terminology, like, well, maybe if we call it commitments instead, people would kind of take it a little bit more seriously. And it's kind of my belief that oftentimes commitments are kind of this pair between the why and the what. And sometimes the face of the commitment is the what. It's like a project and there are many whys behind it. or it's the why and there are many projects behind it. But I kind of was trying to formalize that idea, but it definitely felt a little bit complicated a little bit. Sometimes people are like, well, like, I mean, okay, has exists for a reason. And like, this is basically an OKR with just like a different name. So, my honest answer is we still haven't figured it out, you know, and we're still iterating on a bunch of different things. But I think I've developed some philosophies around it, which is, you know, no matter what you call it, right? Because like, you know, these, It doesn't matter as much. I think that for me, there are three things that really matter about a good OKR. And one is legibility. People look at it and understand what it is. And it's not some weird, obfuscated metric that doesn't mean anything to anyone. I think actionability, I want OKR to inspire action. You look at that and you're like, it stirs action, makes me want to do something differently.

Right.

And then the third one is authenticity, which is like, does this actually honestly depict what you're doing or what you're trying to do on a day-to-day basis? Because if it doesn't, then like, it's hard for me to trust that that matters or if that's something that just happens to describe what you're doing but isn't really connected in a meaningful way, then, you know, I kind of question the value of it also. that's why I am in the process. But, you know, I definitely am all ears to advice around this kind of stuff because I feel like we haven't quite cracked the code.

I love hearing that, that whole journey. I feel like you always hear from product teams, here's what we do now, you never hear, here's the experiments we've been through, here's what we've tried, here's what worked for a while, here's what doesn't work now, and here's what we're doing now. So it's really cool just to hear all the experimentation you've done. Clearly, Figma is a company where you encourage experimentation and trying new things that aren't working. And it's cool they have the flexibility to just like, let's just do headlines for now. No more specific goal metrics. We're just gonna build things that we think are important. And then the newsletter post for folks that are listening, you should actually show the templates that you're using these days for planning your projects and kind of laying out your OKRs. So folks can check those out if they're interested in seeing how you're doing that now. you also mentioned you've hired this awesome data scientist and maybe just expanding that further. I imagine a lot of the success of Figma and the product that you built is the people that you hire. At Figma, I believe you have 22 product managers, which sounds very small for a company like Figma, and I imagine they're all amazing. I'm curious what you look for in product leaders and product managers that you hire that may be other folks aren't as focused on. And just like, what does the interview process look like at Figma?

Yeah, I shared some of these things, right? Like I really feel passionately about storytelling and, you know, not to give it away or anything, but one of my favorite interview questions is asking, describe to me a time when you're part of a controversial product decision, right? And, you know, what did you do and all those things? And I think it's really revealing because, you know, if they can kind of like set up this conflict and understand like why this problem is really important. and represent both sides in such that you can understand why that conflict existed in the first place and they can do it in this kind of like, you know, even keeled way where you realize that they can take on these different perspectives. Like you start to learn a lot about that person, I think. Or sometimes I just ask them for basic things like, okay, talk about kind of like a big problem that you worked on. And the thought experiment for me is always like, coming out of that, do I feel compelled to work on that problem? Right? And no matter how boring it sounds on the surface, like, I think a really great product manager kind of like can catch something. It's like, well, this is why it's so existential, and this is why it's so interesting. I'm like, really rallied at trips. So that's kind of one big thing of like storytelling, communication, because at the end of the day, like so much of our job is around that. I think other than that, you know, some of the things that I value are things like I kind of think about as like, hi, Dan with UX Conversations. It's kind of like we talk about problem and, you know, I think about kind of like when you're exploring solutions, it's kind of this tree of, okay, there's just these branches of explorations and you kind of finally arrive at these solutions. And like a ton of people who can go up and down branches really quickly have a really high command of all these different altitudes as well so that we can talk through a lot of things at the end of the day kind of feel like, we walk away with some progress. And I think that at Uber, our first product officer, Jeff Holden, was someone who often talks about kind of fast forwarding to the future and this idea that, okay, let's just pretend we ran that experiment. What do you think it'll come back with? Or let's pretend we ran that, you just use a study and the kind of PMs who have the ability to kind of imagine those outcomes. I think it helps us be much more efficient too, because we're like, well, if we all think that's gonna go there and that's not gonna compel us to take any action, why do it at all? And so I think a lot of PM is about those kinds of shortcuts that you have to take. And it's not just about what we build, it's about building the right things. And sometimes it's just as important to decide not to build something, but it's only possible if you can have that kind of.

I love that. I was going to ask you for your favorite interview questions in our lightning round and you jumped ahead, which is great. And those are really good examples. Hopefully they don't give too much away. I want to chat a bit about growth and how Figma grows. If you ask people about product led growth and just like, whenever people talk about product led growth, they're always like, companies like Figma, Slack, dot dot dot. Figma is always like seen as a model of product led growth and a product that grew through I imagine now there's a very robust sales team, and I imagine even earlier than people probably imagined there was a sales team. I'm curious as a product leader, what you've learned about how to effectively work with sales and what you teach your product managers about how to work with sales to collaborate effectively.

We're really lucky to have a sales team that understands our product really well and can hold their own with customers who are often also design leaders, product leaders, and things like that. And I think that kind of credibility goes a really long way. One of the things that I kind of, we all are collectively realizing is, we talk about product-like growth, but in some ways, I like to think about it more as kind of community-led growth, or there are certain people inside a company that feel so strongly about Figma and that they're helping kind of push for it and these advocates and evangelizing for Figma, right? And so oftentimes, like what the sales team does is really empower those individuals to make a stronger case or kind of connect them to the rest of the company so that we can kind of get a wider deployment or more leadership buying and things like that. And so oftentimes a sales team is kind of like playing that role of, you know, creating those human connections and helping equip designers feel passively inside a company with the data, you know, with the stories and all those things to help make a case. And I think that's like the most powerful way in which we can spread where, you know, this space of like Figma is not the sales team, but in fact, it's the internal, you know, designer.

Right.

And so that's kind of like the mental model that I think we've been using. And we're fortunate enough to have people inside companies who are so to kind of want to play that role. And so when you kind of like take that lens on, then you start to kind of understand, okay, how can we help set this person up for success? And the sales team has like different ways to do it. Like the product team help in terms of like giving them visibility into how we're thinking about like evolving the product or what other customers might be doing. And so I really see it as kind of this partnership to enable that as much as possible. You know, and I think that's what, to me, what product like growth, you know, looks like at Figma is that.

That is really interesting. Basically making your champion inside the company kind of a superhero, helping them be more effective at what they're already doing, which is evangelizing this product that they really love. Interesting. Is there anything that you think Figma did early on that you think was really important for it to start to grow either in this way or in a different way? Imagine there's just like a lot of product-led growth founders that are trying to create a product-led growth product and they fail. And so I'm curious just like, what do you think people often miss and what do you think Figma did right that got it going?

I think a lot of it was about the level of intention around building community. And the more there are organic conversations happening about Figma, the better, right? And one of the nice things about Figma is you can kind of like share out a file that you've been working on and effectively open source something, but it's your way of showing here's how we do it as XYZ company and sharing that with the rest of the community. And when people see that and when people feel like they have this insider view into how other companies work, that's where there's a lot of interest, right? And more recently, over the last few years, we've really been focused on a program called Friends of Figma, where we have people who are passionate about Figma and all our different geographies kind of like come together in like a Discord channel. They meet regularly and are helping us evangelize. And again, it's kind of like that human connection between users and then between us and the users is something that really helps build that kind of like loyalty, which is the thing that then fuels all the champions to really kind of push for it internally and give people kind of like the enthusiasm and courage to do that inside their organizations.

It's interesting how many corollaries there are to Notion and how they got started. I recently chatted with Camille. I don't know if you heard that episode, but there's a lot of similarities with how Notion used their community to help jumpstart growth and continue to grow.

Totally.

It's interesting that that's, you can call that community like growth, product like growth. There's a lot of overlap there potentially. For sure. What advice would you have for folks that are, I don't know, maybe you already shared this, but just like, If you're a product-led growth founder listening to this, if any other piece of advice to that founder about how to get started with their product, their community, their growth strategy, anything else you'd want to share there.

Maybe a different way to talk about what we just talked about is just like, you know, there has to be this almost like irrational, this like emotional response to your product, right? And it's like love for it, right? First it has to be cultivated internally too. Like, you know, people internally have to authentically love something to really stand behind it. But then, you know, externally too, if people are loving something to the point where they can sing at the top of their lungs and just like really talk about how Figma is great, like if we can get there, like that's, that's like a wonderful place to be, right? And I think that's both a combination of like, you've really solved their problems slow, but you also kind of like equip people with a philosophy around a different way of working. And I think that's what worked well for Figma too, which is like, There's something controversial about this idea that everyone can see what you're doing or that multiple designers can be in the file at the same time. We like to say that one of the first responses we saw on Stigma was, if this is a feature of design, I'm quitting. I'm changing careers. And there's that kind of tension of that narrative tension, but that is signal that you're kind of part of this revolution. and you're trying to change something and when you equip your customers or user base with that, then I think that's something that they can really get behind and champion. So it's not just that they're championing for a tool, they're also championing for a new way of working. Obviously that's a tall order. So I want to come up with that. But hopefully, if you're a founder and you're working on something, your vision is so big that you have those kind of ideas and it's like, how do you actually Equip your customers to want to talk about that.

That's awesome. Reminds me of a quote and kind of a tagline that the Airbnb's first growth team had for a long time. Love drives growth, not the other way around. They made posters of this, put it all over the product teams.

I love that.

Part of the office and seemed to have worked for Airbnb, clearly working for Figma. One last question. Feels like a question we have to touch on. I don't know how much you can say about all this stuff, but with the potential acquisition with Adobe, which I know isn't done yet, but I'm just curious, what do you think will change, may change, you're hoping will change, you're hoping won't change in how you build.

Product at Figma within Adobe? Totally. Yeah. I mean, you know, as you said, it hasn't closed yet, and so we're still independent companies. But, you know, when we think about that theoretical future, I think about kind of like, people often ask me, so like, what's going to happen in terms of like the products that you work on and how is that going to influence Figma? And the answers we don't know yet, but, you know, I get excited about two avenues. One is just, like, really continuing our current mission of making product design better. And the reality is we look at product design. A lot of people are still using both Adobe and Figma alongside each other. Right. And maybe you're creating that micro interaction in After Effects, or maybe you're kind of doing that intricate, like, illustration in illustrator or, you know, editing raster in Photoshop, right? And then you're bringing some of those things into Figma. But when you think about the end-to-end product development process, there's so many ways in which if we can make all those things seamless so that you're not juggling a bunch of apps or it can have one single source of truth, that's really exciting to me to think about. So concretely what that means, I don't know yet, but as kind of thinking through those journeys, that gets exciting for me. And then the other thing is really collaborating with the rest of Adobe and thinking about kind of, you know, we've figured out something really interesting in the, in the form of real time multiplayer collaboration and that as a platform. Adobe has a much broader set of use cases that they've been pursuing and like, what do those two things together? Like, what could that enable? Right. And that gets exciting for me to think about all the creative tools that I've used in the past, be it video editing or 3D objects or things like that, where It's like, okay, if we can bring in the power of the browser, of multiplayer, of, you know, this feeling of like openness, would that make it way easier for people? Would it make it much easier for people to share work or get involved? So those are the things that kind of like go through my heads in terms of like what's possible. In terms of what, you know, I don't want change. Like, I really think that we've figured out something really amazing in terms of our relationship with the community. You know, we talked about kind of like proximity to community and our users. Like, those are things that we we intend to keep and keep doubling down on. And I think it's such an important part of the magic of how Figma works. So it's something that, you know, I think I will continue to do. And that's what I draw a lot of motivation from in the first place.

Awesome. You also get to work with Scott Belsky, which is going to be pretty sweet and hoping to get Scott on this podcast at some point, too.

That'll be awesome.

Any closing thoughts before we get to our very exciting lightning round?

It's really easy to listen to some of these podcasts and feel like, oh, these people have kind of figured everything out, right? But the reality is we haven't, you know, and we're still experimenting with a lot of things. You know, OKRs is a really good example of that, but a lot of other things, right? And so, you know, just the other day I wrote about kind of this idea of like us living in a work in progress world. And I was talking about more from the context of like, We live in a world where all of our products, all our product plans, our strategies, our work in progress, and how do you work in a world like that when what you're reviewing can change the next day, right? But in a similar way, I think the way we work, the way we run product processes as product managers is itself very much a work in progress. So I would love to encourage this kind of conversation, Lenny, that you're facilitating just because we have so much to learn from each other. I'd love to continue to learn more from all of you, like, on interesting ways that you grapple with these age-old problems around things like how to set goals or, you know, how to review work or how to plan. So anyway, just wanted to kind of, like, signal that we are very far from perfect, and I really eager to learn from everyone else as well.

I love that. That also reminds me of something the Airbnb Founders always came back to. Joe and Brian were both designers. And as you learn to be a designer, you kind of are taught that everything around you is designed by someone. Someone just decided this webcam is going to look this way and work in this way. This chair, somebody decided very specifically it's going to be like this. And we kind of assume the things that we're working within are just like they're figured out. Someone much smarter than me figured this out, but it's usually just someone just like you that had to figure something out quickly. And then that's what you're doing now. And so they always encouraged everyone to just remember, someone designed this doesn't mean it's the perfect solution and you should always rethink things like that and not assume.

Yeah.

Well, with that, we've reached our very exciting lightning round. I've got six short, quick questions for you. I'll just go through 'em pretty quick. Whatever comes to mind, share, and we'll see how it all goes. Sound good? All right.

Sounds great.

Awesome. What are two or three books that you've most recommended to other folks?

First one that comes to mind is Switch, and it's really about how to affect organizational change, something that Cisseer recommended to me. And yeah, the difficulty of like affecting change in a large organization basically and how to overcome that. The second one I would say is my favorite book of all time is one called the Story of the Stone, and it's a Chinese novel, one of the most famous Chinese novels of all time. It's like thousands of thousands of pages. It all takes place in a garden, but it's one of the most beautiful pieces of work I've read. So I like to recommend that even though it's nothing to do with PM.

Did you say thousands of pages?

Yeah.

About a stone.

Wow.

I will check this out. I love it. I've not heard this one before. Favorite other podcast other than the one you're currently on?

Well, I'll have to admit, you know, I am actually much more of a visual learner. Not like a listener. And so I rarely listen to podcasts, but the two that I have listened to in earnest was first one was Serial a long time ago. And then, and yours, so, you know, I think some of the best actually, but otherwise more into reading.

Awesome. This show is also on YouTube for folks that don't like listening and like watching things. Plug, plug. Favorite recent movie or TV show?

The last movie I watched was called The good nurse. And it was about kind of a serial killer working in a hospital, but it was a very different take on it. It was very human. It wasn't grotesque at all. And it was talking about how broken a system was. So highly recommend it. It's quite sad, but yeah.

Okay, good tip. What are some SaaS products that you love that you maybe use at Figma or that you just discovered that you find very useful?

Kind of cheating, but like, you know, as I mentioned earlier, like we're starting to use stick big jam for everything from calibrations to interview debriefs to product reviews to everything. So that's thoroughly started to dominate our usage. It's been cool to see. And then, you know, we have our usual suspects like Slack and Asana. And then we're kind of all over the place on the rest. Like some of us use Notion, some of us use Dropbox paper, some of us use Coda. And so we're kind of still figuring that one out, I say.

Drawbox paper. Very cool. I love that product that I feel like no one uses it anymore, but it's cool that you guys do. Final question. Favorite FigJam or Figma plugin or template?

We have this one called the alignment scale, which is a widget that you can insert into FigJam or Figma design actually, and we use it all the time. So basically it's just a simple scale and whenever people click it, Face appears on one end of the spectrum or the other. And so it's our quick way of being like, we're doing a product review, we want to pulse check, we drop it in and we're like, how are people feeling aligned or not aligned? And, you know, if people are aligned, we just move on. If not, then, you know, you know that it's worth a discussion.

So it's just, yeah, it's just a fast way to figure out where all the hotspots are. Awesome. And if folks want to find that, they can actually go to the newsletter interview that we did. I think if you just Google how Figma Builds product. It comes up number one, and then there's a link to actual templates. You can plug that right in. Yuki, thank you so much for being here. I am going to go play with Figma and FigJam right after this. Two final questions. Where can folks find you online if they want to reach out, learn more, are you guys hiring? Anything there? And then two, how can listeners be useful to you?

Yes, you can find me online on Twitter or LinkedIn. Feel free to reach out there in terms of how it can be useful to us. You know, we're really starting to build a lot of products for this audience, right? For product managers. FigJam is one example of this, right? So, you know, definitely try it out. Give us some feedback. Tell me about all the cool things that you're doing or you wish you could do on FigJam or Figma. And you can tweet at me. You can find me anywhere. And of course, we're also hiring. So if you know great people, or are interested. Yeah, there's a lot of roles, so please get in touch. Awesome.

Yuki, thank you so much for being here.

Thank you so much for having me, Lenny.

Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can on all past episodes or learn more about the show at lenniespodcast.com. see you in the next episode.