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

1. 0:00 – 9:05

   Yuhki’s background

   1. YYYuhki Yamashita0:00

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

   2. LRLenny Rachitsky0:56

      (instrumental music) 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, 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 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 enjoy 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 lennysnewsletter.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. 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 wanna 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 dot com slash Lenny to learn more, and to claim your discount. Get started today. Yuki, welcome to the podcast.

   3. YYYuhki Yamashita4:30

      Thank you for having me, Lenny.

   4. LRLenny Rachitsky4:32

      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.

   5. YYYuhki Yamashita5:00

      My team is a huge fan of this podcast, so I'm really honored to be here.

   6. LRLenny Rachitsky5:04

      Wow. That means a lot. I really appreciate that. So you are currently chief product officer at Figma, which is such an epic role at 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?

   7. YYYuhki Yamashita5:22

      My first job out of college was actually at Microsoft, and I was the product manager on Hotmail, if anyone, any listener remembers (laughs) 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 would give me exposure to all the other functions so that I can actually decide which one seems interesting to me. And so spent a couple 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, uh, version of- of Windows. And so there was just a lot of conversation about UI.... and UX, and, and that was really fun for me. And, you know, as, as I was thinking about what's next, I really felt the draw of Silicon Valley and I ended up at YouTube. And I believe Shishir has been on, on this podcast before.

   8. LRLenny Rachitsky6:19

      Yeah. You, you've ...

   9. YYYuhki Yamashita6:19

      Yeah. So Shishir 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 an iPhone before my first day. So my manager, on my first day, just sent me to the Apple Store (laughs) to buy an iPhone. But, you know, that was kind of, like, my next job. And that was kind of, like, a really, uh, interesting change for me too, of, like ... And we can talk about this later, te- as well, is different companies and different styles of product management, and really kind of figuring out ... You know, I think it was a place that taught me a lot about some of my product philosophies to date. And this is also around the time where there are a lot of interesting companies that were working in the physical and digital space. Um, and so, you know, Airbnb was one of them. Uh, 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, but 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 I, 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, but at tail end, I actually switched from PM to design, uh, and managed a few design teams working on our bikes and scooters efforts just to understand what that's like. Um, and it was around this time, around my Uber career, where we encountered this tool called Figma. You know, I'd happened to be working on a project that experimentally brought Figma into the company. Uh, 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, you know, 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, I was just really drawn to that mission, and as a pro- as a product manager who's been straddling that boundary between design and product for all of my career, I really loved how Figma proactively blurred that boundary and, you know, opened up that kind of, uh, process of participating in design. So I really got behind that mission, and that's how I ended up here at Figma.

   10. LRLenny Rachitsky8:49

       It's so fascinating that (clears throat) you moved into design from product, and then back into product. Uh, at Uber you were ... What was the role? You were head of design for the, uh, mobility team?

   11. YYYuhki Yamashita8:59

       Yeah. It was called New Mobility, focused on just ... Or Micro Mobility Efforts, basically. Yeah.

2. 9:05 – 10:29

   What Yuhki learned from being on a design team

   1. YYYuhki Yamashita9:05

   2. LRLenny Rachitsky9:05

      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? Do you-

   3. YYYuhki Yamashita9:14

      Yeah.

   4. LRLenny Rachitsky9:14

      ... encourage people to try that?

   5. YYYuhki Yamashita9:16

      Well, you know, as you said, it's not for everyone. But I, 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 push on the product from a different angle. 'Cause 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, the last thing is, like, I actually think it's an opportunity for, you know, design and PM to learn from each other, right? Like, when I became a manager of design teams, one of the things that I coached designers on are, like, how to win over PMs, you know? And, like, how to speak in PM's language. And, uh, you know, likewise, it's important for PMs 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 to do this.

