
Yuhki Yamashita is the Chief Product Officer at Figma, where he leads the development of one of the world’s most beloved design platforms. Previously, he was Head of Product at Uber, overseeing the core rider experience used by millions globally. A...
Loading summary
Harry Stebbings
This is 20 product with me, Harry Stebbings now 20 product steps inside the world of the incredible product leaders leading some of the best product teams today. Joining me in the hot seat we have Yuki Yamashita, Chief Product Officer at Figma where he leads the development of one of the world's most beloved design platforms. Previously he was Head of Product at Uber, overseeing the core rider experience used by millions globally. Yuki is a master of product storytelling and team building. He's redefined how world class digital products are built and scaled and I couldn't more excited to have him in the studio in London today. But before we dive into the show today, are you struggling to beat model benchmarks or implement Gen AI in your product? If so, you need Turing. Turing is an AGI infrastructure company backed by incredible investors like Foundation Capital and Westbridge Capital and they do two things. Number one, they help leading companies in AI labs like Salesforce, Anthropic and Meta enhance their LLMs with advanced reasoning, coding, multilinguality, multimodality and more. Two, they combine human and artificial intelligence expertise to deploy cutting edge AI systems for awesome companies like Rivian and Reddit. Right now, Turing offers a free 5 minute self assessment to help you pinpoint your place in the Gen AI journey, get tailored next steps to optimize your model strategy and then finally learn how Turing can refine and implement your models for better performance. Take the guesswork out of Gen AI. Visit turing.com 20vc to start your free assessment today and once your Gen AI strategy is on point with Turing. Now let's switch gears to the future of mobile and how one company is turning your screen into real returns. We spend nearly half our waking hours glued to our phones, upwards of 50 hours every week. Recently, one company transforming this reality stood out so much I personally became a shareholder. Mode Mobile Mode Mobile created the EarnPhone, the smartphone that pays you for daily activities instead of big tech. Profiting billions from our attention, Mode returns over $325 million directly to users through earnings and savings. Mode's revenues surged an incredible 32,481% in three years, recognized by Deloitte as 2023's fastest growing software company in North America. And here's why I'm excited. MOAD's equity offerings have raised over $30 million from 20,000 plus retail investors, one of 2025's standout public raises. And you can now join me as a shareholder with as little as 1000 do invest.modemobile.com 20VC for a limited time unlock up to 100% bonus shares and a free earn phone. Email us for the investor brief at 20vcodemobile.com or check out invest.modemobile.com20VC we've talked about making money from your phone. Now let's talk about making your product do exactly what you want it to. Whether it's the software you build or the software you buy. Your tech stack should be creating results, not creating roadblocks. Pendo's no Code Software Experience Management platform makes your software better with tools to see where users get stuck. Guide them with in app messaging and constantly improving your UI. It's so easy that over 14,000 businesses use Pendo to increase revenue, lower costs and reduce risks. Businesses love the control. Engineers love the freedom. Everyone wins. Start for free today at Pendo iO20 product. You have now arrived at your destination.
Yuki Yamashita
Yuki I'm so excited for this dude. We first met in Covid at like a linktree panel event. I've been looking forward to this for a while, so thank you for joining me in person.
Thanks for having me.
Harry Stebbings
Not at all. But we were just talking a little.
Yuki Yamashita
Bit about your upbringing and you said I moved a lot and mentioned Tokyo and some other areas where you spent time in your childhood. I want to start with how did moving a lot impact how you think about product and design today?
Yeah, I think moving a lot in retrospect caused me to As a young kid, you just want to fit in, right? And you make a lot of friends. But you have to abandon your friends and move to a new place, learn a new culture. And as part of that, I felt like I needed to just abandon all of my assumptions about how things work. Like some basics, like in Singapore, you hold the spoon and fork differently from the Philippines or something and just those little things. And so it causes you to just question every assumption you have to some extent. And I think that helped me with putting myself in other people's shoes, building some basic user empathy. I think those are core tenets of design.
I just ask continuously unfair questions and if you don't like them, we can edit them out.
No, go for it.
What design assumption do you think we question that we shouldn't question?
I think we should always be questioning everything. I think a designer's job is to always ask what if?
For me, it's like, you know, simple is always better. Is it? We should question that assumption. And to what extent does simple is always better become lazy versus feature creep?
I see. That's a good one. Dylan does always say simple is better so there is truth to that. But simplicity is a perception, so it's not necessarily a reality. If you take simple is always better to an extreme, you might not add new features, you might not add new capabilities, and I don't think that's always the right thing to do.
When you think about that, simple is better, but then adding new features, the most difficult thing I think from an outsider building product is how do you cater to super users who just want the most advanced features, but then also engage an audience that needs quite basic features, quite a lot of hand holding without alienating either world, right?
No, it's really hard. I think very few products have been able to evolve in that way to some extent. I think at Figma we try to think about it in terms of offering people different modalities, allowing them to be in the same artifact together while using different lenses. So for example, we have a product that we just launched, Figma Buzz, that has Design mode, which is kind of like expert mode, hard mode, and has all the things that designers know about layouts and variables and design systems, things that are a little bit foreign to non designers. But then we have just the regular mode where people can come in and it's just a very simple editor where they can edit content in ways that they expect. And having kind of that duality and giving people different lenses into the same surface has been one way for us to preserve that simplicity for one side, but the need for power on the other.
You said there about the new product Design Mode.
So Design Mode is a feature within our products. So Figma Buzz is one of our new products for marketers. Figma Slides also has Design mode. It looks like any other Slides product regularly, but you can flip on Design Mode and get access to all the features that you expect from Figma Design.
How do you determine which new categories? I love it. This schedule is beautiful, but fuck it. How do you determine which new categories to go into versus which to leave? You could look at Figma Slides and go pitch or Canva or whoever do that pretty well. It's not really our bread and butter versus we want to be there. How do you think about that product decision?
Well, one of my product mentors, his name is Shiva Rajamaran, he was my manager at YouTube and has gone on to do a lot of amazing things. And he talks about how it's important to observe how people hack your product. You know, use that as inspiration because that's real signal, right? They're going out of their way to demonstrate to you that they have A need even though you're not delivering on it. And so for us, a lot of our new products are a function of that. You know, back in the pandemic, people were using figma design as a space to hang out during quarantine. And that motivated us to think about building a space for them, which is FigJam, our brainstorming tool, and slides two. Before our slides product, 3.5 million decks are being made in Figma design. Even though it wasn't intended for it, for us, that was motivation. So I think those are the kind of ways that we can easily prioritize because we know that demand is already there.
Can you take me inside? What happens next in this magical product machine of figma, which is, we see that someone's hacking it, they're creating three and a half million slides, someone brings it to a meeting and says, hey, I think we should create this product. What does the product process look like?
Yeah, I would say in the case of some of these products we just talked about, there's usually a group of people inside Figma, we call them Figmates, who just get super passionate about it. And maybe they wait for our maker week, which is an equivalent of a hack week, essentially, to build out a proof of concept, to make a pitch. And I think, at least in our culture, building something tangible that people can use convinces people more that this idea is tenable. It's actually simpler than we imagined. And that usually is what kind of propels that project into getting on the roadmap or at least being considered.
How often is make a week?
Once a year? Sometimes they've had it twice a year.
Do you want to, in a world that's more fast moving than ever, encourage people to hack on side projects more than ever before?
Well, I think it's really important right now for every product team to think about how to prototype and play with new capabilities, because everything is so fast moving. So programs like MakerWeek help, but I think it's a core capability that we all need to learn.
I completely agree with you. People are inspired more by a build and feeling something more tangible. What happens then? We've got three Figmates and they've been inspired by something, they've built an early version. What happens then?
Well, usually there is kind of a moment where there's a pitch, right? A product review of sorts of. Oftentimes it's nice to pair it with. Okay, well, what makes it differentiated? What is the messaging that will go alongside it? How do we tell the story around it? Because, okay, is it Any old Slides product, or is there something special about it, or why is it uniquely. Figma is a big part of that. And then the second is laddering up to our goals, right? In our case, we're in the business of helping teams build products, even something like Slides. There are a lot of use cases around that for product teams, and how do we bring those to life? And why is that better than another Slides product?
For example, as a podcaster, I make bombastic statements and expect you to probably neutralize them a little bit. Are PRDs dead? People today say, in a world of such agility, PRDs don't need them anymore. Are PRDs dead? And how does how we use them change?
They are in the form that you might be imagining could be dead, which is this very dense spec that's intended to be implemented. I remember when I was just out of college In Microsoft, our PRDs would be 20 pages long with tables of edge cases, and if there was a mistake in the prd, there was a whole process called a design change request that you had to make as kind of like a punishment.
It feels like an advert for Grammarly.
So things of that form, I think are probably outdated even at Microsoft at this point. But a centralized place where you're like, this is the goal, or this is what we're trying to do, or some source of truth where people can go back and say, well, I'm trying to make a decision right here, and I want to know whether I'm making the right decision. Something that articulates that North Star is still important to ground everyone.
Can different products have different North Stars within the same business? Does it have to unite?
I think about it as in our product teams, for example, one of the things that we like to do with goals is do what we call KPI Trees. So KPI Trees is something that I learned actually at Uber, where you say, okay, you have this metric, but what does it ladder up to? And sometimes it ladders up via math, and other times it ladders up via assumptions. So, for example, you might be a team focused on customer satisfaction. And there's an assumption that eventually it ladders up to engagement in their 4 weekly active users. But at the end of the day at Uber, at the very top was trips. Everything cascaded from there. So I think that while it's possible for everyone to be indexed on a different kind of part of that tree, someone should be doing the thinking to make sure that it's all laddering up.
You mentioned story and messaging there as part of that what product messaging story are you most proud of from Figma or Uber, and what did you do?
Well, from it, the best stories, you can kind of look at something and it instantly tells its own story. So for example, I like to think about the screenshot test, which is you have one screenshot, maybe it can be allowed to be a GIF, maybe, but where without any caption, you just understand immediately the value of it. Back from Uber, I was working on a redesign of our rider app going into upfront pricing. So the fact that there's times and real prices on the home screen, that was very self evident what this whole redesign was about. And I think all too often people end up kind of having to walk people through, okay, this tutorial of like, let me just explain to you why this product is better. And to me that's not just a story, it's also kind of a constraint in the design. Like you're maybe not pushing it hard enough for it to be self evident, how to use it or why it could be valuable.
I'm just imagining a lot of founders listening, going, but my product's too complex, I could never do that. Is that because there are some products that are just too complex or is that an element of bad design?
I would say that for your audience, there should be some moment where you're kind of, you look at it, you're like, oh my gosh, that's amazing. Right? And as I said, it could be a GIF or something that's if you need condense a few steps into it. But if there's a moment where you have to say, hey, let me stop and explain, or let me do three tool tips to explain, it's a little bit suspect, I would say.
So we have that beautiful picture screenshot hopefully, or gif and we have this kind of pitch moment. What does that pitch moment look like and how do you think about that decision making on whether to go or not?
Yeah, every product has some magic to it, right? Every company talks about magic in some kind of way. I think there's a visceral reaction. When you see something that feels special, that feels unique, that's usually a very good indication that something is right here. And if that doesn't exist, to kind of keep pushing on that until it does, or maybe say not now. But that's something that I very much look for.
What new product pitch that you had within Figma did everyone find was the most special and was that unanimous or have there been wildly disparate views on what people have liked in the pitch process.
Well, I'm thinking to a recent one. We introduced this feature called Code Layers and at the time the internal product name was called Living Designs. And it was this idea that you could have the static design that you just drew and then hit a button, it transforms it into code and you can start kind of augmenting it with code via prompts. In that moment, I remember it was a Maker Week project. Everyone's like, wow. All of a sudden all these things that were impossible to do within Figma design became possible via the power of code, but based off of the design that you just drew. So it's almost as if the design came alive. That was like a big zoom chat moment. Everyone's like, whoa.
I think about entry points a lot as an investor. Often you lose because you get the wrong entry point. You have the right idea, the right solution, but the wrong entry point. When you think about the entry point for building in the future, you mentioned that turning design into live code and then you've got another element which is just kind of build in real time, which is your bolts, it's your lovables. But you don't necessarily start with pure design, you kind of build on the fly. How do you think about the future in terms of entry points in that way?
The future has to be one where there are many entry points because building a product is just necessarily this very complex multifaceted thing. And we like to talk about our North Star's. How do we go from an idea to a final product in users hands as quickly as possible. And in some cases people have only conceptualized the idea as a phrase. And so by all means start there. Right. But for many others they've already started sketching it out in some way because words aren't sufficient to convey the concept. Or there's something about the essence of the design that they want to communicate or convey first. Designers are very visual people. They're people who. These are the people who go to a whiteboard and start drawing before writing a single word down. And then there are developers who might have an existing code base and they have an idea based off of that and you want to allow them to design a concept.
Do you think the world separates into your professional and amateur and it's the pros will use Figma and use design first and the amateur will build on the fly with your lovables or bolts?
Well, certainly, while it's definitely the case that Figma has traditionally been a little bit more professional, certainly our aspiration is that anyone can arrive to figma and feel like they can get started. One of the motivations for building a product like Figma make, for example, was allowing someone who just has a concept with words to get started and then iterate, whether with the help of their teammates or by themselves, on that output.
When we go to that decision, what was the most controversial new product decision that you remember within figma? Why was it controversial and how do you reflect on that?
Well, I think the biggest thing there was, for example, in Figma Make, Source of Truth is code. And we figure out how to take your design, translate it into code, and then let you iterate via code because code is so expressive and LLMs are fantastic at writing code. I think that was a big shift for us to some extent, just because to date, the Source of Truth had been a representation of our design. And now the two things aren't completely different, they're quite related. But I think that anchoring, especially for the Figma make product, felt different to.
Us, and people within the team were conflicting in terms of how they thought about it.
I don't know if conflicting, but it definitely felt new. It's like this is not what we maybe a couple years ago would have thought.
What happens in that situation when there is a disagreement or a. I'm not sure about this. How do you think about the green light versus the red light?
I think it really comes down to what do our users want, and in our case, our customers want the ability to be unconstrained by the tool that they're using and having the power of any medium to express themselves. And that's why I think our definition of design has almost expanded in the last couple years. Last year or so, where I say, hey, like design, you might think of as that thing of visual manipulation on a canvas drawing some mock, but actually just as valid is a bunch of iterations via prompting, or just as valid is writing some code, because maybe designing via coding is faster. And so if you start to take that worldview where we should allow you to design in any medium, any input method, at any point in the product development process, it starts to make sense that we have to introduce those capabilities into our platform.
You mentioned the expansive nature of design there, and also the unification of product and design in many ways. It feels like we're seeing the kind of collapsing of these different functional areas into all one superhuman. When we think about the future of product teams, how do you think about the structure of those teams given this unification? Blurring of lines?
This blurring of lines has been happening even before AI, like designers learning how to code or PMs learning a little bit of design. One of the reasons I joined FIGMA was precisely because the boundaries were being blurred. And I was always frustrated by that kind of arbitrary line that was drawn between say, a designer and pm, where I've played both roles before. And a lot of this has been happening because people are being pushed up the stack, right? Like engineers don't have to understand everything that's happening underneath the hood anymore. They're just using a bunch of powerful libraries and APIs and still being very productive designers. They're very rarely pushing pixels anymore. They're compositing things that already exist in their design systems and putting it together. And so you're operating at these higher and higher level abstractions, and as a result of that, you're kind of being all pushed towards a similar area where you can focus on the most strategic things, which is solving the problem or solving the user problem. And so I think it is true that naturally all these disciplines are, I don't know if converging is the word, but certainly kind of all moving up in some ways in terms of abstraction.
How does your team structure look today? You have a pod. What does that look like and what will that look like in five years?
It's a good question. Certainly because of the blurring of boundaries, it's possible, easy to imagine that they might collapse a little bit more into kind of generalist product building role with a few specialists always who can go deeper and go higher craft in their respective disciplines. But that being said, I will say that there is always something very healthy about a group of people who are pushing on different extremes. And so, for example, I'm remembering there was this time when we had an intern at FIGMA who was a design intern but wanted to try out pm. And so we're like, oh yeah, great, go PM and design this project. And they had a lot of difficulty because as soon as they put the PM hat on, they're just constraining themselves, getting super pragmatic and capping their ability to dream to some extent. And sometimes designers are just so focused on the end user and doing what's right for them over anything else. And they are the ones pushing for business constraints or technical constraints to be changed or removed. And that tension is what I think advances a product, right? And so I think people have to push on these things like advocate for the business, advocate for the user, advocate for technical feasibility. And they might not be expressed through these traditional rules like we know Today. But I think those extremes are almost necessary to create the best product.
So then when we go back to the pod, what do the pods look like today? What will they look like in five years?
Everyone should be designing in some capacity. And whether that's happening today or whether that's happening in the future, should everyone.
Be building in some capacity? If everyone should be designing, should everyone be building on the flip?
That's also possible. We're seeing more and more that a mock isn't sufficient to convince people you actually need a realistic prototype. You need to vet your ideas in that way. You need to validate it. So yes, it's true that some form of building is going to be important for everyone.
Forgive my blunt basicness, this is the challenge of speaking to a Lenny who actually understands product and speaking to a venture investor like me who tries to understand products. Very big difference. If you have a team of 10, what is that ratio split across product, eng design, PM today. And what does that look like in 10 years or 5 years?
Yeah, I mean today you typically see maybe 8 to 10 engineers PM and a designer or two. Right. That's kind of atypical. Pod depends on kind of the nature of your product.
And then in five years time, how do you think that goes?
Oh, see, you're in the business of making guesses like these. I would say that perhaps it would come down a little bit where more of each function or more of each consideration will be more equally represented. Because what is the point of leverage is really going to be figuring out what we're building, figuring out the user experience, and that's where the concentration of human attention is going to be.
So we have less engineers.
It's hard to say will Figma have.
More or less engineers in five years time?
I don't think we'll have fewer engineers than we have today, but I think we'll be able to do more than we're able to today. As we expand more products. I don't expect the number of engineers, for example, to grow in proportion.
How has the stack changed internally? Do you mandate cursor, Windsurf? How do you think about pushing your ENG team to be at the forefront?
They're exploring a lot of tools that are AI assisted code editors for sure.
Do you mandate any? Do you focus on one or two? We had Duolingo on the other day.
And they said, hey, everyone's on cursor, no mandate. I think we always just want to make sure that people are using the best tool possible. And as people discover differences, there's always a conversation.
Do you think these tools make normal engineers 10x engineers 1 or 10x engineers 1000x engineers? If you had to choose one.
I always like to go back to our own framework of how AI helps with design, which is that it does both lower the floor and raise the ceiling, which is that it makes in our case design, but in this case coding, more accessible and approachable to everyone. And so in that sense welcomes more people, but it does raise the ceiling in allowing the best designers, the best engineers, to be more productive. And it's delivering on both ends. And I do think that's the reality of what we're seeing.
You mentioned a brilliant word there, which was constraint. I'm permanently debating what makes a good constraint versus a bad constraint. How do you think about that with your product teams today?
I think everyone has a love hate relationship with constraints. If you're in the creative world, constraints create creativity. And without constraints it's almost.
It's not fun.
Yeah. Or constraints give you inspiration to some extent. And the reality is sometimes constraints are arbitrary. Right. We say, hey, we want to ship something by so and so timeline, and that's just an arbitrary constraint. But then it's really wild to see what people do with that. And so I think there is importance in having constraints, but the wrong constraints can be really dangerous too. So, for example, maybe you assume that a team assumes they can't change something about the way the product works, so has to build on top of what already exists. And that could be a bad constraint because it results in a subpar experience. And so being able to recognize those kinds of constraints is a really important part of product thinking.
Is there a constraint that you thought was good that turned out to be bad? Good example for me, say, would be I was very much a fan of not doing video. We don't do YouTube. No. We are constrained on audio because we do a lot of shows. But they're very, very good people, don't feel as comfortable on video. The constraint of channel I thought was very good, very wrong, very bad. I misunderstood my customers and what they wanted, which was a much more visual presentation. A good constraint that I was wrong on.
Yeah, I mean, I think one thing I would say is a lot of our product philosophy earlier at FIGMA had been the power of the infinite canvas. And the beauty of FIGMA was that you go into a space that feels conversely, has no constraints in some ways. Right. You can keep creating bigger and bigger things and expanding the canvas in both directions and that's amazing. For collaboration, because you can keep building on top of each other without clobbering each other. Whereas, for example, in a dock, it's one dimensional. And so as you add stuff, you're pushing other things down and you have to contend with the space. And so figma Design, figjam, that was a big part of the beauty of that. But as we started building other products, we realized, and other audiences, they were like, oh, no, people are confused by a 2D canvas. They would prefer to be in more of a workflow where they can see one thing at a time. And so as we contemplated other types of users, like developers or product managers and others, we realized that reducing that dimension in some cases was actually better.
How fast do you know when a new product is wrong is not what you thought it was going to be?
I would say it's fast to know that it's not working in terms of just put it in front of some users and see if it sticks. We often do some beta testing where we put it in front of a team and then we check in a week later and are they still using it? So that's like, obvious. But then the difference between good and great can be more subtle and you have to let it play out a little bit sometimes, or you have to kind of see it out in the real world or test it with a bunch of different kinds of users to know. So I would say it's very obvious. For something that won't work at all, maybe it takes more time to discern amazing from good.
What was the biggest flop? The one that released, and it just did not work and it was super clear. And what did you learn about that?
I would say that at least from a reception perspective, we had worked on some AI features the year before, which at the time we had called make design, where you can go from a prompt and it would generate some designs on the canvas. And it was a pretty simple feature. You write some prompts and then it would use some templates and some basic variables to make that template look a little bit more custom to your use case or fill it in with content that's a little bit more dynamic. But at the end of the day, it was just matching some prompts to some templates. But because it was called Make Design and because people didn't exactly know how it worked, Anchor Community was very unclear as to our intentions. What are you trying to do with this feature? What is it actually being trained on? And there was a lot of backlash to it, when in reality, what we intended for it to be and we renamed this feature later was a first draft. And to get you going, it's not supposed to replace the act of designing. You have to iterate from there. And we wanted to be more clear around, well, what's going on underneath the hood. So we wrote an entire blog post that explained how it worked. And in our recent products too, we're now more transparent about, well, we use these models and this is exactly how it works. So there's a little bit of like.
Does that go against the screensaver simplicity that we mentioned earlier, the need for clarification, the need for crystal clear communication?
Yes. And I think that's also maybe we were having to retroactively do all this explanation. There was an opportunity to have in the product have named it something more clear. Be very clear that today, if you take a screenshot of figomake, you see, oh, it's being powered by Claude and it's like, okay, make no questions, you know exactly where the code is being generated from. So I think those are some lessons that we could have applied. But at the time I think there was something about taking care of it for you without bothering you with the details. That might have been a point of view that led us initially to be more obfuscated.
So when we think about that process, often it's kind of navigated by PMs. And PMs are often told to me on the show, PMs are the CEOs of the product. Is that true that PMs are the CEOs of the Product? And how does being a PM change in the next few years?
I started my PM career at Microsoft and the first thing my manager said was basically like, you are a glorified secretary. That's how you should think about yourself. And you're here to unblock your developers. That's what your job is. That has been ingrained in me for a while in terms of there's a worldview where you say, hey, you don't have any hard skills, so you're just here to fill in the gaps. And so that's been my philosophy forever. There are talented designers and engineers who are just have a command of their craft that I could never have. So I've never kind of resonated with the CEO type of language, with the.
Blurring of lines where you fill in the cracks, the cracks are molded over, so to speak. I have many people say that we won't actually have PMs in a few years.
Look, I'm open to that idea, but I do think that the nature of the work is still very important. And one of the simplest ways I've heard PM explained before is that they're responsible for the why. Why are we doing this? Why is this a priority right now? Why this particular use case or user base or whatnot? Creating clarity on that allows everyone else to make really great decisions. I think that somebody does need to play that role. I don't think that it has to be someone called a product manager, but certainly the best product managers are able to create that kind of clarity.
Is that the PM and the why? Is it the founder?
No. For me there's like a cascading levels of whys. Right. And there is a very deep existential lie that a founder owns in a smaller company. They are the person who is doing all of that. And in fact that smaller companies shouldn't have PMs because the founder is playing that role. But you get to scale where you need.
Could figma exist without PMs?
I mean, I have a very biased view on that. I think that it could if our other functions step up to play that role. And there are certainly a lot of people in engineering and design that can play that role. But I don't think overnight you would be able to get there because we've built a function around being able to go deep in the why and really work deeply with our customers. And so that is time and skills that needs to be.
It sounds like I'm against PMs, but I'm not at all. PMs are wonderful. Does their presence not allow for fragmentation to continue though? Which is like if you have this glue across all the different entities or functions, they don't need to interact in the same way that they would if you took them away. And suddenly cross functional communication becomes super important to them because they have to address the way themselves.
Right. I think this comes back though to the original thing I was talking about, which is that it can be hard for someone to push on both sides. Right. One of the unique things about PMs is they're the ones facilitating the trade offs between these different points of view. Engineering here, saying what's feasible or what's not, a designer saying what's right for the user, being able to kind of mediate that. And certainly the two sides can do that. But in a complex business there are a lot of these kinds of points of view from different functions that need to be accounted for. And it's almost easier to tell a designer or an engineer to really advocate for one aspect because that is what they're deeply ingrained in. And product managers are uniquely good at being able to objectively look at all that information, think about the goals and the whys, and decide what the best balance of things are. That kind of leadership, I think is important.
What is the most non obvious trait that the best product people have? And so like we talked earlier and I said, actually being a part of a clan or leading a gaming clan is one of the most deterministic signs of success as a founder. Are there any traits, behavioral backgrounds, commonalities that lead to the best product people?
For me, it comes back to storytelling. And I'll give a specific example, which is I think a PM is really great at motivating something incredibly boring as existential. And so whenever I'm interviewing PMs, I just ask, okay, well what are some projects you've led? And whatever. And if they can't make it sound interesting to me, no matter the space, then I'm dubious of their abilities to rally a team. Because part of it is, yeah, they have to make a case for why it's an important thing to do right now, because otherwise there's plenty of other important things to be doing. A team has to be motivated around that. Even if it's some really boring compliance project, a product manager can make it feel incredibly existential and so strategic and important and get everyone excited around it. And so that's the skill.
I look for one thing that's so important. I was listening to a brilliant Jony I've talked and he talks about kind of the importance of joy and play in design. How do you think about that versus utility? In a world where consumer attention is shorter than ever, is it important for products to be playful?
Play shows the human behind the product and it also shows the care. To some extent, I think the most exciting things I look back in my career are moments when someone decided to care so deeply, not because there was some OKR that they had to fulfill, but rather because they just were excited to think about the reaction that someone would have when they discover that little thing or that people would start talking about it even though it wasn't in service of a particular kind of metric in the funnel. And I think the pride in that, that pride in craftsmanship there is what first of all just makes product building fun. At the end of the day, we're here because these are jobs, but also because we are designers, we are craftsmen, and that's what gives us joy. And so if you can't find those moments in your product, then it's quite sad.
It's funny. Gustav Soderschrom from Spotify, who I think is brilliant, he always says the details are not the details, they are the product. And I think that's so important. How do you think about when to get it shipped and out versus when to perfect every tiny little bit and the details being so important?
It's the perennial question. I would say that it also depends on the culture. For example, at Figma, we have a culture of everyone wants to get the details right. So sometimes we have to encourage people to be comfortable getting something shipped.
Do you struggle to place urgency when the details are so central?
There is a very concrete trade off around learning so that you know which details to perfect versus just perfecting the details right. So if you're perfecting the details for a critical part that it's going to help you understand how well this product is going to do in the market, then by all means. But if you're starting to kind of perfect these areas that are much more speculative or areas of the product that you're not sure are going to be used, I'd rather first know if we have general product market fit or just know what parts of the product people are drawn to to then put more of attention on that.
What metric is your guiding? North Star within the product team for customer love?
Our main product is one that's used five days a week, deeply for hours a day. Our first product, Figma Design, has always set the bar for what it means to be the kind of tool that people are deeply, deeply reliant on. That's kind of the golden standard always within Figma. For deeply Reliant, we call it ND7. Like how many days in a week that people are using your product, for.
Example, and for you it's five.
Yeah, I mean for designers, it is their core job.
You mentioned that the element of building beautiful products and the granularity with which you build too. I'm permanently debating whether the build it and they will come is true. You mentioned people share products much more that they love. If you build beautiful product, do they come versus Hell no. Distribution is everything. And more than ever today you can.
Build the most beautiful thing and it's not discovered. And Figma has been the place where I learned that the most because Dylan, our founder from the beginning, was very much about the designer community and getting them talking about Figma. So one of the first things he did was he took design Twitter, he visualized it as a graph and then figured out which people designers are following. The most, and then went to those designers to get feedback on Figma and get them excited about Figma. And that was his strategy and it worked. And design Twitter at the time especially worked in that way where they were influencing each other's choices in this really profound way. Had he not done that, I'm not sure we would have seen that acceleration in growth or that buy in from the community. So that's not the way I think usually because I'm just all more focused internally on, okay, let's build something great. But I do think that matters a lot. But I don't want to necessarily say that that's the only important thing, obviously product distribution.
What's the ratio of importance? 70, 30, 60, 40.
Certainly a lot of things out there today that are fantastic demos that people all try out because they're talking about it, and then it ends up not delivering on that. And then all of a sudden it's so much harder to win back those users and have them come back. I think the most important thing is finding some small cohort of people who just freaking love your product.
It's a thousand true fonts.
I don't know if 1000 cuts it these days, but something of that magnitude, that would be my way of building.
You mentioned the community aspect that Dylan focused on very early. There's. You see a lot of new products come and go. What are the biggest mistakes you see others around you make with regards to community building?
You know, relationship with community is incredibly important, but you also have to learn how to talk to them. You know, we're always motivated by what people ask of us, but we have to ask deeper questions than that. It's easy to just keep building what people ask, but we want to be like, well, why are you asking for that feature? And they'll say, well, it's because I have this problem. But why do you have that problem in that first place? At Figma, engineers have this ritual around the five whys to get to the bottom of why did this mistake happen? And you kind of get deeper and deeper to find the root cause. And I think that same exercise needs to be done with the community. And that's not to say the community's wrong. They're not always expressing their needs via problems. They might be talking about a feature that just comes to mind. And so important is to build a deeper relationship with them, to be able to ask. That's a great idea, but maybe help me understand why you even want that. Maybe we can come up with something better.
What would you most like to change about Figma design across any product. It could be horizontal or it could be about a product specifically, but for some reason you're unable to. Could be Dylan, could be product teams, could be whatever.
I would like our products to be even more closely integrated than they are today. We just recently went from four products to eight products, which is really exciting. But there's so much more room to make it so that it just feels like a cohesive experience where you can maybe start in one product but fluidly move to another.
Do you think it was the right decision to have that many products that quickly? The cadence of rollout is very fast. It was all at once. Sometimes you need to drip feed people so they can understand the expansion.
I guess time will tell. I mean, this is the first time we've tried something like this and we'll learn a lot from it. But it's also indicative of the diversity of our user base at this point. Right. There are plenty of people who are excited about a subset of these products and there are different audiences that we're beginning to reach. And so maybe to the average user, they might not kind of perceive it as four new products to learn necessarily, because a couple of them really resonate and they're going to go explore those first.
When you think about those four new products, do all of them work? If you place forward three years, do those four products all still exist? Or is it a case of no, we'll likely drop two?
Well, certainly we don't launch with the assumption that we'll drop nea, but at the same time, many of them are in beta and we fully expect to learn from that. And if there's an opportunity to kind.
Of like, what are all my things in beta for?
We take as long as we think is needed to get the product to a state we're proud of. Some of these are pretty sophisticated products. And the kind of interesting thing about building a tool is a tool is very different from a typical consumer product where there's a funnel and you're trying to optimize the metric. You're building something so that other people can build other things. And so it's hard upfront to imagine all the ways in which someone will take your tool and build something. Right. I mean, you definitely have some use cases in mind that you start with, but everyone always surprises you. And so I think there's some amount of humility you need to have as a tool maker to let people's creations help you understand where to take the tool or where to double down or what's working, what's not. And as a result of that, we need to give people the time to create on our tool.
I'm just wondering if it's a little bit like firing people, which is you always know well ahead of time and you just let it go on for too long. And my question is, do you know when a product's failing but you let it go for too long?
In my career, certainly I've seen products that probably should have spun down or sunsetted earlier, which is the most prominent.
That comes to mind. And what did you take from that?
I don't know if I can comment on that.
That's one of those phases where it's like I know exactly what product, but I don't want to piss anyone off too much. Which is a totally fair answer. By the way, that's very funny. What product have you not built in figma that you would most like to build and why?
As much as we celebrate or we talk about things in terms of products as units of accomplishment or something, at the end of the day we have one thing we're trying to support our users in doing, which is building software or building digital products. For me it's less about oh, what other product do I need to build to help teams do that? And rather what are all the gaps today that still exist that make that job hard for us that can manifest in features in an existing product or a stronger connection between products or things like that. So there's plenty of things where if you ask the average person, okay, well what's hard about building products today? They'll list a thousand things that make it difficult or take a lot of time and those are the things that we need to go and build.
What is the one for you?
There's still a strong disconnect between what people design and what ends up in users hands. And for me, a thought experiment is next time a designer shares a portfolio with you, are they sharing the designs that were beautiful mocs or are they sharing the designs as screenshots from production? And chances are they're sharing the ones that were designed in a perfect environment with perfect data. And for me, my goal would be for them to be as proud to just pull up any person on the street, pull up a screenshot of what they have and be like that is my design. I'm so excited about it.
Is the chasm between design and implementation a feature or a bug?
Oh, that's a great question. I would say it's primarily bug today, perhaps at times masquerading as a feature because I think designers are always designing ahead, right? So they're always thinking about v1, v2, v next. And so as a result of that, it is natural for the designs to always be a little bit better because they're thinking ahead and they're upstream. But that being said, I think too often designers are designing far too ahead and not sitting in the reality of how their product exists today, if that makes sense.
Have your teams ever got in a product funk? And what I mean by that is a lack of creativity, a lack of energy? And how do you reinvigorate a product team to be creative, ambitious, hungry, excited, when it's a little bit formulaic?
Yeah, that certainly happened. Sometimes it can happen because you just have this very hard problem that you've been banging your head against the wall for such a long time that can be solved with a variety of different things. Maybe it's change up the makeup of the team or revisit some constraints because something in there is maybe causing people to kind of think that they have to constrain their solution space in a particular way. But I think things like Maker Week are exactly that kind of rhythm to disrupt the everyday.
Is once a year enough?
Perhaps not. Perhaps not. Teams have their own hack week sometimes, or my favorite is actually quality week where people kind of step back from their roadmap and go back to oh, I wish I could go polish that other thing that I didn't have time to do or fix that long standing bug or something of this nature that again, kind of pulls you out of your current project. In fact, some of our most popular launches are these small little things that we brand them as little big updates. Our users love it.
Little big updates, yeah. It's a wonderful way to kind of caveat something that maybe doesn't work, but maybe works. If it doesn't work, well, it's a little update. If it works, it's a big update.
Harry Stebbings
You know what I mean?
Yuki Yamashita
Well, I mean, oftentimes there are small little bugs or small little, I call them micro tragedies that finally get addressed. So they're very much celebrated by our users.
If I gave you unlimited resources today, catch wise, I guess would be the most obvious. How would you change what you do and build?
That's a good question. I'll first caveat it with. It's not always the case that throwing more people or resources at a problem makes something go faster. And I say this because we just launched a bunch of new products and perhaps the hardest problem still Is how do we make them connect better? And making them connect better requires the systems thinking, seeing the whole picture, that just throwing more people at that isn't going to necessarily solve. You need to solve, throw the right people at that problem or give yourself the time to do that. So I'll kind of caveat it with that and maybe also add that my personal hope is to be able to, I know it's a little bit high level, but make things connect better. And that's a problem I would want to solve a little bit more.
And the biggest reason for lack of.
Connection is I think one of the things philosophically that this time we focused on is before we prematurely say that everything has to be very deeply connected, I mean, they still are very connected. You can copy paste between things. It's all in one platform. So that's great. But I think that one of the reasons for that was we're trying out new use cases and we need to learn from that. And before we prematurely make everything work together, let's learn what's working, what's not, and each of those products. Great. And then it'll become more obvious how things fit together. So I think it's kind of by design to some extent. But I also want to recognize that for an end user it might feel overwhelming if there's like a lot of products and not knowing where to start.
For example, does AI make discovery more challenging? In a product world where everyone is democratized to create anything they want, the supply side of new product creation is infinite in many ways and discovery becomes more of a problem. How do you think about that?
Well, it's discovery, but I think it's more, we think about it more as craft, which is that there's a sea of software, everyone can make some product and it's really about, well, what is going to help differentiate one product from the next. And we deeply believe it's great design, great craft. And that's not something that you can rely on an AI to figure out by itself. You need human guidance to push it to think about the experience more deeply or think about something really unique. And that is the first problem to solve. Because if you're just helping people discover mediocre software, that's not helping the world. Right.
Totally agree with you. Before we do a quick fire, I do just want to touch on the Uber experience because it's fascinating when you think about biggest product win that you worked on, what was that and what did you learn from a product perspective?
I mean, I would say that it was that Transformation of helping Uber. Believe it or not, it's hard to remember, but Uber worked very differently back then, where you would pick a car based on a type of get in the car and then at the end get a receipt. And only until you get the receipt did you know how much you would pay. Right?
Surprise.
Yeah, yeah, yeah, yeah. And we got called out a lot for New Year's Eve for that, you know, and that's how taxis worked. So by far the biggest transformation to that experience was being able to enter your destination upfront, show the price and time. On our end, knowing your destination up front before you get into the car was a huge win because we could optimize everything, optimize routes, we could do pricing based on your destination, all these kinds of things. So I think that was transformative.
What does transformative people want? Reliability. People want transparency. People want.
I think the lesson was actually, at the time, there's huge pushback to doing this internally. The most profitable parts of the business at the time was our Uber Black business. People were worried that when juxtaposed against the cheaper UberX or Uber Pool prices, that would take a hit. It wouldn't be profit maximizing, I guess, for the business. And given that the industry didn't have that precedent, it was kind of like, why are we forcing our own hand to do that? But at the time, Travis was CEO at the time was just like, yeah, but this is about principles. And he was very insistent that part of the magic is the transparency and we're going to go change the industry and everyone else is going to follow, so we might as well be the first ones to do it and learn from it. And he was absolutely right, but it was a very hard thing. Yeah, I would love to do a.
Quick fire around this.
Harry Stebbings
So I say a short statement.
Yuki Yamashita
What's been the hardest moment at FIGMA so far?
I would say probably, I mean, if I'm fully being honest, it was coming out of the breakup with Adobe and making sure that our community understood that we're business as usual and we're here and we're the Figma, you know, and love, and we're just going to continue to focus on them. Right. And I think that while it's true that during that period we were building and heads down and everything, I think it was still a moment for us. Right. To prove to the community that we have as much momentum as ever before and we're excited about our path forward and it was just like a big moment.
What did Dylan say to galvanize the team that is the hardest, most challenging moment. Listen, Figment is now going to be an incredible standalone company. And so it's like, works out well, but that moment is very hard. What did he do and say to galvanize the team?
He just really went back to the mission and how big it is. And he often likes to at least internally index on an original vision that he had for Figma, which is just going from imagination to reality. That's kind of what he started with before people were like, okay, well, maybe you should be more specific than that. But he just reminded everyone of this founding vision and how broad that was. And I think that was really important to show. There's so much to do. Basically, it was kind of like the message, first and foremost. And then the second thing was just a lot of it was really focused on our community. Right when all this is happening, there are so many people, so many of our users, who are just really excited about our future and pointing everyone to that and saying, hey, look at everyone who believes in us, who are excited for all the things that we're going to be doing, rallying everyone around our community and their excitement.
We're going to do a feedback session and you're giving a review on yourself as a product leader. If you were to say, hey, this is the weakness. You need to work on this, what would you say to yourself?
That is, I tend to be not a very emotional person, and oftentimes I would get this feedback of, oh, you should use emotion as a lever more, or it's hard to know what you're thinking, because sometimes I'm just processing without giving an immediate visceral reaction. I think with every strength, there's a shadow kind of thing, and I think that's an example of this. But I think there's a way in which I can be better as a leader to not just rally people around the intellectual interest of building products, but just the emotional part of it more.
It's funny, I would say my biggest weakness is I'm too Italian, which is like, you know, if someone says to me, I'm like, I hate it.
Harry Stebbings
It's terrible.
Yuki Yamashita
Yeah.
And then like five minutes later, I'm like, no, not a bad idea quite like that one. But I've already kind of done the damage of, like, you know, bluntly being far too emotional up front. When you think about great product leaders, which product leader do you most respect and admire? And why them?
One of them is a mentor of mine who is now CEO of Grammarly, and he used to lead product at YouTube. Shashir. He's such an incredible systems thinker. He just knows how to run an organization and he obsesses over rituals and basically kind of designs. I think a lot of times you think about building a product and designing a product, but he also thinks about designing a culture very intentionally by designing very unique and interesting processes, meeting cadences and everything is just so beautifully structured and intentional. And yeah, it's just really fun to be a part of and impressive.
What is bad about the Figma product culture that remains and you would like.
To change, it's still very tribal knowledge. You kind of have to know this random nuance here, which is why this backstory, which is why we can't do this. And sometimes that prohibits some of the new people from being able to get to a better solution faster or know how their product affects other products. And I just wish that we did a better job codifying it some way so that everyone can understand or simplifying it so there aren't all these strange dependencies.
Final one, what's a recent product strategy in particular or product that you've been most impressed by and why that one? So, like, for me, it was actually Duolingo. That's why I had them on the show. But it was the attention to detail, how they use haptics for progression through levels. This granularity of user delight was so obvious, actually. What's your favorite product in the consumer realm that you think is beautiful?
The consumer product right now that I love is Waymo, but it's more kind of the physical experience of it. I mean, part of it is obviously just how impressive it is in making you feel incredibly safe in something that didn't seem plausible. And all the little cues that they have in the product that that kind of make you feel they are on top of it. And just even the attention to detail, like there's a biker coming by before you open the door or stuff like you leave your bag, they'll let you know as you're walking away. Right. Stuff that a driver could do too, but it's just the default. And I think its ability to kind of make the average experience the best experience, almost because of that tension to detail is just really something we said at the beginning.
The best conversations are conversations. I so appreciate this conversation. I don't actually know, to be honest, if I went through any of these questions, really. I don't like to look. It takes away from the conversation. You've been fantastic, so thank you so much.
No, you've been a great host, so thank you for that.
Harry Stebbings
I so enjoyed that show with Yuki. And if you want to watch that show, you can find it on Spotify by searching for 20 VC. That's Spotify and searching for 20 VC. But before we leave you today, are you struggling to beat model benchmarks or implement Genai in your product? If so, you need Turing Turing is an AGI infrastructure company backed by incredible investors like Foundation Capital and Westbridge Capital. And they do two things. Number one, they help leading companies in AI labs like Salesforce, Anthropic and Meta enhance their LLMs with advanced reasoning, coding, multilinguality, multimodality and more. Number two, they combine human and artificial intelligence expertise to deploy cutting edge AI systems for awesome companies like Rivian and Reddit. Right now, Turing offers a free 5 minute self assessment to help you pinpoint your place in the Gen AI journey, get tailored next steps to optimize your model strategy and then finally learn how Turing can run, refine and implement your models for better performance. Take the guesswork out of Gen AI. Visit turing.com 20vc to start your free assessment today and once your Gen AI strategy is on point with Turing. Now let's switch gears to the future of mobile and how one company is turning your screen into real returns we spend nearly half our waking hours glued to our phones, upwards of 50 hours every week. Recently, one company transforming this reality stood out so much I personally became a shareholder. Mode Mobile Mode Mobile created the EarnPhone, the smartphone that pays you for daily activities. Instead of big tech, profiting billions from our attention, Mode returns over $325 million directly to users through earnings and savings. Mode's revenues surged an incredible 32,481% in three years, recognized by Deloitte as 2023's fastest growing software company in North America. And here's why I'm excited. MOAD's equity offerings have raised over $30 million from 20,000 retail investors, one of 2025's standout public raises. And you can now join me as a shareholder with as little as $1,000 at invest.modemobile.com 20VC for a limited time, unlock up to 100% bonus shares and a free Earn phone. Email us for the Investor Brief at 20VCODEMO or check out invest.modemobile.com 20VC We've talked about making money from your phone. Now let's talk about making your product do exactly what you want it to. Whether it's the software you build or the software you buy. Your tech stack should be creating results, not creating roadblocks. Well, Pendo's no Code Software Experience Management platform makes your software better with tools to see where users get stuck. Guide them with in app messaging and constantly improving your UI. It's so easy that over four 14,000 businesses use Pendo to increase revenue, lower costs and reduce risks. Businesses love the control, engineers love the freedom. Everyone wins. Start for free today at Pendo iO20 product. As always, I so appreciate all your support and stay tuned for an incredible episode with the founder of Duolingo on Monday.
Podcast Summary: The Twenty Minute VC (20VC) – "20Product: Figma CPO on How Figma Builds Products" with Yuhki Yamashita
Release Date: May 16, 2025
Host: Harry Stebbings
In this episode of The Twenty Minute VC (20VC), host Harry Stebbings welcomes Yuhki Yamashita, the Chief Product Officer (CPO) at Figma. Yuhki brings a wealth of experience from his previous role as Head of Product at Uber, where he oversaw the core rider experience used by millions worldwide. Renowned for his expertise in product storytelling and team building, Yuhki shares insights into how Figma develops and scales one of the world's leading design platforms.
Impact of Frequent Moves on Empathy and Design
Yuhki begins by reflecting on his childhood, moving frequently between places like Tokyo and Singapore. This experience fostered his ability to empathize with diverse users and question fundamental assumptions about how things work.
"As a young kid, you just want to fit in... I felt like I needed to just abandon all of my assumptions about how things work." (04:04)
This adaptability has been crucial in developing user empathy, a cornerstone of effective design and product management.
Simplicity vs. Feature Complexity
Harry and Yuhki delve into the mantra "simple is always better." Yuhki challenges this notion, emphasizing that while simplicity is valuable, it shouldn't lead to stagnation or unnecessary feature creep.
"Simplicity is a perception, so it's not necessarily a reality. If you take simple is always better to an extreme, you might not add new features, you might not add new capabilities." (05:10)
Balancing User Needs
Yuhki explains Figma's strategy to cater to both novice users and power users by offering different modes within the same product.
"We have different modalities, allowing them to be in the same artifact together while using different lenses." (05:46)
For instance, Figma Buzz introduces Design Mode tailored for marketers, while regular users enjoy a straightforward editing experience.
Identifying New Product Opportunities
Yuhki attributes new product development to observing how users "hack" Figma for unintended purposes. This real-world usage provides genuine insights into unmet needs.
"A lot of our new products are a function of that... motivated us to think about building a space for them." (07:17)
The Role of Maker Week
Figma conducts "Maker Week," a hackathon-like event where passionate team members develop proof-of-concept projects. Tangible prototypes from these sessions often secure spots on Figma's roadmap.
"Building something tangible that people can use convinces people more that this idea is tenable." (08:26)
Blurring Lines Between Disciplines
The conversation shifts to the future structure of product teams, highlighting the increasing overlap between design, engineering, and product management roles.
"The boundaries were being blurred... moving up in some ways in terms of abstraction." (19:46)
Evolving Team Structures
Yuhki envisions teams becoming more generalist, with specialists contributing deeper expertise when necessary. This flexibility fosters innovation and strategic problem-solving.
"More of each function or more of each consideration will be more equally represented." (23:10)
Adopting AI-Assisted Tools
Figma is exploring AI-assisted code editors like Cursor to boost engineering productivity. Yuhki emphasizes the dual impact of AI: making coding more accessible while enhancing the capabilities of seasoned engineers.
"AI... lowers the floor and raises the ceiling." (24:45)
Positive vs. Negative Constraints
Yuhki discusses the role of constraints in fostering creativity within product teams. While constraints can inspire innovative solutions, arbitrary or misaligned constraints may hinder progress.
"Constraints create creativity... the wrong constraints can be really dangerous." (25:22)
Example of Constraint Evolution
He shares an example where Figma's infinite canvas philosophy was adapted to better suit different user needs, balancing flexibility with usability.
"Reducing that dimension in some cases was actually better." (26:56)
Case Study: Make Design Feature
Yuhki candidly recounts the challenges faced with introducing the "Make Design" feature, which initially led to user backlash due to unclear intentions and functionality.
"We wanted to be more clear around, well, what's going on underneath the hood." (29:54)
Lessons Learned
The experience underscored the importance of transparent communication and setting clear expectations when launching new features.
"There was an opportunity to have in the product have named it something more clear." (30:31)
Focusing Beyond Product Development
Yuhki highlights that building a great product is only part of the equation; effective distribution and community engagement are equally vital for success.
"Dylan... focused on the designer community... that was his strategy and it worked." (38:34)
Common Mistakes in Community Building
He warns against merely responding to expressed needs without delving deeper into the underlying problems, advocating for a more inquisitive approach to community feedback.
"It's easy to just keep building what people ask, but we want to ask deeper questions." (40:20)
The Role of Product Managers (PMs)
Yuhki debates the notion that PMs are the "CEOs of the product," emphasizing that their primary responsibility is to define the "why" behind product decisions.
"Creating clarity on that allows everyone else to make really great decisions." (31:21)
Essential Traits of Great Product Leaders
He identifies storytelling as a critical skill for PMs, enabling them to motivate teams even around mundane or complex projects.
"A PM is really great at motivating something incredibly boring as existential." (34:31)
Personal Leadership Development
Yuhki reflects on his own leadership style, recognizing the need to balance intellectual leadership with emotional engagement to better rally his team.
"I need to be better as a leader to not just rally people around the intellectual... but the emotional part." (54:43)
Admiration for Waymo
Yuhki expresses his appreciation for Waymo, particularly praising its attention to detail and user safety in autonomous driving technology.
"Its ability to make the average experience the best experience... really something." (57:24)
Yuhki Yamashita provides a comprehensive look into Figma's product development ethos, emphasizing user empathy, iterative innovation, and the critical balance between simplicity and functionality. His insights into team dynamics, the evolving role of product managers, and the integration of AI in engineering offer valuable lessons for aspiring product leaders and venture capitalists alike.
Notable Quotes:
This episode offers deep insights into effective product management and development from a leading figure in the tech industry. Whether you're a budding entrepreneur, a seasoned product manager, or a venture capitalist, Yuhki Yamashita's perspectives provide valuable guidance on building successful, user-centric products.