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

Podcast Intro and Guest Background

Lenny: 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 Lenny [inaudible 01:08:35] Figma was, if this is the future of design, I’m quitting, right? I’m changing careers.

And there’s that tension of that narrative tension, but that is signal that you’re part of this revolution and you’re trying to change something. And when it equips 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 or don’t 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?

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 Yuhki Yamashita. Yuhki 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, Yuhki 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 Yuhki has found to be the most instrumental in his success in his career, and also what Yuhki and his product team have learned by building a product led growth business.

This episode builds on a newsletter post where I interview Yuhki 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 Yuhki Yamashita, after a short word from our wonderful sponsors.

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.

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. Beginning a SOC to your port can be a huge burden, especially for startups. It’s time consuming, tedious and expensive.

Enter Vanta. Over 3000 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.

Yuhki, welcome to the podcast.

Yuhki Yamashita: Thank you for having me, Lenny.

Career Path and Trajectory

Lenny: I’m 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.

Yuhki Yamashita: Hi, team, as a huge fan of this podcast, so really honored to be here.

Transitioning from Product to Design

Lenny: 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’re today as CPO at Figma?

Yuhki Yamashita: 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 I didn’t really know what product management was at the time, and I mute it as a interdisciplinary function that will give me exposure to all my other functions so that I can actually decide which function’s interesting to me.

And so, spent a couple years at Microsoft. Through that, also, moved on to Hotmail to Windows. And at the time, they were working on Windows 8 and Windows 8 was really interesting because it’s a very touch forward version of Windows. And so there’s just a lot of conversations about UI and UX, and that was really fun for me.

And 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 this podcast before?

Comparing Design and Product Management

Lenny: [inaudible 00:06:19] you.

Yuhki Yamashita: Yeah, so Shishir was leading YouTube at the time, and he continues to be a great mentor of mine, but 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 that was my next job and that was a really interesting change for me, too, of, and we can talk about this later, as well as different companies and different styles of product management and really figuring out, I think it was a place that taught me a lot about some of my product last weeks to date.

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 Airbnb was one of them, Uber was another. So I felt this draw just because it seemed just a really interesting space to be in. So eventually, ended up at Uber. Uber was another 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 I learned a lot from there.

And to date, all those companies has really been 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 realized that I wanted to dip my toes into design directly. For the tail end, I actually switched from PM to design and managed a few design teams working on our bikes and scooter efforts just to understand what that’s like. And it was around this time, around my Uber career, where we encountered this tool called Figma.

I’d 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, I got to watch how Figma changed the way it worked, how it’s spread within the company. We got to know the Figma team a little bit, as well. And yeah, I was really drawn to that mission and as a product manager who’s been straddling that boundary between design and products 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.

Storytelling and Synthesis Skills

Lenny: It’s so fascinating that you moved into design from product, and then back into product. At Uber, were, what was the role? You were Head of Design for the mobility team?

Yuhki Yamashita: Yeah, it’s called New Mobility, focused on just our micro mobility efforts, basically. Yeah.

Actionable Tips for Better Storytelling

Lenny: Do you recommend this path for PMs to switch into design? I know it’s not 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?

Yuhki Yamashita: Well, I decided it’s not for everyone, but I think that it’s, first of all, a really great empathy building exercise of understanding that point of view, and also pushing yourself to push on the product from a different angle. Because I think as a PM, you’re in the center facilitating all these different trade offs, and when you go into design, you have to ignore some of those other aspects to really be insistent on pushing on the best experience possible. Just suspend everyone’s disbelief in business feasibility or engineering feasibility to push on a vision. And that’s just an interesting exercise to do.

And then, I think the last thing is, I actually think it’s an opportunity for in design and PM to learn from each other. When I became manager of design teams, one of the things that I coach designers on, are how to win over PMs, and how to speak in PM’s language, and 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, it has to come from a place of passion that you know you really want to do this.

Product Managers Must Own the Why

Lenny: Which job would you say is harder; design or product management?

Yuhki Yamashita: They’re hard for different reasons. I would say managing designers is harder than managing product managers.