3. 10:29 – 12:20

   Why managing designers is more difficult than managing product teams

   1. YYYuhki Yamashita10:29

   2. LRLenny Rachitsky10:29

      Which job would you say is harder, design or product management?

   3. YYYuhki Yamashita10:32

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

   4. LRLenny Rachitsky10:38

      Interesting.

   5. YYYuhki Yamashita10:39

      And I think part of it is that designers are, uh ... 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. Uh, 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 th- the experience working on different kinds of problems, at the end of the day I feel, you know, they want to be working on the thing that matters most to the company. So from that perspective, it's easy. But, you know, as you know, and the reason this podcast exists is because PM isn't easy. And so the discipline, I think, is, is harder in a sense that, like, it's sometimes hard on a day-to-day pace to know if you're doing the best thing you could possibly be doing.

   6. LRLenny Rachitsky11:47

      Mm-hmm.

   7. YYYuhki Yamashita11:48

      And so I think that makes it a little bit harder as a PM as well.

   8. LRLenny Rachitsky11:52

      I had a, a designer friend (clears throat) who moved into-

   9. YYYuhki Yamashita11:55

      Yeah.

   10. LRLenny Rachitsky11:55

       ... a PM role and had a product role at a startup.

   11. YYYuhki Yamashita11:57

       Mm-hmm.

   12. LRLenny Rachitsky11:58

       And she's like, "Holy shit, I had no idea how hard being (laughs) a product manager was, and a product leader. I have so much more empathy for the PM role." And so it's-

   13. YYYuhki Yamashita12:07

       Yeah.

   14. LRLenny Rachitsky12:07

       ... interesting it works in both ways. Similarly, I was-

   15. YYYuhki Yamashita12:09

       Totally.

   16. LRLenny Rachitsky12:09

       I was actually a manager of engineers at one point, and I felt-

   17. YYYuhki Yamashita12:12

       Mm-hmm.

   18. LRLenny Rachitsky12:13

       ... S- the same way where managing PMs was a lot easier than managing engineers. So...

   19. YYYuhki Yamashita12:17

       Yeah.

   20. LRLenny Rachitsky12:17

       Kinda translates to a lot-

   21. YYYuhki Yamashita12:18

       Yeah.

   22. LRLenny Rachitsky12:18

       ... different roles.

   23. YYYuhki Yamashita12:19

       I can see that.

4. 12:20 – 16:35

   Why storytelling is important for product managers

   1. YYYuhki Yamashita12:20

   2. LRLenny Rachitsky12:20

      Folks listening to (clears throat) 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 has most contributed to your success as a leader, as a product leader, what do you think that would be?

   3. YYYuhki Yamashita12:45

      You know, people who work with me know that I often talk about storytelling. And in fact, if you've ever reported to me, storytelling has co... Showed up in some kinda (laughs) performance review-

   4. LRLenny Rachitsky12:53

      Mm-hmm.

   5. YYYuhki Yamashita12:53

      ... I feel, and that's how much I care about it. And, you know, I actually think that a lot of being a great product manager is being a great storyteller. And I know, like, a lot of us have already talked about it out there. I think s- the importance of storytelling is understood, but maybe I, I would share two things that are specific about it that I think are interesting. One is just understanding the power of synthesis. And, you know, it's this idea that maybe even as kind of like a early career PM, you know, you're inside some of these reviews and, you know, a lot of people say, "Hey, like at least s- you can take some notes for the meeting, right? So that, you know, you're adding value." And so that's common advice I hear, 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 like a dis- 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, uh, you know, push the project forward from there? So that's kinda one example, or another example is I really love thinking through frameworks and offering ways in, of talking about a problem or ways of thinking about a problem, and that's kind of synthesis too of 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 r- reading, like, a William Yates poem, and you're trying to kind of like... You observe all these interesting things.

   6. LRLenny Rachitsky14:35

      Mm-hmm.

   7. YYYuhki Yamashita14:35

      But then you're s- you have to take those different observations and, like, distill into a thesis, into something cohesive, and I think that's what a good PM can do. Like, all these different ideas and opinions and problems, and how do you kind of 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 like, you know, a story is only as good as, you know, the actions it's capable of driving, and a lot of times that I often coach my product managers on, on we're living in a world where everyone is constantly distracted, right? And you kinda 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 memefication, which is this idea that, like... I found this out most a- at Uber, I feel, where there are certain insights, data insights, research insights, that were memefied to the point where, like, someone like Travis or Dara was just, like, 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, like, people are able to do that and draw from that in that way. And that's what ultimately kind of like sticks, right? And so when you kinda start thinking about it from that perspective, it's really powerful because it's the way in which knowledge is transferred within the company, and you kind of, you know, compel action through it. Or, you know, when, when I'm kind of like, uh, being maybe asked questions by other leaders 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, like, what this project is about, or, you know, 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 if you kinda take that mindset, you just realize that it's a really useful way to think about everything.

