How Figma builds product

Executive overview

Great product building starts with deep proximity to customers and clarity on the "why" behind every decision. At Figma, this translates to obsessive attention to community feedback, intentional product choices that inspire internal use, and a philosophy that PMs uniquely own the problem—not the solution. The core mechanism: foster genuine love for your product internally and externally, equip users with a philosophy of change (not just a tool), and let that drive authentic advocacy.

Core insight: Product leadership is storytelling—synthesizing disparate inputs into a memorable, actionable narrative that compels both teams and customers.

The power of storytelling in product leadership

Storytelling is the single most instrumental habit in Yuki's career, and he teaches it relentlessly. The skill has two facets:

• Synthesis: Distill multiple opinions, data points, and observations into a cohesive thesis—similar to literary analysis
• Memification: Create insights so memorable that executives cite them in meetings months later
• Escape the curse of knowledge: Reset context as if explaining to someone with zero background, then work back up
• Teaching is the best training ground—forcing yourself to explain pointers to computer science students teaches clear communication

PM ownership of the "why" over what and how

PMs don't own the what or how (teams do), but must own the underlying problem and motivation. This discipline emerged when Yuki moved from Microsoft's spec-driven culture to YouTube's distributed decision-making:

• Without clear "why," engineers and designers make isolated decisions that don't align
• Asking "why do they have that problem?" goes one level deeper than the feature request
• Five whys (borrowed from engineering post-mortems) uncovers root causes and unblocks bigger product opportunities

Obsessive proximity to customer feedback

Figma maintains a unique channel called "Concerning Tweets"—Dylan reads customer feedback more than anyone and drops tweets (sometimes zero engagement) that smell like truth:

• View tweets and feedback as canaries in the coal mine, not gospel
• Balance vocal minorities with broader data from support tickets, sales conversations, and research
• Research and data functions prevent blind spots; one dimension alone is insufficient
• Early success came from intentional targeting of influential designers on Twitter as go-to-market

Using your own product ruthlessly

The single most important lever for product quality is getting your entire company to use the product constantly:

• Switch from memo to deck culture so PMs build decks in Figma and encounter real issues
• Use FigJam for HR calibrations, performance reviews—any company process—to maximize internal usage
• Personal accountability spikes when someone using a tool is embarrassed by bugs
• Designers inside Figma feel personally accountable because their customers are often people they know on Twitter

Bottoms-up energy and intrinsic motivation

Engineers spotting broken things and fixing them without roadmap approval is often more effective than top-down quality initiatives:

• Motivation to fix self-identified problems is always higher than motivation for assigned work
• Avoid gating genuine customer-driven fixes behind roadmaps
• Engineers are willing to invest more effort when they identify and advocate for a problem themselves

The long experiment with OKRs and goal-setting

Figma has cycled through multiple goal-setting approaches. The core frustration: poorly designed OKRs feel performative and disconnected from day-to-day work.

• First issue: OKRs treated as task lists or check-boxes rather than true commitments
• Second issue: Secondary metrics that don't correlate to business outcomes; business metrics with no direct control
• Current philosophy: Three properties matter more than naming convention
  • Legibility: People understand what it means
  • Actionability: It stirs action and changes behavior
  • Authenticity: It honestly reflects what you're actually doing day to day
• Experiments tried: Deprecate metrics entirely and use headlines → brought back rigor with data team → now labeling goals as "commitments" to increase ownership

What sets Figma apart in hiring PMs

Yuki's favorite interview question: "Describe a controversial product decision you were part of. What did you do?" This reveals:

• Can they set up a genuine conflict and represent both sides fairly?
• Do they maintain an even-keeled perspective while navigating tension?
• Can they take on different stakeholder perspectives simultaneously?

Other signals: Strong PMs are storytellers who compel you to care about their problem. They can move fluidly between problem altitude and solution details. They can "fast-forward to the future" (imagine experiment outcomes) to avoid unnecessary research.

Product-led growth as community-led growth

Figma doesn't really grow via product-led growth—it grows via "community-led growth." Internal champions (designers) are the real salespeople:

• Sales team empowers internal champions with data, stories, and credibility to make internal cases
• The magic: Help designers evangelize internally by connecting them to peers and equipping them with ammunition
• Organic community (Friends of Figma in Discord) creates human connections that fuel loyalty
• Figma normalized file-sharing as open-sourcing your process, creating visibility into how other companies work

Growth lessons for product-led founders

Irrational emotional love (not just utility) drives sustainable growth:

• Product must solve a real problem deeply
• Equip customers with a philosophy or vision for change, not just a tool
• Some of Figma's early power came from controversy—"if this is the future of design, I'm quitting"—that signaled revolution
• Community-led growth requires authentic internal love first (people must believe it); external advocacy follows

Handling products beyond internal dogfooding

As Figma scales beyond its core designer audience, they've built products (design systems, branching) that don't fit internal workflows:

• Heavy reliance on internal dogfooding limits feedback for enterprise or niche use cases
• Expansion requires creative approaches: research, data science, forums, and support insights
• Building features for audiences you don't represent requires more deliberate measurement and feedback loops

Working with leadership: CEO dynamics

Dylan Field and Yuki are very different. Dylan is intuition-driven (informed by decades of customer interactions), while Yuki is logic-tree driven:

• Dylan needs to see end implementation to feel if a solution works—he won't buy in at the planning stage
• Dylan obsessively reads customer feedback and notices single tweets with zero engagement if he senses truth
• Building logic trees around Dylan's intuitions helps scale his insights across teams
• Dylan's level of personal accountability (asking random users about their problems in his own home) sets the company tone