Engineering Retrospective Practices

Lenny: Interesting.

A Customer-Centric Culture

Yuhki Yamashita: And I think part of it is that designers are, it’s really important to focus on growing their craft and helping them develop as designers. So it might not be that the company’s biggest problem is one where you can actually learn this new thing you’re trying to learn as a designer, and this probably happened for engineers, too, right? You could be working on the onboarding funnel, and that might not be the best place to be learning micro interactions, or maybe it is, but 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 pace 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.

Lenny: 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, translates to a lot of different roles.

Balancing Feedback and Spotting Blind Spots

Yuhki Yamashita: Yeah, I can see that.

Lenny: 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 has most contributed to your success as a leader, as a product leader, what do you think that would be?

Early Growth and the Social Graph

Yuhki Yamashita: 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 would share two things that are specific about it that I think are interesting.

One is to understanding the power of synthesis and it’s this idea that maybe even as 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 so that you’re adding value.” And so that’s common advice, here, but I think the most powerful part of that is that in some ways, you can synthesize what happened. And a lot of things are said in a review and there’s still this bring it all together into a distillation of a message. And even that’s like, that’s a lot of power, I think. And what do you take away from all these different opinions that all these leaders had, and how do you push that, push the project forward from there? So that’s 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 synthesis, too, of figuring out all these different disparate parts and 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 literature classes almost, where you’re doing literary commentary and you’re reading a William Yates poem and you’re trying to, 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 action that it’s capable of driving. And a lot of times that I often coach my product managers are on, we’re living in a world where everyone is constantly distracted, and you get these 30 seconds of attention at a time. And so, just the ability to really tell something powerful that sticks is really important, the memorability of it.

And I often talk about memification, which is this idea that I found this out most at Uber, I feel, where there’s certain insights, data insights, research insights that were memmified 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 the company and you compel action for it. Or when I’m being, maybe, asked questions by other leaders or stakeholders, the thing that’s going through my head is, okay, there’s this story that, that leader is trying to develop, or a meme about what this project is about or what the biggest problem is. And so, what story are they trying to create in their head so that they can remember or talk about what’s happened?

And if you take that mindset, you just realize that it’s a really useful way to think about everything.

Lenny: I’m really excited to chat about this idea because it comes up a lot. The power of storytelling, it’s similar to being good at vision. It’s like PMs are always told, “Hey, you got to improve in vision.” Here’s a skill the great PMs are really strong at. And I feel like storytelling is similar. It’s 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. Think of it as a meme, maybe.

Is there anything else? When you’re doing a performance review with a PM and 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?

Collaborating with Dylan Field

Yuhki Yamashita: Yeah, I think of it as 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 bare 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 reset moment, and to pull yourself out helps you tell a better story, in many cases. So that’s one thing that comes to mind, yeah.

Navigating Failed Experiments and Setbacks

Lenny: Got it. So it’s escape 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.

Yuhki Yamashita: Yeah, I think another thing that where I learned storytelling is through teaching. So when I was a course assistant for a computer science class and I had to explain pointers, you’re like, okay, I really have to borrow on real world metaphors or something that is much more grounding because if you assume a lot of knowledge, then 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 learn that skill of being able to tell anyone who has no context, then it becomes much easier to turn to these other audiences that are closer and closer.

Secrets to Building High-Quality Software

Lenny: When I asked you in our newsletter interview what one of the core philosophies of product managers is, in 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 at Figma.

Yuhki Yamashita: I really can’t remember why I heard this, but it really stuck with me because oftentimes, there’s this debate about well, is a PM the 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, your customers come up with a ton of different ideas and certainly, the what and 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 early in my career, so I was just really focused on my, what we called, our feature crew, our engineer designer, our tester, and just writing specs that really specified exactly how everything works. And so that was the Microsoft culture back then, and your specs had to be perfect, right?

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. Made is an error handling situation, and in Microsoft culture, you would’ve had a table that specifies exactly what happens during that error. But in Google culture, it’s like, okay, well the engineers and designers, they can figure it out.