5. 16:35 – 18:51

   How to improve your storytelling skills

   1. YYYuhki Yamashita16:35

   2. LRLenny Rachitsky16:35

      I'm really excited to chat about (clears throat) this idea because it comes up a lot, uh, 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 meme 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-

   3. YYYuhki Yamashita17:09

      Yeah.

   4. LRLenny Rachitsky17:09

      ... you recommend they specifically do to get better at this skill? Or is it just-

   5. YYYuhki Yamashita17:12

      Yeah.

   6. LRLenny Rachitsky17:13

      ... do it again and again and watch me do it-

   7. YYYuhki Yamashita17:14

      Yeah.

   8. LRLenny Rachitsky17:14

      ... watch other people do it, and you'll learn?

   9. YYYuhki Yamashita17:16

      Yeah. I think of it as kind of like resetting the internal computer of my brain a little bit so that, like, I start from scratch again. And when I'm starting from, like, no context at all, can I build up the story from there and explain what's happening? And oftentimes, you're just, like, 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, kind of 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 nuance, nuanced enough way what you're grappling with. And so that kind of, like, reset moment and to pull yourself out helps you tell a better story in many cases. So that's, that's one thing that keep comes to mind. Yeah.

   10. LRLenny Rachitsky18:03

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

   11. YYYuhki Yamashita18:12

       Yeah. I think 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. There's 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 learn 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.

6. 18:51 – 22:34

   Why PMs need to know the “why” of the product they are managing

   1. YYYuhki Yamashita18:51

   2. LRLenny Rachitsky18:51

      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, and at Figma?

   3. YYYuhki Yamashita19:17

      I really can't remember where I heard this, but it, it really stuck with me because, you know, 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, you know, in our case, like, our customers come up with a ton of different ideas, right? And, you know, certainly kind of the what and the how are things that are shared, uh, 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, uh, been working at Microsoft for a long time. And, you know, I was earlier in my career, so I was just really focused on my, what we called our feature crew, like our engineer, designer, artist, you know, our tester, and just writing specs that really specified exactly how everything works, right? And so that was kind of the Microsoft culture back then. And your specs had to be perfect, right? Then I moved over to YouTube, and all of a sudden, you know, 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 there'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 develop- designers could... 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... All these local decisions that you're not a part of, how do you make sure that a great decision is made? And if everyone has an understanding of why we're doing this, what problem we're solving, then, you know, 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 as well. So for example, our engineering team at Figma, whenever we do a retro or postmortem, you know, 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 this 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 out the problem. But I think there's one more step we 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, um, make a bigger product impact by fixing kind of like that underlying condition that created the problem in the first place.

   4. LRLenny Rachitsky21:55

      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've never heard people-

   5. YYYuhki Yamashita22:00

      Yeah.

   6. LRLenny Rachitsky22:00

      ... actually using it. So you actually do this at your postmortems, you said?

   7. YYYuhki Yamashita22:03

      Yes, the engineering team, uh, uh, does this at Figma. Yeah.

   8. LRLenny Rachitsky22:07

      That's so interesting. Can you talk a bit more about these postmortems? Is this just like when something goes wrong, or is this just every project, your retrospective postmortem sort of thing?

   9. YYYuhki Yamashita22:14

      As it relates to five whys, it's more when something-

   10. LRLenny Rachitsky22:17

       Mm-hmm.

   11. YYYuhki Yamashita22:17

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

   12. LRLenny Rachitsky22:33

       Cool. Okay.

7. 22:34 – 26:13

   The importance of developing a community and strong customer relationships

   1. LRLenny Rachitsky22:34

      Another attribute of the product team and how you build product at Figma that you shared that was really interesting is, you mentioned that you just have an obsession with the 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, we're really close to customers. We talk to customers all the time. Of course you gotta 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, of just like, wow, this is how close we are to customers, and s- maybe something that emerged out of that, that'd be really cool to hear.

   2. YYYuhki Yamashita23:07

      Well, I think a lot of it starts with our origin story in many ways, uh, which is that way back when, when Dillon and this small group of people were building Figma, you know, this is the time when no one believed that was possible to have a design editor in the browser, right? And so it just seemed like science fiction almost. And yet, what Dillon did, you know, 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, you know, 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 kind of like listening really carefully to what the community had to say, and through that process, making them, you know, evangelists, right? And that's kind of where a, 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 then that are now advocating for Figma and helping it spread within the community and within their company. So, you know, that's kind of the backdrop for why we have such a strong connection with, 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 that 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 im- 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, like, the, the most crazy version of it maybe is, you know, Dylan's always reading customer feedback. In pro- in fact, he reads the most customer feedback of all of us and has been doing that for, like, 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 and be like, "Hey, this seems concerning," or, "We're getting this feedback." And it got... kind of got to a point where, you know, 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, you know, for, uh, 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, like, one like, 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.

