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

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.

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.

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.

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.

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.

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.

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.