So then it’s like, how do they make a really great decision? How do they make all these local decisions that you’re not a part of, how do you make it so that a great decision’s 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 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, our engineering team at Figma, whenever we do a retro or postmortem, we do this thing called five why’s. And it’s the idea behind it, it’s like, well, why did this happen, outage happen, okay, and why did that thing happen? And go deep enough where you can find the root cause and go fix all those things.

And I think a PM can do this, too, which is a customer is asking for a feature, but then you would say, okay, why are they asking for it, and back up the problem. But I think there’s one more step you can take, which is, why do they have that problem in the first place? And maybe there’s something there, and that could be an opportunity to make a bigger product impact by fixing that underlying condition that created the problem in the first place.

Making the Product a Daily Habit

Lenny: 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 post-mortems, you said?

Yuhki Yamashita: Yes. Engineering team that’s accepting them, yeah.

Lenny: That’s so interesting. Can you talk a bit more about these postmortems? Is this just when something goes wrong or is this just every project you retrospective postmortem thing?

Yuhki Yamashita: As it relates to five whys, it’s more when something went wrong. But I do think we have a retro culture, [inaudible 00:22:24], 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, so.

Lenny: Cool. Okay.

Yuhki Yamashita: Yeah.

Lenny: 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 a proximity to customers, that you make sure your PMs and product team are really close to customers. When you hear that, you’re just, 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, wow, this is how close we are to customers and maybe something that emerged out of that, that’d be really cool to hear.

Yuhki Yamashita: Well, I think a lot of it starts with our origin story in many ways, which is that way back when, when Dylan, the small group of people were building Figma, this is the time when no one believed 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 a tentative 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 where a lot of how Figma came to be and why we have such a strong connection with our community where we’ve actually, they’ve really helped shape the product to date, and there’s a deep belief in that, and they’re the ones in that are now advocating for Figma and helping us spread within the community and within their company.

So that’s the backdrop for why we have such a strong connection with our customers, and there’s a lot of things that you see. So for example, maybe someone on my team Sho, and oftentimes, Sho will tweet out to the community, here’s what we’re thinking, or we’re actually thinking about focusing a lot more in prototyping. What are the top problems you’re seeing? And people come back with all these different answers because everyone’s passionate. And we 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 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 Dylan’s always reading customer feedback. In fact, has reads the most customer feedback of all of us and has been doing that for a decade. And oftentimes, 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 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 intervened. We created this new channel, private channel called Concerning Tweets, and it just, we’re this small group of us that Dylan can drop us in. And these are tweets that aren’t going viral, by any means. They’re just things that you see is with one like, sometimes zero likes, but he feels there’s an essence of truth to them and we make sure that we look at what’s going on there and see if there isn’t something much bigger that we should be focusing on. But that’s the extent to which someone like Dylan, from top down, implements this idea that we need to be staying close to what our users are saying.

Lenny: That’s an awesome idea for a channel, a way to 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 an approach there? Just deciding what’s worth paying attention to?

Yuhki Yamashita: As we built out our research and data functions, it’s really important to balance out the vocal minority with what’s actually happening. So I really view some of those tweets more as canaries in the coal mine, in a way, and inputs into, many inputs we have around everything our customers could possibly be experiencing. And it’s important to realize that 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 sales conversations with prospects, 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 know that you don’t have any blind spots. So I think that’s one of the things that I focused a lot on when I came in, which is the Figma team is very good at Twitter and staying on top of the sentiments. And luckily for us, a lot of designers are on Twitter, but the reality is that most of our audience, at this point, probably aren’t. And so building our capabilities to extract feedback or more insight from those other sources, as well.

Lenny: That reminds me, I think Twitter was really instrumental to the beginnings of Figma. I believe Dylan made this social graph of the most influential designers on Twitter, and that was 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?

Yuhki Yamashita: Yeah, that sounds right to me. And he is very intentional about which designers we need to win over. I think it was very novel at time.

Lenny: What is it like to work with Dylan Field? As an outsider, he’s a legend, feels like he’s an incredibly smart, talented, hardworking, CO. There’s always tension a little bit between a Chief Product Officer and a CO, and so I’m just curious, what do you like to work with as a product leader? And then, is there, I don’t know, a memory that comes to mind of just a way that encapsulates what it’s like to work with Dylan?