8. 26:13 – 28:11

   How to use different types of feedback

   1. LRLenny Rachitsky26:13

      That's an awesome idea for a channel, way to kind of contain that, uh, 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 of just deciding what's worth paying attention to?

   2. YYYuhki Yamashita26:31

      As we built out our research and data functions, you know, it's really important to kind of balance out the vocal minority with, you know, 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 Figma 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 k- know that you don't have any blind spots. So, I think that's one of the things that, like, I've, 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, or insight from those other sources as well.

   3. LRLenny Rachitsky27:46

      That reminds me, I think Twitter was really instrumental to the beginnings of Figma.

   4. YYYuhki Yamashita27:50

      Yeah.

   5. LRLenny Rachitsky27:50

      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, his code to do that. Is that right?

   6. YYYuhki Yamashita28:02

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

9. 28:11 – 32:44

   Working with Dylan Field

   1. YYYuhki Yamashita28:11

   2. LRLenny Rachitsky28:11

      What is it like to work with Dylan Field? Uh, 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 the 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?

   3. YYYuhki Yamashita28:32

      We're very different, actually. And, uh, you know, Dylan is very... He's very based on intuition and instinct, and that intuition is actually built off of, you know, thousands and hundreds of thousands of, you know, 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 did you conclude that?" And, you know, part of my job is to kind of like fill it 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 his, he's very much about that, or, you know, I think there's a way which sometimes as a product manager you kind of wanna lay out a problem and say, "Okay, we're gonna first focus on this problem, and then there are these three approaches. We're gonna take this approach and, like, have a review, you know, 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, like, the end implementation to viscerally 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 just... he really needs to see it to, to kind of feel it. But it's not totally random. It is based on, like, all these interactions with customers that somehow encoded in him to, to kind of like build up some of those kind of intuitions. And I think one of the things that's really interesting about him is that, like, his... he actually really cares, like, 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, 'cause, you know, this is the era where you would take meetings... if you take meetings, they're all outside, right?... (laughs) and then he, he needed to use the bathroom, so he came over to my house in the Castro. He used the bathroom, and then he met my partner, and my partner was on Figma. And Figma pulled up because, you know, he's, he's doing work. And then (laughs) Dillon, you know, just went straight in there and wanted to ask what the biggest problems were or, like, what's not working, and they started kinda like geeking out on some issue around Google fonts. And, you know, this is, like, the first major interaction between the two of them, but it's kinda one of those things where, like, that's how much Dillon 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 added. Um, and so that's kind of, uh, the level of kind of, I guess, customer obsession, if you will, um, that he exhibits and, and then in turn informs, um, his intuitions.

   4. LRLenny Rachitsky31:16

      That's amazing. Figma's, 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- and he's taking the opportunity to, like, experience it in real time every chance he gets, sounds like.

   5. YYYuhki Yamashita31:31

      Yeah.

   6. LRLenny Rachitsky31:33

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

   7. NANarrator31:41

      At least 40%.

   8. LRLenny Rachitsky31:42

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

   9. NANarrator31:45

      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.

   10. LRLenny Rachitsky32:05

       I am 0% 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.

   11. NANarrator32:19

       Totally. It's incredible to see how our customers like Square, Spotify, and Zuora are able to grow their businesses on top of Flatfile. It's because flawless data onboarding acts like a catalyst to get them and their customers where they need to go faster.

   12. LRLenny Rachitsky32:36

       If you'd like to learn more or get started, check out Flatfile at flatfile.com/lenny.

10. 32:44 – 34:54

    Testing at Figma and the branching emerging feature

    1. LRLenny Rachitsky32:44

       As an outsider, it feels like Figma's just, like, always firing on all cylinders, shipping the best product. People love it. I use it, I sh- I shouldn't 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'd do without it. And it always feels like Figma's 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 a launch, or something like that, that just kinda shows people that it's, like, not everything always works out?

    2. YYYuhki Yamashita33:14

       We run experiments all the time that don't come back with winning 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 the 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, you know, effectively suggesting a change, you reviewing it, and then pushing it in. And so o- in theory, makes a lot of sense, and things that our customers asked us for, but once we built it, you know, in the initial stages, just didn't really see that much adoption. And, you know, didn't feel great because it was, like, a really big investment for us. That's, like, a, a lot of work that we've put into it. And there were 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, like, us helping customers kind of 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, 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 helped make sure the quality of our product was good enough. But now we're working with really new types of customers and, you know, needing to push ourselves and build that muscle as well.

