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

Figma has established itself as one of the most critical tools in the modern design stack, fundamentally changing how teams collaborate. But behind the sleek interface and multiplayer capabilities lies a unique product culture driven by experimentation, deep user empathy, and a willingness to break standard management rules. Yuhki Yamashita, Chief Product Officer at Figma, offers a rare glimpse into the machinery of a design unicorn.

With a diverse background spanning product leadership at Uber and YouTube, as well as a stint as a computer science instructor at Harvard, Yamashita brings a rigorous yet human-centric approach to software development. His philosophy bridges the often-siloed worlds of engineering, design, and product management, offering a blueprint for building software that users don’t just utilize, but genuinely love.

Key Takeaways

• The PM owns the "Why": While engineering and design can determine the "how" and "what," the Product Manager must rigorously define and own the problem statement.
• Storytelling is synthesis: Great leadership isn't just about presentation; it is about synthesizing complex inputs into "meme-ifiable" insights that stick with the team.
• Dogfooding drives quality: Figma replaced written memos with slide decks built in Figma to force the entire company to experience the product’s friction points daily.
• OKRs require authenticity: After struggling with performative metrics, Figma shifted toward "commitments"—goals that are legendary, actionable, and authentic.
• Community is the growth engine: Product-led growth is actually community-led growth; success comes from equipping internal champions to be heroes within their own organizations.

The Product Manager’s Core Responsibility: Owning the "Why"

In many organizations, the definition of a Product Manager’s role can become muddy. Are they project managers? Are they feature definers? At Figma, the distinction is clear: the PM is the guardian of the "Why."

Yamashita contrasts his early career experience at Microsoft—where "feature crews" required exhaustive specifications covering every possible error state—with the culture at Figma. In a fast-moving environment, it is impossible for a PM to dictate every pixel or edge case. Instead, the team relies on designers and engineers to make high-quality micro-decisions. For those decisions to be correct, the underlying problem statement must be crystal clear.

"I really always hold the PM uniquely responsible for the why... 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."

Figma applies this rigor through a "Five Whys" approach, traditionally used in engineering post-mortems. When a customer asks for a feature, the product team peels back the layers to understand the root friction. By solving the foundational issue rather than the surface-level request, the team delivers solutions that are robust and scalable.

Storytelling as a Strategic Lever

One of the most underrated skills in product leadership is storytelling. Yamashita argues that storytelling is not merely about charisma or public speaking; it is an exercise in synthesis and empathy. A PM is constantly bombarded with disparate data points, stakeholder opinions, and user feedback. Success lies in distilling that noise into a coherent narrative.

The Concept of "Meme-ification"

In a distracted corporate world where leaders have limited attention spans, insights must be memorable. Yamashita introduces the concept of "meme-ification." A product manager or researcher has succeeded when their insight is so punchy and resonant that it is repeated verbatim by executives in meetings, effectively becoming a company meme. This transfer of knowledge ensures that the core user truth travels efficiently across the organization.

Resetting the Context

Effective storytelling also requires the "curse of knowledge" escape. Yamashita coaches his PMs to reset their internal context before presenting, assuming the audience knows nothing about the project's history. This forces the storyteller to build a logical, accessible argument from the ground up, ensuring that the narrative lands with engineers, executives, and designers alike.

Radical Quality Through Dogfooding and Proximity

Figma’s reputation for quality isn't accidental; it is the result of aggressive "dogfooding" (using one’s own product). However, Yamashita takes this beyond the standard practice of occasional testing. He implements structural changes to force the product into employees' daily workflows.

Upon joining Figma, Yamashita shifted the company culture from written memos to decks. The catch? The decks had to be built inside Figma. This forced Product Managers, who might otherwise live in document editors, to use Figma’s tools for layout, typography, and collaboration. This exposure creates a sense of personal accountability.

"If an engineer working on the driver app [at Uber] saw a driver struggling with something, they would find it embarrassing and kind of feel personally accountable to go and fix that... When you can create that sense of personal accountability, then all this progress happens."

Managing Feedback at Scale

Staying close to the customer becomes harder as a company scales. Figma’s CEO, Dylan Field, is known for his obsession with customer feedback, often dropping isolated tweets into company Slack channels. To manage this without causing fire drills, the team created a "Concerning Tweets" channel. This serves as a canary in the coal mine—a place to discuss potential sentiment shifts or emerging bugs without deriving strategy from a single data point. It balances the "vocal minority" on Twitter with the broader, quieter user base found in support tickets and sales calls.

A Dynamic Approach to OKRs and Planning

Goal setting is often a source of friction for product teams. Yamashita admits to a "love-hate relationship" with OKRs (Objectives and Key Results). In many companies, OKRs become performative—teams set safe goals they know they can hit, or select secondary metrics that don't actually correlate with business success.

Figma has experimented with various iterations of planning:

1. Headlines only: Removing metrics entirely to focus on the philosophical goal of a project.
2. Report cards: Allowing teams to grade themselves qualitatively to encourage honesty over metric gaming.
3. Commitments: A shift in terminology to emphasize the promise made to the user and the business.

Regardless of the specific framework used, Yamashita insists that any goal-setting mechanism must satisfy three criteria:

• Legendary: The goal must be easily understood by anyone in the company without explanation.
• Actionable: Reading the goal should inspire immediate action and clarify what needs to be done.
• Authentic: The goal must honestly reflect the team’s day-to-day work, not serve as a "post-rationalization" of projects they intended to do anyway.

Community-Led Growth

Figma is frequently cited as the gold standard for Product-Led Growth (PLG). However, Yamashita views it more accurately as "Community-Led Growth." The software didn't just spread because it was a good tool; it spread because it represented a philosophical shift in how design should happen—open, collaborative, and transparent.

Early on, this shift was controversial. Many designers feared that real-time collaboration would lead to micromanagement ("design by committee"). Figma leaned into this tension, framing the product not just as a tool, but as a movement. By winning over individual designers and making them feel like part of a revolution, Figma created internal champions.

The role of the sales and product teams, therefore, is to equip these internal champions with the data, stories, and templates they need to sell Figma to their own bosses. Growth is driven by love for the product, which translates into advocacy.

Conclusion

Figma’s approach to building product is characterized by a refusal to stagnate. Whether it is iterating on how they write specs, how they set goals, or how they gather feedback, the team operates with a "work in progress" mindset. By maintaining a high "bandwidth" for UX discussions, prioritizing storytelling, and fostering deep personal accountability for the product experience, Figma has managed to scale without losing the craftsmanship that defined its early years.

For product leaders, the lesson is clear: standard frameworks are useful starting points, but building a legendary product requires adapting those processes to fit the unique culture and mission of the team.