Yuhki Yamashita: We’re very different, actually. And Dylan is very, he’s very based on intuition and instinct. And that intuition is actually built off of thousands and hundreds of thousands of customer interactions where he might look at something and be like, “You know what? This isn’t going to land well,” or, “Here’s the biggest problem right now.” And you’re like, well, how does it conclude that? And part of my job is to build out that logic streak for him of how did you arrive at that conclusion so that people can understand that at scale, in a way. But he’s very much about that.

Or I think there’s a way which, sometimes, it’s a product manager, you want to lay out a problem and say, okay, we’re going to first focus on this problem, and then [inaudible 00:29:21] 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 fully get bought into it until he sees the end implementation to viscerally feel if this is a good solution or not. And so I think that’s the kind of thinker he is where he really needs to see it to feel it. But it’s not totally random. It’s based on all these interactions with customers and somehow encoded in him to build up some of those intuitions.

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. I remember when, during the height of the pandemic, we were doing a one-on-one walking around Delores Park, because this is the era where you would take meetings, if you take meetings, they’re all outside, and then he needed to use the bathroom. So he came out to my house in the Castro, he used the bathroom, and then he met my partner, and my partner was on Figma, had Figma pulled up because he is just doing work. And then Dylan just went straight in there and wanted to ask what the biggest problems were or what’s not working, and they started geeking out on some issue around Google fonts, and this is the first major interaction between the two of them.

But it’s one of those things where that’s how much Dylan cares. And on one level it’s just easy to say, “Hey, this is a single user who just happens to be using your product,” and be dismissive with it or not care that deeply because you think you already know all the biggest problems, but that’s not his attitude. And so that’s the level of, I guess, customer obsession, if you will, that he exhibits and then, in turn, informs his intuitions.

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

Yuhki Yamashita: Yeah.

Lenny: Hey, Ashley, Head of Marketing at Flatfile, how many B2B SaaS companies would you estimate need to import CSP files from their customers?

Taking Personal Responsibility for End Users

Ashley: At least 40%.

Bottom-Up Fixes vs. OKR Conflicts

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

Ashley: 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 CSP importer doesn’t work right, which is super common, considering a customer files are chalk full of unexpected data and formatting, they’ll leave.

Lenny: I am 0% surprised to hear that. I’ve consistently seen that improving onboarding is one of the highest leverage opportunities for both signup conversion and increasing long-term retention. Getting people to your a-ha moment more quickly and reliably is so incredibly important.

Ashley: 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 Wallace data onboarding acts like a catalyst to get them and their customers where they need to go faster.

Lenny:

As an outsider, it feels like Figma is just always firing in all cylinders, shipping the best product. People love it. I use it, I should’ve mentioned this, but I use it probably every day for my newsletter for illustrations and banners and all this stuff. Yeah, I don’t know what I do without it. And it always feels like Figma is 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, a launch, or something like that that just shows people that it’s, not everything always works out.

Love-Hate Relationship: Core Experience and OKRs

Yuhki Yamashita: We run experiments all the time that don’t come back with winning results, 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 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, just didn’t really see that much adoption and didn’t feel great because it’s 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, 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 dogs looting, 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 needing to push ourselves and build that muscle, as well.

Lenny: Speaking of high quality software, again, I’ll repeat, I think Figma is one of the most beloved software products. It’s 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 is maybe 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?

Three Criteria for Great OKRs

Yuhki Yamashita: 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 the, internally within Figma, are the most vocal and the ones who are in the product six hours a day, essentially. But even for PMs, one of the first things I did 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 we can build those decks in Figma, and just that act alone allows you to 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 creative to enable your company, your entire company to use a product more. Or as an example, recently, we just did calibrations for performance reviews in FigJam, and our Head of Design, Noah, 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, just naturally becomes better. Because a lot of times, it’s not just about people raising their hands and saying this is the problem, it’s more about you just want to make your own workflows, your own day-to-day better, and derive satisfaction from improving that.