11. 34:54 – 36:50

    Why your entire company should be using your product

    1. LRLenny Rachitsky34:54

       Speaking of high-quality software. Again, I, I'll repeat, I think Figma is one of the most beloved software products. It's kinda 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? 'Cause 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 you know, the more tactical, the better.

    2. YYYuhki Yamashita35:27

       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, when I arrived was, we were a little bit more of a memo culture, and I was like, "You know what? We should be a deck culture." Because (laughs) 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, to use the product more. Or as an example, recently we just did, uh...... 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?

12. 36:50 – 38:48

    The importance of having personal accountability

    1. LRLenny Rachitsky36:50

       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 switched from memos to decks. Usually it 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 Dillon's obsession with the product and making it... just continuing to just, like, be obsessed with making it 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."

    2. YYYuhki Yamashita37:27

       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. But one of the things that I've, 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, you know, everyone at Uber would take Ubers into work, right? And if an engineer working on the driver app saw a driver struggling with something, they would find it... 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, it was getting creative at Uber about, "Okay, well, how do we kind of in- increase those interaction points to the point where, like, if someone building feels like they have some kind of personal relationship with the, with the end user?" And this is what happens at Fig- Figma 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, 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

13. 38:48 – 40:50

    Why Yuhki likes to stay out of the way of engineers fixing their own bugs

    1. YYYuhki Yamashita38:48

       a difference.

    2. LRLenny Rachitsky38:48

       That begs the question of... I imagine this engineer at Uber coming back to their desk and like, "I've got to fix this bug." And then their PM's like, "No, we've got goals to hit. Here's our priorities. We've 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, do you have a approach to that? Do you encourage engineers, designers to 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.

    3. YYYuhki Yamashita39:21

       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 everyone in the company is kind of trying to make the, the product better, that is sometimes a way more effective way to improve the quality of experience than this, like, top down of like, "Oh, let's define this quality experience metric." And, you know, try to, like, change all the things, because you might miss these things. So that's one, one aspect. And the second thing is, you know, 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, like, you are asking for as a PM, right? And that kind of, like, motivation is so different. And that's why, you know, getting the buy-in of developers is really important, right? Because you want them to feel like they're personally invested in this problem, and then all of a sudden, like, their, their willingness or their creativity or all these things kind of spike. And so when you kind of think about all those things, where there's a situation where, like, an engineer or a designer's trying to fix kind of like a real custom problem, I'm kind of like, "By all means," right? So that's on that.

