An inside look at how Figma builds product | Yuhki Yamashita (CPO of Figma) — Lenny's Podcast: Product | Career | Growth Summary

An inside look at how Figma builds product | Yuhki Yamashita (CPO of Figma) — Lenny's Podcast: Product | Career | Growth Summary | Galaxy of Podcasts

The Conversation Breakdown

Use storytelling to synthesize the problem

⏱ Untimed topic

Yamashita describes taking scattered observations, opinions and problems and turning them into a coherent lens. Storytelling in this sense is about making the reasoning understandable, not adding decoration. A team can use that synthesis to see what connects the different pieces of work.

Take responsibility for why the work matters

⏱ Untimed topic

He says ideas and implementation can be shared across the company, while holding the PM responsible for the why. A clear reason helps designers and engineers make choices without an exhaustive specification. The value is in making purpose usable, not claiming the PM originates every idea.

Go beyond the requested feature

⏱ Untimed topic

Yamashita suggests asking why a customer wants a feature, then asking why the underlying problem exists. That second step may reveal a broader opportunity. The requested solution is useful evidence, but it need not define the entire problem space.

Return with feedback reflected in the product

⏱ Untimed topic

In his account of Figma's early work, designers saw the product repeatedly and their feedback shaped later versions. The interaction was about listening rather than expecting immediate adoption. The example connects ongoing feedback with building a stronger relationship to the community.

Treat a public complaint as a clue, not the whole picture

⏱ Untimed topic

He describes small complaints as possible signals of a deeper issue. They can be worth investigating even when few people engage with them. A complaint is an input to research, not proof that everyone has the same experience.

Gather a balanced set of feedback sources

⏱ Untimed topic

Yamashita distinguishes support tickets, sales conversations, public discussion, research and data. Each source can overrepresent a different kind of experience. A balanced set helps the team notice blind spots instead of relying only on the most visible voices.

Avoid turning every leadership observation into an emergency

⏱ Untimed topic

He describes a smaller channel for concerning feedback so the broader team did not feel it had to drop everything for every shared post. The structure retained attention to potential issues while adding a step for interpretation. Preserve the signal without automatically replacing the current priorities.

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

Executive Summary (TL;DR)

Key Takeaways

Use storytelling to synthesize the problem

Take responsibility for why the work matters

Go beyond the requested feature

Return with feedback reflected in the product

Treat a public complaint as a clue, not the whole picture

Gather a balanced set of feedback sources

Avoid turning every leadership observation into an emergency

The Conversation Breakdown

Use storytelling to synthesize the problem

Take responsibility for why the work matters

Go beyond the requested feature

Return with feedback reflected in the product

Treat a public complaint as a clue, not the whole picture

Gather a balanced set of feedback sources

Avoid turning every leadership observation into an emergency

Core Frameworks & Ideas

Why behind the request

Balanced feedback portfolio

Signal before urgency

Actionable Next Steps

Notable Quotes

The One Thing to Remember