Fostering a Culture of Experimentation

Lenny: 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. I know you mentioned in our newsletter interview that you switch from memos to decks. Usually, it goes the other way around, and now I get the second order effects of that where people are building their decks in Figma. That is very clever, and 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 in making it, just continuing to just be obsessed with making a great experience combined with that, people using the product and this trickle down of we really need to make this as awesome as possible.

Ashley: There are other companies, for example, when I was at Uber, especially working on the driver’s side, of course we went out and driving, and that speaks to some aspects of it. But one of the things that I’ve realized is when you are logging a bug and you 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, and if an engineer working a driver app saw a driver struggling with something, they would find it embarrassing and feel personally accountable to go and fix that. And when you can create that sense of personal accountability, then all these crazy things happen and all this progress happens. So I think for us, as getting creative at Uber about, okay, well how do we increase those interaction points at the point where, if someone building feels like they have some kind of personal relationship with the end user, and this is what happens, at Figma, too, where a lot of our designers feel personally accountable, in a way, because all their customers are people they already know in the community 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 personal accountability can really make a difference.

Lenny: That begs a 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 got 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 a two part question, just like you have a approach to that, do you encourage engineers, designers just fix stuff that seems broken/you mentioned that you have a fun experience with OKRs and how you’ve approached OKRs at Figma, and you’ve gone back and forth a little bit. And so maybe, as a second part, just talking about your experience with OKRs at Figma.

Core Traits When Hiring PMs

Yuhki Yamashita: The first part, I would say that I think one of the most powerful things, especially for startups, is that bottoms up energy, 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 the company is 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, 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, 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. And that motivation is so different.

And that’s why getting the buy-in of developers is really important, because you want to feel like they’re personally vested in this problem, and then, all of a sudden, their willingness or their creativity, or all these things spike. And so when you think about all those things, when there’s a situation where an engineer or a designer’s trying to fix a real custom problem, I’m like, by all means.So that’s on that.

OKR is totally bigger topic, and maybe I’ll set the conflicts of why I have such this love-hate relationship with it, which is that a lot of my career, I’ve actually just worked on core experiences, and OKRs were the bane of my existence, in a way. Because when you’re working on a core experience, sometimes you’re just, 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, anyway. So it just seems very performative, and there’s just a lot of work that goes into it.

And you 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 satisfaction metric that you have on some survey, but you haven’t actually done the work to show that, that actually has correlations with retention or anything that actually “matters for real” in the business, or it’s some weird usage metric or something like that.

And then the other extreme is to say, no, we’re going to be ambitious and we’re going to send it for business goals. So for example, 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. And I think the reality for a lot of that is, it’s a metric that you don’t have full control over or there are many hops until it can affect it, and okay, well maybe we can make the experience better and maybe that improves your attention and maybe this. And by the time you get there, you actually can’t even prove that you moved the top level metrics. So either you anchor something that matters, but you can’t move, or you anchor something that you can’t move but doesn’t actually matter. So that’s the relationship I’ve had with [inaudible 00:42:45], so even it’s really frustrating.

So when I write that thinking about, one of the things I realized is that we had OKRs, but people were treating it almost as a to-do list or a task list of, okay, here’s how, by the end of quarter, I need to complete these tasks and then I’ll 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 got to this point where we had all these, and this is similar to the secondary metric problem, but either you couldn’t approve that you actually moved it, or you’re trying to work on something that I don’t actually understand why it’s useful.

And so that was when I deprecated it and said, “I just want to understand your headline. What are you trying to do, philosophically?” And just don’t stress about whether you can measure it or not. I just don’t understand what you’re optimizing for, and let’s first have that to date. 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’s qualitative, so it’s quantitative, and that’s fine. And I almost feel like sometimes, it’s better to take the report card approach of saying, Hey, just give yourself a score, tell me how you derive that score, let’s all understand that the metrics and those inputs that go into it can change over time, and we’re going to get more sophisticated about how we measure it. But at least everyone understands what on earth you’re trying to go for.

So that’s 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, 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 I 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 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 feel like these post-rationalizations of the projects that you’re working on, anyway.