14. 40:50 – 48:40

    Yuhki’s thoughts on OKRs and how they are used at Figma

    1. YYYuhki Yamashita40:50

       OKR is, like, totally bigger topic. And maybe I'll kind of set, set the context of why I have such a... just, like, love-hate relationship with it, which is that a lot of my career, I've actually just worked on core experiences, and OKRs were kind of like the bane of my existence in a way, right? Because when you're working on a 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, like, BS way to measure what that looks like, but, you know, that's not what I'm thinking about every day anyway." So it just seems, like, very performative and there's just, like, a lot of work that goes into it. And you kind of encounter one of two situations. Like, one is you come up with some secondary metric that nobody actually cares about, right? That technically you can measure and technically you can move, but, like, you haven't actually proven that it really matters. So maybe it is some kind of, like, satisfaction metric that you kind of have a... some survey, but, you know, 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 gonna be ambitious and we're gonna set up 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 gonna contribute incremental trips because the experience is gonna 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... there are many hops until it can kind of affect it. And like, okay, well, maybe we can make the experience better and maybe that kind of improve- improves retention and maybe this... 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 bank on something that you can move but doesn't actually matter. So that's kind of a relationship I had with OKRs and so I've been... You know, it's really frustrating, right? So when I arrived at Figma, 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, you know, I, I did my job," kind of thing. And we would have these dreadful meetings where we go through these spreadsheets, um, and, like, have people stand up in front of everyone and, like, talk about those commitments or th- th- those key re- results rather. But they were dreadful for a reason, which is that, like, 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 couldn't prove 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, uh, 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. Just... I just want to understand what you're optimizing 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 about how we measure it, right? But, like, at least everyone understands, like, what on earth you're trying to go for, right? So that's kind of like where, you know, uh, where I kind of moved in my first year, I would say. And then we hired a head of data, who is a friend of mine, you know, from Uber too. And one of the things she kind of felt was like, "Okay, but this is still very loosey-goosey and super subjective. So, like, let's just try to bring OKRs back and see if we can just do them better next time," right? And so we've done that. And they were definitely better than, like, you know, when I first arrived just because we had a data science team and, you know, we had more rigor around metrics and things like that. But again, like, 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, you know, 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 moved, 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?" Like, oftentimes, like, they wouldn't be able to say. 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, you know, we tried to experiment with this terminology, like, well, maybe we should call it commitments instead. Like, people would kind of take it a little bit more seriously. And it's kind of my belief that, you know, oftentimes, like, 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. So I kind of was trying to formalize that idea, but it definitely felt a little bit complicated, a little bit... Sometimes people were like, "Well, like, I mean, OKRs exist 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, like, for me, there are three things that really matter about, like, a good OKR. And one is legibility. Like, people look at it and understand what it is and, like, it's not some, like, weird obfuscated metric that doesn't mean anything to anyone. I think, like, actionability. Like, I want an OKR to inspire action. Like, you look at that and you're like, "It stirs action, makes me want to, like, 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 it 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, I kind of question the value of it all. So that's where 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.

    2. LRLenny Rachitsky47:38

       I love hearing that, (clears throat) 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 are working. And it's cool they have the flexibility to just like, "Mm, let's just do headlines for now. No more, no more specific goal metrics. We're just gonna-"

    3. YYYuhki Yamashita48:06

       Yeah.

    4. LRLenny Rachitsky48:07

       "... build things that we think are important." And in the newsletter posts, for folks that are listening, you sh- actually show the templates that you're using these days-

    5. YYYuhki Yamashita48:13

       Yeah.

    6. LRLenny Rachitsky48:13

       ... for planning your projects and kind of laying out your OKRs.

    7. YYYuhki Yamashita48:17

       Yeah. Yeah.

    8. LRLenny Rachitsky48:17

       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.

15. 48:40 – 51:45

    Figma’s interview process

    1. LRLenny Rachitsky48:40

       I'm curious what you look for in product leaders and product managers that you hire, that maybe other folks aren't as focused on. And just like, what does the interview process look like at Figma?

    2. YYYuhki Yamashita48:51

       Yeah. I shared some of these things, right? Like I really f- feel passionately about storytelling and, you know, not to give it away or anything, but one of my favorite interviewer 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, I think it's, it's really revealing because, you know, if they can kind of like set up this conflict and understand like why this problem was really important and represent both sides in a, in... such that you can understand why that conflict ex- existed in the first place. And they can do it in this kind of like, you know, even keeled way where you, 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, t- 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 cast something as like, well this is why it's so existential for us and this is why it's so interesting and like really rally the troops. 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 high bandwidth 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 this, these branches of explorations and it, you kind of finally arrive at these solutions and like the kind 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 that at the end of the day kind of feel like we walk away with some progress. And you know, I, I think that like at, at Uber, our first C product officer, Jeff Holden, was someone who o- often talked about kind of fast forwarding to the future and this idea that, you know, okay, like let's just pretend we ran that experiment. What do you think it'll come back with? Or let's pretend we like ran that re- re- just user study and like the kinds of PMs who have the ability to kind of imagine those outcomes, I think like it helps us be much more efficient too, because we're like, well if we all think that it's gonna go there and that's not gonna compel us to take any action, why do it at all? Right? And so I think a lot of PM is about kind of those kinds of shortcuts that you have to take, right? And it's not just about what we build, it's about, you know, building the right things and sometimes just as important to like decide not to build something, but it's o- only possible if you can have that kind of like imagination or that ability to see around corners.

    3. LRLenny Rachitsky51:37

       I love that. I was gonna 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.

