Table of Contents
Figma's CPO reveals the counterintuitive strategies behind building one of the most beloved B2B products, from storytelling mastery to controversial OKR experiments.
When Yuhki Yamashita joined Figma as Chief Product Officer, he discovered something remarkable: the company had accidentally created a revolution. Not just in design tools, but in how teams collaborate. His insights reveal why traditional product management wisdom often fails—and what actually works.
Key Takeaways
- Storytelling is the most undervalued PM skill—great PMs synthesize complex information into memorable, actionable narratives
- Product managers must own the "why" while sharing the "what" and "how" with their teams to enable autonomous decision-making
- Community-led growth outperforms product-led growth by creating emotional evangelists who champion new ways of working
- Quality emerges from internal product usage—get your entire company using your product in creative ways
- OKRs often fail because they become performative tasks rather than authentic commitments to meaningful outcomes
- Hiring for storytelling ability and high-bandwidth UX conversations predicts PM success better than technical skills
- Personal accountability drives quality improvements better than top-down quality metrics and processes
- The best product feedback comes from failed users, not successful ones—they reveal adoption barriers
- Controversial products that challenge existing workflows create stronger evangelism than incremental improvements
Timeline Overview
- 00:00–12:20 — Career Journey & Core Skills: Yuhki's path from Microsoft to Figma, the unique experience of switching from PM to design lead, and why storytelling became his north star for product management success
- 12:20–22:34 — The Power of Product Storytelling: How synthesis and meme-ification create organizational knowledge transfer, practical frameworks for improving narrative skills, and why PMs must own the "why" of products
- 22:34–32:44 — Customer Obsession at Scale: Dylan Field's extreme customer proximity, the "concerning tweets" Slack channel, building balanced feedback portfolios, and how Twitter became Figma's early growth engine
- 32:44–40:50 — Quality Through Internal Usage: Why Figma switched from memos to decks, the branching/merging feature challenges, and how personal accountability drives better engineering outcomes than top-down mandates
- 40:50–48:40 — The OKR Experiment Journey: Three different approaches to goal-setting at Figma, why traditional OKRs feel performative, and the ongoing search for authentic commitment mechanisms
- 48:40–54:57 — Hiring Philosophy & Sales Collaboration: Interview techniques focusing on controversial product decisions, high-bandwidth UX conversations, and how sales teams empower internal champions rather than selling directly
- 54:57–58:57 — Community-Led Growth Strategy: The controversial nature of real-time collaboration, building emotional responses to products, and equipping customers to champion new ways of working
- 58:57–01:03:44 — Adobe Acquisition & Future Vision: Potential for seamless creative workflows, bringing multiplayer collaboration to broader Adobe ecosystem, and maintaining community relationships through transition
Why Storytelling Separates Great PMs from Good Ones
What if the most important skill for product managers isn't technical analysis or user research, but something taught in literature classes? Yuhki Yamashita believes storytelling distinguishes exceptional PMs from competent ones—and he's built his entire hiring philosophy around it.
"A lot of being a great product manager is being a great storyteller."
This isn't just about presentation skills. Yamashita identifies two specific aspects of storytelling that create outsized impact: synthesis and meme-ification. Synthesis involves taking disparate opinions from reviews and distilling them into coherent direction. Meme-ification ensures insights become memorable enough that executives naturally reference them in unrelated meetings.
"I found this out most at Uber... there were certain insights that were meme-ified to the point where someone like Travis or Dara was just citing this insight in the middle of a meeting."
When insights become organizational memes, they demonstrate true knowledge transfer. The test isn't whether your research was thorough—it's whether leaders unconsciously draw from your frameworks weeks later when making unrelated decisions.
But how do you develop this skill practically? Yamashita's approach involves resetting your internal computer: start from zero context and build the story from scratch. Assume your audience knows nothing. This technique, learned from teaching computer science at Harvard, forces clarity that makes complex products accessible.
The deeper insight here challenges how most PMs think about their role. Instead of being the person with all the answers, great PMs become the person who makes everyone else's answers coherent and actionable.
Owning the Why: The PM's Unique Responsibility
Most debates about product management center on whether PMs should generate ideas or execute others' visions. Yamashita cuts through this confusion with surgical precision: PMs must own the "why" while sharing everything else.
"I do think the why is something that I really always hold the PM uniquely responsible for."
This philosophy emerged from his transition from Microsoft's specification-heavy culture to Google's autonomous environment. At Microsoft, specs detailed every possible scenario. At Google, PMs couldn't specify everything—designers and engineers made countless local decisions independently.
"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."
This creates a multiplier effect. When teams understand underlying problems, they make better decisions in situations you never anticipated. Error handling, edge cases, and user experience details improve because everyone optimizes toward the same underlying goal.
The practical application extends beyond product development. Yamashita applies the "five whys" technique—borrowed from engineering postmortems—to customer requests. Customers ask for features, but the PM's job involves understanding why they have the underlying problem in the first place. Often, addressing root causes creates bigger impact than fulfilling surface-level requests.
This approach transforms PMs from feature factories into problem-solving orchestrators. Instead of dictating solutions, they create environments where great solutions emerge naturally from shared understanding.
The Concerning Tweets Channel: Customer Obsession at Scale
How obsessed with customer feedback can a CEO be? Dylan Field reads customer feedback for hours daily—to the point where Yamashita had to intervene with operational boundaries.
"Dylan's always reading customer feedback... there used to be this thing where he would drop in tweets that he sees into different slack channels... we got big enough where people would feel like they had to drop everything and deal with that tweet."
The solution reveals sophisticated thinking about feedback management. They created a private "concerning tweets" channel where Field shares feedback that often has zero likes but contains "essence of truth." This feedback becomes input into balanced portfolios rather than reactive fire drills.
"I really view some of those tweets more as kind of like canaries in the coal mine."
This metaphor captures the strategic value of weak signals. Individual complaints rarely represent widespread problems, but patterns in weak signals often predict broader issues before they appear in support tickets or user research.
The deeper principle involves building feedback systems that balance vocal minorities with representative data. Support tickets skew toward dissatisfied users. Sales conversations reflect prospects' perceptions rather than user experiences. Twitter captures passionate users but excludes most of Figma's audience. Great product organizations synthesize across these channels rather than over-indexing on any single source.
Field's approach—reading thousands of pieces of feedback personally—builds intuition that informs product decisions at scale. When he declares something "won't land well," that judgment reflects pattern recognition across massive feedback exposure, not random opinion.
Quality Through Dogfooding: Making Everyone a User
Most companies claim to use their own products. Figma operationalized this principle with remarkable creativity, fundamentally changing how quality emerges in their development process.
This decision wasn't about presentation preferences—it was strategic product development. Switching to decks forced product managers to encounter issues and build familiarity with user workflows. Recently, they conducted performance reviews in FigJam, creating another touchpoint for internal usage.
"The more hours people are spending inside your product internally... it just naturally becomes better because... you just want to make your own workflows better."
The psychological insight here challenges traditional quality approaches. Instead of mandating quality metrics or processes, creating personal investment in daily experience drives organic improvement. Engineers who personally encounter bugs feel embarrassed and accountable in ways that external bug reports never create.
"The degree of motivation is so different if that engineer has somehow experienced a problem in some way."
At Uber, Yamashita observed engineers becoming personally invested when they witnessed drivers struggling with app issues. When quality problems affect people you know—or yourself—fixing them becomes emotional, not just professional.
The broader principle applies beyond product teams. When designers at Figma ship features, they're shipping to people they know personally in the design community. This creates accountability that formal review processes can't replicate. Quality emerges from caring, and caring emerges from personal connection to outcomes.
The OKR Evolution: From Performance Theater to Authentic Commitment
Few product leaders admit publicly that OKRs don't work for them. Yamashita's candid journey through multiple OKR experiments reveals why traditional goal-setting often becomes performance theater—and what alternatives might actually drive results.
"OKRs are kind of like the bane of my existence... when you're working on the core experience, sometimes you're just like 'I'm just trying to make the experience better' and sure I can come up with this baseline to measure what that looks like, but that's not what I'm thinking about every day."
The fundamental tension involves measurement versus impact. Core experience improvements resist quantification, leading to two failure modes: measuring meaningless metrics you can move, or targeting business metrics you can't directly control.
"Either you picked something that matters but you can't move, or you picked something that you can move but doesn't actually matter."
Yamashita experimented with three approaches. First, he eliminated OKRs entirely, asking teams to articulate their philosophical headlines without measurement pressure. Second, he reintroduced OKRs with better data science support. Third, he tried renaming them "commitments" to increase psychological ownership.
"If you stop an engineer in the middle of the hallway... and ask them what are your team's biggest goals or OKRs... how many times they wouldn't be able to say [them]... they're just like 'well I'm working on this project that's really important.'"
This observation reveals the core problem: OKRs often become post-rationalization of existing work rather than driving daily decisions. When team members can't articulate their goals spontaneously, those goals aren't actually guiding behavior.
His current philosophy emphasizes three criteria for effective goals: legibility (everyone understands what it means), actionability (it inspires different behavior), and authenticity (it honestly reflects daily work). Most OKRs fail because they optimize for measurement over these practical qualities.
Hiring for High-Bandwidth UX Conversations
Technical skills are table stakes for product management roles. Yamashita's hiring philosophy focuses on softer capabilities that predict success in complex, fast-moving environments.
"One of my favorite interview questions is asking 'describe to me a time when you're part of a controversial product decision'... if they can set up this conflict and understand why this problem is really important and represent both sides... you start to feel a lot better about that person."
This question tests multiple capabilities simultaneously. Can candidates synthesize complex situations? Do they understand different stakeholder perspectives? Can they communicate controversy without taking sides? These skills matter more than specific product knowledge because they transfer across domains.
"I kind of think about... high bandwidth UX conversations... when we talk about a problem and think about potential solutions, it's kind of this tree of branches of explorations... people who can go up and down branches really quickly."
This concept captures something crucial about product conversations. Great PMs navigate between strategic altitude and tactical details fluidly. They can discuss broad user problems, zoom into specific interaction design, then zoom back out to business implications without losing thread.
"A lot of PMs... have the ability to imagine outcomes... 'let's pretend we ran that experiment, what do you think it'll come back with?'"
This forecasting ability accelerates decision-making dramatically. Teams that can reliably predict experiment outcomes avoid running experiments with obvious conclusions. They focus testing on genuine uncertainties rather than confirming hypotheses everyone already believes.
The deeper principle involves hiring for thinking speed rather than thinking depth. Product environments require rapid iteration through solution spaces. PMs who can quickly model potential outcomes, imagine user responses, and forecast technical constraints enable faster progress than those who need to research every decision thoroughly.
Community-Led Growth: Creating Controversial Champions
Everyone talks about product-led growth, but Yamashita prefers a different framework: community-led growth. The distinction reveals why some products create passionate evangelists while others remain transactional tools.
"I like to think about it more as kind of community-led growth... there are certain people inside a company that feel so strongly about Figma that they're helping push for it... those advocates are evangelizing for Figma."
Traditional product-led growth focuses on usage metrics and viral mechanics. Community-led growth focuses on emotional investment and philosophical alignment. Sales teams don't sell Figma—they empower internal champions to advocate more effectively within their organizations.
"One of the first responses we saw when Figma was 'if this is the future of design, I'm quitting... I'm changing careers.'"
This resistance signal actually indicated revolutionary potential. When products challenge existing workflows fundamentally, they create polarization. People either love the new approach or feel threatened by it. Lukewarm reception often indicates incremental improvements that won't create passionate advocacy.
"It's not just that they're advocating for a tool, they're also championing a new way of working."
This distinction explains why some B2B products inspire conference talks while others remain functional purchases. Tools that enable new workflows create intellectual frameworks people want to share. Users become thought leaders by adopting and advocating for better approaches to common problems.
The practical implication involves designing for controversy, not consensus. Products that threaten no existing workflows likely improve nothing significantly. Products that fundamentally challenge how work gets done create opportunities for users to become evangelists for better futures.
Real-time collaborative design was controversial because it challenged designer autonomy and creative ownership. But that controversy created opportunity for early adopters to champion transparency and collaborative workflows. They became missionaries for cultural change, not just software adoption.
Personal Accountability Beats Process Mandates
Most organizations approach quality through processes, metrics, and review gates. Yamashita's experience suggests personal accountability creates better outcomes than systematic approaches.
"When you are logging a bug and you add some engineers to it... the degree of motivation is so different if that engineer has somehow experienced a problem."
This observation challenges how most teams handle bug prioritization. Engineers who personally encounter issues feel embarrassed and motivated in ways that external bug reports never create. The emotional investment drives both faster fixes and better long-term thinking about user experience.
"For the most part I try not to get in the way of that because if people are doing that constantly and everyone in the company is trying to make the product better, that is sometimes way more effective than this top-down approach."
This philosophy requires courage from product leaders. Allowing engineers to fix issues they discover personally means accepting some prioritization chaos. But the quality improvements often exceed what formal processes achieve because people care more about problems they've experienced directly.
"If you ask an engineer about how much time it'll cost to build something and it's something they came up with... it's almost always half the time as something that you are asking for."
Motivation affects execution speed dramatically. Features engineers advocate for get built faster and with more creativity than features imposed by product requirements. This creates a multiplier effect where personal investment accelerates both development and innovation.
The broader principle involves designing systems that create personal stakes in outcomes. When Figma designers ship features to people they know personally in the design community, quality standards become personal reputation management rather than professional requirement compliance.
This approach scales through culture rather than process. Instead of mandating quality gates, create environments where poor quality creates personal embarrassment. Instead of tracking quality metrics, ensure everyone experiences quality problems directly when they occur.
Common Questions
Q: How do you balance vocal feedback from Twitter with representative user data?
A: Treat social media feedback as "canaries in the coal mine"—early warning signals that require validation through broader research and data analysis.
Q: What's the most important skill for product managers to develop?
A: Storytelling ability, specifically synthesis (distilling complex situations into coherent direction) and meme-ification (making insights memorable enough to influence future decisions).
Q: How do you hire great product managers?
A: Focus on controversial product decision scenarios to test perspective-taking, communication skills, and ability to represent multiple viewpoints fairly.
Q: What's wrong with traditional OKRs?
A: They often become post-rationalization of existing work rather than driving daily decisions, and optimize for measurement over authenticity and actionability.
Q: How do you create product-led growth?
A: Focus on community-led growth instead—build emotional investment and enable users to champion new ways of working, not just better tools.
Conclusion: The Human Side of Product Excellence
Yuhki Yamashita's insights reveal that product management success depends less on frameworks and processes than on human psychology and organizational culture. His approach at Figma demonstrates how emotional investment, personal accountability, and authentic communication create better outcomes than systematic approaches alone.
The most striking theme involves moving beyond mechanical product management toward deeply human approaches. Whether it's Dylan Field personally reading thousands of customer tweets, engineers feeling embarrassed about bugs they encounter personally, or sales teams empowering internal champions rather than selling directly—excellence emerges from caring, not just competence.
Yamashita's candid admission that Figma "hasn't figured everything out" and continues experimenting with goal-setting, user research, and product processes offers permission for other leaders to embrace continuous evolution rather than seeking perfect systems.
His philosophy challenges several product management orthodoxies. OKRs aren't universally effective. Product-led growth might be less important than community-led growth. Internal product usage drives quality better than external quality processes. Storytelling matters more than technical analysis for career advancement.
Most importantly, his approach demonstrates how great products emerge from organizations that prioritize human connection—to customers, to internal colleagues, and to the problems they're solving. Technical excellence follows from emotional investment, not the reverse.
Practical Implications
• Hire for storytelling ability through controversial decision scenarios — tests synthesis, perspective-taking, and communication skills that predict PM success
• Create personal accountability through internal product usage — quality improves when teams experience their own product's problems directly
• Treat social media feedback as early warning signals — balance vocal minorities with representative data rather than dismissing either source
• Focus on community-led growth over product-led growth — build emotional investment and enable users to champion new ways of working
• Own the "why" while sharing the "what" and "how" — enables autonomous decision-making by providing clear problem context
• Design for controversy, not consensus — products that challenge existing workflows create passionate evangelists rather than indifferent users
• Allow bottom-up quality improvements — engineers fixing problems they discover personally often outperforms top-down quality mandates
• Build balanced feedback portfolios across multiple channels — avoid blind spots by synthesizing support tickets, sales conversations, social media, and user research
• Evaluate goals on legibility, actionability, and authenticity — effective objectives inspire different behavior and honestly reflect daily work priorities