And at the end the quarter, you come back and see if those OKRs move, fingers crossed. But if you stop an engineer in the middle of the hallway or the virtual hallway, so to speak, and ask them, okay, what are your team’s biggest goals or OKRs? [inaudible 00:45:31], they wouldn’t be able to say it. They’re just like, well, I’m working on this project that’s really important. And so it’s, well, what’s the point of publishing this OKR if you’re actually not thinking about moving it on a daily basis almost, right?

And so that’s when we’ve tried to experiment with this terminology, well, maybe if we should call it commitments instead, people would take it a little bit more seriously. And it’s my belief that oftentimes, commitments are this care between the why and the what, and sometimes the face of the commitment is the what.

It’s a project and there are many why’s behind it, or it’s the why and there are many projects behind it. So that what’s trying to formalize that idea, but it definitely felt a little bit complicated, a little bit. Sometimes people are like, well, OKRs exist for a reason and this is, basically, an OKR with just a different name. So my honest sense is we still haven’t figured it out and we’re still iterating on a bunch of different things, but I think I’ve developed some philosophies around it, which is, no matter what you call it, because it doesn’t matter as much.

I think that, for me, there are three things that really matter about the 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’s stirs action, makes me want to do something differently. And the third one is authenticity, which is, does this actually, honestly depict what you’re doing, what you’re trying to do on a day-to-day basis? Because if it doesn’t, then 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 I question the value of it all.

So that’s why I am in the process. But I definitely am all ears to advice around this kind of stuff, because I feel like we haven’t quite cracked the code.

Lenny: I love hearing that. That ,hole 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, and no more specific goal metrics. We’re just going to build things that we think are important.

And in the newsletter post, for folks that are listening, you actually show the templates that you’re using these days for planning your projects and 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, maybe, other folks aren’t as focused on, and just what does the interview process look like at Figma?

Effective Collaboration with Sales Teams

Yuhki Yamashita: Yeah, I shared some of these things. I really feel passionately about storytelling, and 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 controversial product decision, and what did you do,” and all those things. And I think it’s really revealing because if they can set up this conflict and understand why this problem was really important and represent both sides in such that you can understand why that conflict existed in the first place, then they can do it in this even-keeled way, where you realize that they can take on these different perspectives. You start to learn a lot about that person, I think.

Or sometimes, I just ask them for basic things, okay, talk about a big problem that you worked on. And the thought experiment, for me, is always coming out of that, do I feel compelled to work on that problem? And no matter how boring it sounds on the surface, I think a really great product manager can cash something, it’s like, well, this is why it’s so existential for us, and this why it’s so interesting, and really rally the troops up. So that’s one big thing of storytelling communication because at the end of the day, so much of our job, it’s around that.

I think other than that, some of the things that I value or things I think about as, hi Dan with UX conversations, it’s like we talk about problem, and I think about when you’re exploring solutions, it’s this tree of, okay, there’s just these branches of explorations and you finally arrive at these solutions. And 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, feel like we walk away with some progress.

And I think that at Uber, our first two Product Officer, Jeff Holden, was someone who often talked about 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 PMs who have the ability to imagine those outcomes, I think, it helps us be much more efficient, too, because we’re like, well, if we all think that it’s going to go there and that’s not going to compel us to take any action, why do it at all?

And so I think a lot of PM is about those 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 all only possible if you can have that kind of imagination or that ability to see around corners.

Lenny: 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 whenever people talk about product led growth, they’re always companies like Figma, Slack… Figma is always seen as a model of product led growth 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.

Keys to Figma’s Early Growth

Yuhki Yamashita: We’re really lucky to have a sales team that understands their 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 we all are collectively realizing is, we talk about product like growth, but in some ways, I like to think about it more as community led growth or there are certain people inside a company that feel so strongly about Figma and that they’re helping push for it in these advocates and evangelizing for Figma.