16. 51:45 – 54:57

    How Figma’s sales team works by creating human connections and empowering designers

    1. LRLenny Rachitsky51:45

       I wanna 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 as, and a product that grew through product. 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.

    2. YYYuhki Yamashita52:24

       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, you know, 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, you know, we talk about product led growth, but in some ways, you know, I, I like to think about it more as kind of like community led growth or there are certain people inside a company that feels so strongly about Figma and that they're helping kind of push for it and these like 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 buy-in 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 who feel passionately 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, the s- the face 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 passionate to, 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, like 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 can 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 led growth, you know, looks like at Figma is that.

    3. LRLenny Rachitsky54:29

       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? I imagine there's just, like, a lot of product-led gr- growth founders that are trying to create a product-led growth product and they

17. 54:57 – 56:36

    How Figma built community and created organic growth

    1. LRLenny Rachitsky54:57

       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?

    2. YYYuhki Yamashita55:02

       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 o- one of the nice things about Figma is you can kind of, like, share out a file that you've been working on, and, like, effectively open source something. But it's kind of your way of showing, "Here's how we do it at so- XYZ company," and sharing that with the rest of the community. And, you know, when people see that, and when people kind of feel like they have this, like, insider view into how other companies work, that's where there's a lot of interest, right? And, you know, more recently, you know, 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 in all our different geographies kind of, like, come together in, like, a Discord channel. They meet, uh, regularly, and are helping us evangelize. And again, that'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 organization.

    3. LRLenny Rachitsky56:16

       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.

    4. YYYuhki Yamashita56:29

       Totally.

    5. LRLenny Rachitsky56:30

       It's interesting that that's... You can call that community-led growth, product-led growth. There's a lot of overlap there, potentially.

    6. YYYuhki Yamashita56:35

       For

18. 56:36 – 58:57

    Advice for founders

    1. YYYuhki Yamashita56:36

       sure.

    2. LRLenny Rachitsky56:37

       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, do you have 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?

    3. YYYuhki Yamashita56:52

       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, you know, 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 well, 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, you know, everyone can see what you're doing, right? Or that, you know, multiple designers can be in the file at the same time. Like, we like to say that one of the first responses we saw when we launched Figma was, "If this is the future of design, I'm quitting." Right? "I'm changing careers." And there's that kind of, like, tension, of that narrative tension. But, like, that is signal that you're kind of part of this revolution, and you're trying to change something. And when you can equip, you know, 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, like, a new way of working. Obviously, that's a tall order (laughs) for someone to kind of, uh, come up with that. But hopefully, you know, if you're a founder and you're working on something, your vision is so big that, like, you- you have those kind of ideas. And it's like, how do you actually equip your c- customers to want to talk about that?

    4. LRLenny Rachitsky58:35

       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-

    5. YYYuhki Yamashita58:47

       Yeah.

    6. LRLenny Rachitsky58:47

       ... put it all over the product teams-

    7. YYYuhki Yamashita58:48

       I love that.

    8. LRLenny Rachitsky58:49

       ... part of the office, and seemed to have- have worked for Airbnb. Clearly working for Figma. One last question, feels like a question we

19. 58:57 – 1:01:42

    The potential acquisition by Adobe and the future possibilities for Figma

    1. LRLenny Rachitsky58:57

       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?

    2. YYYuhki Yamashita59:12

       Totally, yeah. I mean, you know, as you said, it- 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 s- people often ask me, "So, like, wha- what's gonna happen in terms of, like, the products that you work on, and, like, how is that gonna influence Figma?" And the answer is, 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, when you 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- and then you're bringing some of those things into Figma. But when you think about kind of, like, that 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, like, juggling a bunch of apps, or you can c- kind of 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 like, as... kind of, like, thinking through those journeys, that's- 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 th- 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 and 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 head in terms of like what's possible. In terms of what, you know, I don't want to 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 there are things that we, we intend to keep and keep doubling down on. And I think it's, that's an important part of the magic of how Figma works, so it's something that, you know, I think how we'll continue to do. And that's what I draw mo- a lot of motivation from in the first place.

    3. LRLenny Rachitsky1:01:34

       Awesome. (clears throat) You also get to work with Scott Belsky which is gonna be pretty sweet and-

    4. YYYuhki Yamashita1:01:39

       Yeah.

    5. LRLenny Rachitsky1:01:39

       ... hoping to get Scott on this podcast at some point too.

    6. YYYuhki Yamashita1:01:41

       That would be

