Lenny's PodcastAn inside look at how Figma builds product | Yuhki Yamashita (CPO of Figma)
CHAPTERS
- 0:00 – 0:56
Cold open: Turning controversial product shifts into a movement users champion
Yuhki explains how Figma’s early, polarizing premise—real-time multiplayer design—created narrative tension that signaled a true revolution. He argues that the best product stories equip customers to advocate not just for a tool, but for a new way of working.
- •Controversy and pushback can be a signal of meaningful change
- •Users rally more behind a philosophy than a feature set
- •Make customers capable of retelling your vision in their own words
- •Big visions create “movement energy” that fuels organic advocacy
- 0:56 – 5:04
Show setup: Who Yuhki is and what this episode will cover
Lenny introduces the podcast’s mission and Yuhki Yamashita’s background across Microsoft, Google/YouTube, Uber, and now Figma as CPO. He sets expectations that the conversation will go deeper than their earlier newsletter collaboration.
- •Podcast focus: building and growing great products
- •Yuhki’s cross-functional arc: PM, design leadership, back to product
- •Episode themes: product philosophy, hiring, PLG/community-led growth
- •Reference to the companion newsletter post for templates/details
- 5:04 – 9:05
Yuhki’s career arc: From Hotmail and Windows to YouTube, Uber, and Figma
Yuhki walks through the key transitions in his career and what each environment taught him. He highlights how his interest in the design/product boundary ultimately pulled him toward Figma’s mission.
- •Early PM experience at Microsoft (Hotmail, Windows 8) and strong spec culture
- •Move to YouTube and learning different PM styles at scale
- •Uber as a fast-moving environment shaping product-building philosophy
- •Discovering Figma at Uber during a push for transparency and inclusion
- 9:05 – 12:20
What PMs learn from managing design teams (and why design management can be harder)
Yuhki shares why switching into design leadership was a powerful empathy and craft-building exercise for him. He also explains why managing designers can be tougher than managing PMs, largely due to the need to grow craft alongside delivering impact.
- •Switching roles builds empathy and expands how you push the product forward
- •Design requires insisting on the best experience, sometimes suspending feasibility constraints
- •Designers’ craft growth needs may not align with the company’s biggest immediate problems
- •PMs often optimize for impact and the most important company problems
- 12:20 – 16:35
Storytelling as a core PM skill: Synthesis, memefication, and driving action
Yuhki frames storytelling as central to effective product leadership, especially in distracted organizations. He emphasizes synthesis—distilling disparate inputs into a cohesive thesis—and making insights “sticky” enough to spread and drive decisions.
- •Synthesis turns messy discussions into forward-moving direction
- •Frameworks are a form of storytelling: offering a lens for decisions
- •Memefication: making an insight repeatable inside the company
- •A story’s value is measured by the actions it compels
- 16:35 – 18:51
How to improve storytelling: Reset context, fight the curse of knowledge, teach with metaphors
Yuhki shares practical ways he coaches PMs to become clearer communicators. The goal is to rebuild the narrative from zero context, using grounded metaphors—similar to teaching—to make complex ideas accessible and compelling.
- •“Reset your brain” and explain from no-context first principles
- •Assume the audience lacks the background you take for granted
- •Borrow real-world metaphors to make abstractions concrete
- •Teaching is a forcing function for clarity and audience empathy
- 18:51 – 22:33
PM ownership of the “why”: Scaling decisions when you can’t specify everything
Yuhki explains why PMs don’t have to own the idea, the what, or the how—but must uniquely own the why. He contrasts Microsoft’s detailed spec culture with YouTube/Google’s delegation and shows how shared understanding of the why enables better local decisions.
- •PMs don’t need to originate ideas; customers and teams contribute heavily
- •Owning the “why” aligns decentralized design/engineering decisions
- •Google/YouTube style requires teams to make many local calls without PM input
- •Five Whys thinking helps uncover root causes beneath feature requests
- 22:33 – 26:13
Customer proximity as culture: From Figma’s origin story to “Concerning Tweets”
Yuhki describes how Figma’s earliest success came from putting the product in front of designers repeatedly and implementing feedback fast. He also shares how Dylan Field’s intense feedback habits led to creating a private channel to triage important signals without derailing teams.
- •Early loop: demo to designers → implement feedback → repeat
- •Community shaped product direction and became natural evangelists
- •PMs engage the community directly (e.g., asking questions publicly)
- •“Concerning Tweets” channel: capturing weak signals without creating chaos
- 26:13 – 32:36
Balancing feedback inputs: Tweets, support pain, sales perceptions, and avoiding blind spots
Yuhki explains how Figma treats social feedback as “canaries in the coal mine,” not the whole truth. He outlines the need for a balanced portfolio of feedback sources—each with its own bias—supported by research and data functions.
- •Vocal minority signals vs. broader reality: validate with data/research
- •Support tickets skew dissatisfied; sales calls can skew toward perceptions
- •Build multiple feedback pipelines beyond Twitter as the audience expands
- •Use qualitative and quantitative inputs to reduce blind spots
- 32:36 – 34:54
When launches don’t land: Branching/merging adoption and the limits of dogfooding
Yuhki shares an example of a substantial feature investment—branching and merging for design systems—that initially saw low adoption. He explains why: workflow novelty, performance, enablement needs, and the challenge of building for customers unlike your own org.
- •Branching/merging: governance workflow for high-scale design systems
- •Early adoption lagged despite customer demand and large investment
- •Root causes: performance, unfamiliar workflow, and change management needs
- •As Figma grows, it must test features for orgs unlike itself
- 34:54 – 38:48
Building high-quality software: Company-wide dogfooding and personal accountability
Yuhki argues that quality improves fastest when the entire company uses the product daily, not just the product org. He shares how Figma nudged usage by shifting to “deck culture” in Figma and using FigJam templates for HR processes, plus why firsthand pain creates accountability.
- •Dogfooding increases exposure to issues and motivation to fix them
- •Operational choices can drive usage (memos → decks in Figma)
- •Use internal rituals/templates (e.g., performance calibration in FigJam) to expand adoption
- •Personal accountability spikes when builders experience user pain directly
- 38:48 – 40:52
Letting engineers fix what’s broken: Bottoms-up energy and intrinsic motivation
Yuhki explains why he tries not to block engineers or designers when they want to fix real user problems they’ve noticed. He highlights how intrinsic motivation changes both speed and effort, and why buy-in matters for execution quality and velocity.
- •Bottoms-up improvements can beat top-down “quality metrics” programs
- •Avoid discouraging proactive fixes that improve real user experiences
- •Motivation changes estimates and outcomes—self-driven work ships faster
- •PMs should cultivate genuine team buy-in, not just assign tasks
- 40:52 – 48:17
OKRs at Figma: The love-hate journey and the three tests (legibility, actionability, authenticity)
Yuhki candidly shares Figma’s experimentation with OKRs: from dreaded spreadsheet rituals, to simplifying into headlines, to reintroducing rigor with a data leader, and then reframing as “commitments.” He closes with three criteria he believes matter most for any goal system.
- •Core-experience teams struggle to measure what “better” means without performative metrics
- •Two OKR failure modes: measurable-but-irrelevant vs. important-but-uncontrollable
- •Figma experimented: deprecate OKRs → headlines → bring back with more data rigor → “commitments” framing
- •Three requirements: legibility, actionability, authenticity
- 48:17 – 51:37
Hiring and interviews: What Figma looks for in PMs (especially storytelling and high-bandwidth thinking)
Yuhki outlines what he values in product candidates and how interviews reveal those strengths. He emphasizes storytelling under controversy, the ability to make problems compelling, and “fast-forwarding” through decision trees to avoid wasteful work.
- •Favorite question: describe a controversial product decision and how you navigated it
- •Great PMs can represent multiple perspectives fairly and clearly
- •Look for “high-bandwidth UX conversations” and rapid exploration of solution branches
- •Fast-forwarding: predict experiment outcomes to decide what not to do
- 51:37 – 58:49
How Figma grows: Community-led motion, sales enabling champions, and founder lessons
Yuhki reframes product-led growth as community-led growth, where internal champions drive adoption and sales helps amplify them. He shares why intentional community-building (sharing files, Friends of Figma) creates loyalty, and why founders should aim for an emotional “love” response plus a philosophy users can champion.
- •Sales at Figma focuses on empowering internal advocates, not replacing them as the face of adoption
- •Human connections + credibility with design/product leaders matter in enterprise expansion
- •Community mechanics: sharing artifacts, open-sourcing workflows, Friends of Figma program
- •Founder advice: build something users irrationally love and can rally around as a new way of working
- 58:49 – 1:08:35
Adobe acquisition possibilities, closing reflections, and lightning round
Yuhki discusses what excites him about a potential Adobe future—more seamless end-to-end creative workflows and broader multiplayer collaboration use cases—while preserving Figma’s community closeness. He closes by emphasizing that Figma is still iterating on many “age-old” product process challenges, then answers quick-fire questions on books, tools, and favorite widgets.
- •Potential future: tighter interoperability across Adobe + Figma workflows and “single source of truth”
- •Expand multiplayer collaboration platform into broader creative domains
- •Non-negotiable: maintain and deepen community/customer proximity
- •Lightning round highlights: recommended books, tool stack, and the FigJam alignment scale widget