And so oftentimes, what the sales team does is really empower those individuals to make a stronger case or connect them to the rest of the company so that we can get a wider deployment or more leadership buying and things like that. And so oftentimes, a sales team is playing that role of creating those human connections and helping equip designers that feel passionately inside a company with the data, with the stories and all those things to help make a case. And I think that’s the most powerful way in which we can spread where the space of Figma is not the sales team, but in fact, it’s the internal designer.

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

Advice for Product-Led Growth Founders

Lenny: That is really interesting. Basically, making your champion inside the company 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 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 what do you think people often miss and what do you think Figma did right that got it going?

Yuhki Yamashita: 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. And one of the nice things about Figma is you can 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 at so X, Y, Z 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 in how other companies work, that’s where there’s a lot of interest.

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 passing about Figma, and all our different geographies come together in a Discord channel. They meet regularly and are helping us evangelize. And again, that’s that human connection between users, and then between us and the users is something that really helps build that kind of loyalty, which is the thing that, then, fuels all the champions to really push for it, internally, and give people the enthusiasm and courage to do that inside their organization.

Thoughts on the Adobe Acquisition

Lenny: 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 use their community to help jumpstart growth and continue to grow.

The Continuous Evolution of Product Philosophy

Yuhki Yamashita: Totally.

Lightning Round Q&A

Lenny: It’s interesting that you can call that community growth, product growth. There’s a lot of overlap there, potentially.

Yuhki Yamashita: For sure.

Top Recommended Daily Tools

Lenny: What advice would you have for folks that are, I don’t know, maybe you already shared this, but just 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?

Yuhki Yamashita: Maybe a different way to talk about what we just talked about, is just, there has to be this, almost irrational, this emotional response to your product and this like love for it. First, it has to be cultivated internally, too. People, internally, have to authentically love something to really stand behind it. But then, externally, too, if people are loving something to the point where they can sing at the top of their lungs and just really talk about how Figma’s, great, if we can get there, that’s a wonderful place to be.

And I think that’s both a combination of you’ve really solved their problems well, but you also equip people with a philosophy around a different way of working. And I think that’s what worked well for Figma, too, which is, 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 [inaudible 00:57:51] Figma was, if this is a future of design, I’m quitting. I’m changing careers. And there’s that tension of that narrative tension, but that is signal that you’re part of this revolution and you’re trying to change something. And when it can equips your customers or user base with that, and 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 or [inaudible 00:58:23] come up with that. But hopefully, if your a founder, you’re working on something, your mission is so big that you have those kind of ideas, and it’s how do you actually equip your customers to want to talk about that?

Conclusion and Final Thoughts

Lenny: That’s awesome. Reminds me of a quote and 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.

Yuhki Yamashita: I love that.

Lenny: 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?

Yuhki Yamashita: Totally. Yeah. As you said, it hasn’t closed, yet, and so we’re still independent companies, but when we think about that theoretical future, I think about people often ask me, so what’s going to happen, in terms of the products that you work on, and how is that going to influence Figma? And the answer is, we don’t know, yet, but I get excited about two avenues. One is just 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. And maybe you’re creating that micro interaction in After Effects, or maybe you’re doing that intricate illustration in Illustrator, or editing Raster in Photoshop, and then you’re bringing some of those things into Figma. But when you think about the 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 maybe you 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 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, we’ve figured out something really interesting in the form of realtime multiplayer collaboration, and that, as a platform. Adobe has a much broader set of use cases that they’ve been pursuing, and what do those two things together, what could that enable? 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, okay, if we can bring in the power of the browser, of multiplayer, of this feeling of 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 go through my heads, in terms of what’s possible. In terms of what I don’t want change. I really think that we’ve figured out something really amazing, in terms of our relationship with the community. We talked about proximity to community and our users. Those are things that 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, I think, I will continue to do and that’s what I draw a lot of motivation from in the first place.

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

Yuhki Yamashita: That’ll be awesome.

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

Yuhki Yamashita: It’s really easy to listen to some of these podcasts and feel like, oh, these people have kind of figured everything out.