20. 1:01:42 – 1:03:44

    Closing thoughts

    1. YYYuhki Yamashita1:01:42

       awesome.

    2. LRLenny Rachitsky1:01:42

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

    3. YYYuhki Yamashita1:01:46

       It's really easy to listen to some of these podcasts and just feel like, oh, these, 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 it more from the context of, like, we live in a world where all of our products, our product plans, our strategies are work in progress, and like how do you, like, work in a world like that when what you're doing can change the next day, right? But, you know, in a similar way, I think the way we work, the, the way w- we run product processes as product managers are in itself very much a work in progress. So I would love to kind of encourage this kind of conversation, Lenny, that you're facilitating, just because we have so much to learn from each other. And I'd love to continue to learn more from all of you, like, on interesting ways that you grapple with these, like, 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, uh, really eager to learn from everyone else, else as well.

    4. LRLenny Rachitsky1:03:04

       I love that. That also reminds me of something that 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's gonna look this way and work in this way, this chair, somebody decided very specifically it's gonna 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.

21. 1:03:44 – 1:08:35

    Lightning round

    1. YYYuhki Yamashita1:03:44

       Yeah.

    2. LRLenny Rachitsky1:03:44

       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?

    3. YYYuhki Yamashita1:03:55

       All right. Sounds great.

    4. LRLenny Rachitsky1:03:56

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

    5. YYYuhki Yamashita1:04:02

       First one that comes to mind is Switch, and it's really about how to effect organizational change. Something that Shishir, uh, recommended to me. And, yeah, the difficulty of like effecting 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. Um, one of the most famous Chinese novels of all time. And it's like thousands of s- thousands of pages. It all takes place in a garden, but it's, it's one of the most beautiful piece of work I've read, so I like to recommend it, even though it has nothing to do with Figma.

    6. LRLenny Rachitsky1:04:38

       Did you say thousands of pages?

    7. YYYuhki Yamashita1:04:40

       Yeah.

    8. LRLenny Rachitsky1:04:41

       (laughs) 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?

    9. YYYuhki Yamashita1:04:49

       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, I have listened to in earnest was, first one was Stereo a long time ago and then, and yours. So, you know, I think some of the best actually, but otherwise more into reading.

    10. LRLenny Rachitsky1:05:09

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

    11. YYYuhki Yamashita1:05:18

        The last movie I watched was called The Good Nurse and it was about kind of a serial killer, uh, 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 our system was. So highly recommend it. It's quite sad, but yeah.

    12. LRLenny Rachitsky1:05:37

        Hmm. 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?

    13. YYYuhki Yamashita1:05:45

        Kind of cheating but like, you know, as I mentioned earlier, like, we're starting to use Fig, Figjam for everything from calibrations to interview debriefs to product reviews to everything. So that's thoroughly started to dominate our usage which has 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, somebody uses Coda. And so we're kind of still figuring that one out I'd say.

    14. LRLenny Rachitsky1:06:16

        Dropbox Paper. Very cool.

    15. YYYuhki Yamashita1:06:17

        Yeah.

    16. LRLenny Rachitsky1:06:18

        I love that product but I feel like no one uses it anymore. But it's cool that you guys do. Final question. Favorite Figjam or Figma plug-in or template?

    17. YYYuhki Yamashita1:06:27

        We have this one called the alignment scale which is a widget that you can insert into Figjam or Figma design actually, but, and we use it all the time. So basically it's just a simple scale and whenever people click it their 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 wanna 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 hot spots are.

    18. LRLenny Rachitsky1:07:01

        Awesome. And if folks wanna 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 the actual template so you can plug that right in. Yuhki, thank you so much for being here. I am gonna go play with Figma and Figjam right after this. Two final questions. Where can folks find you online if they wanna reach out, learn more, are you guys hiring? Anything there. And then two, how can listeners be useful to you?

    19. YYYuhki Yamashita1:07:30

        Yes. You can find me online on Twitter, uh, or LinkedIn. Feel free to reach out there. Uh, in terms of how you can be useful to us, you know, we're really starting to build a lot of products for this audience, right? Uh, for product managers. Figjam is one example of, of this, right? So, you know, definitely try it out, give us some feedback, tell me all 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 for, are interested, yeah, there's a lot of roles so please get in touch.

    20. LRLenny Rachitsky1:08:06

        Awesome. Yuhki, thank you so much for being here.

    21. YYYuhki Yamashita1:08:08

        Thank you so much for having me, Lenny.

    22. LRLenny Rachitsky1:08:11

        (music) 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 find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.

Episode duration: 1:08:35