But the reality is, we haven’t, and we’re still experimenting with a lot of things. OKRs is a really good example of that, but a lot of other things. And so, just the other day I wrote about this idea of us living in a work in progress world, and I was talking about more from the context of we live in a world where all of our products, our product players, our strategies are work in progress, and how do you work in a world like that, when what you’re reviewing can change the next day.

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 you have so much to learn from each other. And I’d love to continue to learn more from all of you on interesting ways that you grapple with these age old problems around things like how to set goals, or how to review work, or how to plan.

So anyway, just wanted to signal that we are very far from perfect, and I really eager to learn from everyone else, as well.

Lenny: 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 are taught that everything around you is designed by someone. Someone just decided this webcam’s 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 assume the things that we are working within are just, they’re figured out. Someone much smarter than me figure 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.

Yuhki Yamashita: Yep.

Lenny: 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 them pretty quick, whatever comes to mind, share, and we’ll see how it all goes. Sound good? All right.

Yuhki Yamashita: Sounds great.

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

Yuhki Yamashita: First one that comes to mind is Switch, and it’s really about how to affect organizational change, something that’s Shishir recommended to me and we have the difficulty of 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. And it’s thousands of pages. It all takes place in a garden, but it’s one of the most beautiful piece of work I’ve read, so I like to recommend that, even though it’s nothing to do with PM.

Lenny: Did you say thousands of pages?

Yuhki Yamashita: Yeah.

Lenny: 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?

Yuhki Yamashita: Well, I’ll have to admit, I’m actually much more of a visual learner, not a listener, and so I rarely listen to podcasts, but the two that I have listened to, in earnest, was first one was Cereal a long time ago, and then yours.

So I think some of the best, actually, but otherwise, more into reading.

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

Yuhki Yamashita: The last movie I watched was called The Good Nurse, and it was about 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 was talking about how broken our system was. So, highly recommend it. Quite sad, but yeah.

Lenny: 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?

Yuhki Yamashita: Kind of cheating, but as I mentioned earlier, we’re starting to use FigJam 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 we have our usual suspects like Slack and Asana, and then we’re all over the place on the rest. Some of us use Notions, some of these use Dropbox Paper, some of these uses Koda, and so we’re still figuring that one, out, I’d say.

Lenny: Dropbox Paper. Very cool.

Yuhki Yamashita: Yeah.

Lenny: 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 plugin or template?

Yuhki Yamashita: 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, 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 on a pulse check, we drop it in and we’re like, how are people feeling aligned, not aligned?

And if people are aligned, we just move on. If not, then you know that it’s worth a discussion. So it’s just a fast way to figure out where all the hotspots are.

Lenny: 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 template, so you can plug that right in.

Yuhki, 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?

Yuhki Yamashita: Yes, you can find me online on Twitter or LinkedIn. Feel free to reach out there.

In terms of how you can be useful to us? We’re really starting to build a lot of products for this audience, for product managers. FigJam is one example of this, so definitely try it out, give us the 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 or are interested, yeah, there’s a lot of roles, so please get in touch.

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

Yuhki Yamashita: Thank you so much for having me, Lenny.

Lenny: Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcast, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving 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.

Glossary

English	中文
Alignment Scale	对齐标尺
branching and merging	分支与合并
Camille	Camille
canaries in the coal mine	煤矿里的金丝雀
Chris	Chris
CO	CO
Concerning Tweets	Concerning Tweets
CPO	首席产品官
CTO	CTO
dogs looting	dogs looting
Dylan	Dylan
Dylan Field	Dylan Field
five why’s	五个为什么
frameworks	框架
impact	影响力
Jeff Holden	Jeff Holden
Lenny	Lenny
memification	梗化
micro interactions	微交互
micro mobility	微出行
onboarding funnel	新手引导漏斗
postmortem	事后复盘
product led growth	产品驱动增长
realtime multiplayer collaboration	实时多人协作
Scott Delski	Scott Delski
Shishir	Shishir
Sho	Sho
single source of truth	单一事实来源
social graph	社交图谱
storytelling	故事讲述
Switch	Switch
synthesis	综合
The Story of the Stone	The Story of the Stone
work in progress	进行中
Yuhki Yamashita	Yuhki Yamashita

---

Reformatted by reformat_english.py