Yuhki Yamashita
Chief Product Officer at Figma, formerly Head of Design for New Mobility at Uber and PM at Google and Microsoft
Where to hear and read about Yuhki Yamashita1 episode or test
Yuhki Yamashita is Chief Product Officer at Figma, after product and design roles at Microsoft, Google (YouTube) and Uber. The thing most worth learning from him is that product quality comes from keeping every builder close to real users and responsible for the why.
The more hours people are spending inside your product internally, I think it just naturally becomes better.
An inside look at how Figma builds product | Yuhki Yamashita (CPO of Figma)
Yuhki Yamashita: the story and the lessons
1Yuhki Yamashita's path from Microsoft to Figma
Yamashita learned product in three very different company cultures before Figma. His first job was a Hotmail PM role at Microsoft, chosen because product exposed him to every other function. He then led the iOS app at YouTube and later worked at Uber.
YouTube's style of product management shaped his working habits, and Uber's fast-moving setting shaped his philosophy of building products.
He led YouTube's iOS app without ever having used an iPhone. He had never touched an iPhone before his first day. Earlier he worked on Windows 8, a touch-first Windows, which pulled him into UI and UX conversations.
He moved from PM to design at Uber, and that led him to Figma. He managed design teams on bikes and scooters to learn what design work is like. He also ran an experiment that brought Figma into Uber, which was trying to be more transparent and inclusive.
He watched how Figma changed the way people worked and spread inside the company. He liked that it blurred the line between design and product, which he had straddled his whole career.
Leading designers gave him empathy for the other side of the table. A PM sits in the center weighing trade-offs, while a designer must set those aside and insist on the best experience. He coached designers on how to win over PMs and speak their language.
He doesn't recommend the switch for everyone, only for people who really want to do it.
He found managing designers harder than managing PMs. Designers need to grow their craft, but the company's biggest problem may not be the place to learn a given skill. PMs just want impact, so a manager can point them at the biggest problems.
An onboarding funnel, for example, may be the wrong place to learn micro interactions. He thinks the same is probably true for engineers.
2Yamashita on storytelling and owning the why
He says much of being a great PM is being a great storyteller. It starts with synthesis: turning many inputs into one message that moves a project forward. Even an early-career PM taking meeting notes is doing this.
He learned it in literature classes, turning observations about a Yeats poem into one cohesive thesis. Storytelling shows up in the performance review of everyone who has reported to him.
He turns research and data into memes that leaders repeat. People give about 30 seconds of attention at a time, so a story has to stick. At Uber, some insights became memes that Travis or Dara would cite mid-meeting.
He sees this as how knowledge moves through a company. When leaders question him, he asks what story or meme they are building in their heads about the project.
He tells his story as if the listener has zero context. PMs are caught in the middle of everything, so their context stops being obvious. He resets and rebuilds the story from nothing, as a user who knows nothing but wants the nuance.
He learned this as a computer science course assistant, explaining pointers with real-world metaphors. Once you can tell it to someone with no context, closer audiences become much easier.
He holds the PM uniquely responsible for the why. Ideas can come from customers, engineers or designers, but the PM owns the reason something is worth building. Microsoft specs covered every case, while at YouTube one PM could not specify everything.
A shared understanding of the problem was the only way to scale local decisions. In his words: "the why is something that I really always hold the PM uniquely responsible for".
He adds one more step to Figma's five whys for PMs. Figma engineering runs five whys in retros and postmortems on things that went wrong. PMs can go from the requested feature to the problem behind it, then ask why the customer has that problem at all.
That deeper layer can turn out to be a bigger product opportunity.
3How Yamashita reads customer feedback at Figma
Figma asks its community in public but never builds their answers verbatim. The team tweets what it is considering, such as a bigger focus on prototyping, and asks for the top problems. Passionate users reply with many different answers.
The goal is a pulse on how people feel, not a feature list.
A private 'concerning tweets' channel triages weak signals from Dylan Field. Dylan has read customer feedback for about a decade and drops low-like tweets into Slack because he senses truth in them. That made teams feel they had to drop everything, so Yamashita and a colleague moved them to a small group.
The group checks whether a bigger pattern sits underneath. Tweets are treated as canaries in the coal mine, not verdicts.
He balances the vocal minority against a portfolio of other feedback. Support tickets skew toward dissatisfied customers, and sales conversations reveal how prospects perceive Figma. Many designers are on Twitter, but most of Figma's audience is not.
He built the research and data functions to get insight from those other sources, so PMs have no blind spots.
4Working with Dylan Field's intuition
Yamashita makes Dylan Field's customer-built intuition explainable to the company. Dylan's intuition comes from hundreds of thousands of customer interactions. Yamashita fills in the logic tree for how Dylan reached a conclusion, so people can follow it at scale.
Dylan struggles to buy in step by step and needs to see the end implementation to feel whether a solution is good. A PM would rather set out the problem, three approaches and a review at each step.
Field treats every single user as worth attention. During the pandemic, on a walking one-on-one, Dylan stopped at Yamashita's house and met his partner, who was working in Figma. He asked what wasn't working, and they geeked out over a Google Fonts issue.
Dismissing one user as a single case is easy. Yamashita says Dylan does not.
5Why Yamashita wants everyone at Figma using Figma
He makes the whole company use the product every day. He moved PMs from memos to decks so they build them in Figma, and a FigJam template for performance calibrations went out through HR. FigJam now also runs interview debriefs and product reviews.
Designers spend about six hours a day in the product. People are not mainly raising hands to report bugs; they want their own workflows to be better.
He builds personal accountability by connecting builders with real users. At Uber, engineers who saw a driver struggle felt embarrassed and fixed the problem. Engineer-owned fixes tend to be estimated at about half the time of PM-assigned ones.
Figma designers know their customers from the community and Twitter, so they ship work they can defend. Uber staff rode Ubers to work, and the driver-side team went out driving.
He stays out of the way of engineers fixing what they notice. Bottom-up energy is one of the most powerful things in a startup, and it catches things a defined quality metric would miss. Asked whether a PM would block a fix to protect the roadmap, he says "by all means" for a real customer problem.
When developers are personally invested in a problem, their willingness and creativity spike.
He admits dogfooding fails for features built for customers unlike Figma. Branching and merging for design systems was a big investment that customers asked for, yet saw little early adoption. Causes included performance, an unfamiliar workflow and gaps Figma missed because it barely uses the feature.
As Figma serves organizations unlike itself, he says the team needs a new muscle for judging how well features work.
6How Yamashita describes Figma's community-led growth
Figma began by building with designers and listening to them. Dylan Field kept putting the product in front of designers and came back with their feedback built in. He never expected them to adopt it at work.
Dylan also mapped the most influential designers on Twitter, was deliberate about whom to win over, and open sourced his code.
He equips champions inside companies instead of selling around them. The base of Figma's growth is the internal designer, not the sales team. Sales builds human connections and gives the champion data and stories, while product shares how the product is evolving and what other customers do.
He calls this community-led growth and sees it as a partnership to enable the champion as much as possible.
He says users champion a new way of working, not just a tool. Seeing everyone's work, or many designers in one file, felt threatening at first. One early reaction was "if this is a future of design, I'm quitting".
He reads that tension as a signal that you are changing something and are part of a revolution.
He credits intentional community building for much of the early traction. Designers can share a file and effectively open source it, showing how their company works, which draws others in. Friends of Figma has fans in different regions meeting in a Discord channel.
The loyalty from that human contact gives champions the enthusiasm and courage to push for Figma in skeptical organizations.
7Yamashita's search for goals people believe in
He says OKRs tend to be either unmovable or meaningless. A survey satisfaction score can be moved, but nobody showed it correlates with retention. A rider-experience team promising incremental trips can't prove it moved a number many hops away.
On core-experience teams at Uber, OKRs felt performative, and review meetings were dreadful because nobody could tell what the team cared about.
He asks teams for a headline goal first and measurement second. Teams state what they are optimizing for, even if it can't be measured yet. A report card works too: give yourself a score and explain how you got it.
A new head of data, also from Uber, found this too subjective, so OKRs returned with more rigor. The new problem was that OKRs read as after-the-fact labels.
He judges a goal by whether it is legible, actionable and authentic. Legible means people understand it without an obscure metric. Actionable means it makes you want to do something differently, and authentic means it honestly describes the team's day-to-day work.
If an engineer stopped in the hallway can't name the team's goals, they aren't working. Figma tried calling them commitments, and he says they haven't cracked it yet.
8How Yamashita hires and decides
He interviews PMs by asking about a controversial product decision. A strong candidate sets up the conflict and presents both sides evenly. A candidate who can't take other perspectives worries him.
After hearing about a big problem, he asks himself whether he feels compelled to work on it. A great PM can make even a boring problem sound exciting.
He asks teams to fast-forward to an experiment's result before running it. Borrowing from Uber's first chief product officer Jeff Holden, he asks what an experiment will come back with. If nobody expects the result to change what they do, they skip the work.
He says deciding not to build something matters as much as deciding what to build.
He uses an alignment scale in FigJam to find hot spots fast. People click a widget to place their face between aligned and not aligned. If everyone is aligned, the team moves on; if not, the topic is worth discussing.
Figma uses it in product reviews and pulse checks.
An inside look at how Figma builds product | Yuhki Yamashita (CPO of Figma)
Figma's CPO explains how the company keeps product quality high through storytelling, owning the why, staying close to the community, and using its own product everywhere. He also walks through Figma's messy OKR experiments and how community-led growth works in practice.
Yamashita learned product in three very different company cultures before Figma. His first job was a Hotmail PM role at Microsoft, chosen because product exposed him to every other function. He then led the iOS app at YouTube and later worked at Uber.
YouTube's style of product management shaped his working habits, and Uber's fast-moving setting shaped his philosophy of building products.
He led YouTube's iOS app without ever having used an iPhone. He had never touched an iPhone before his first day. Earlier he worked on Windows 8, a touch-first Windows, which pulled him into UI and UX conversations.
He moved from PM to design at Uber, and that led him to Figma. He managed design teams on bikes and scooters to learn what design work is like. He also ran an experiment that brought Figma into Uber, which was trying to be more transparent and inclusive.
He watched how Figma changed the way people worked and spread inside the company. He liked that it blurred the line between design and product, which he had straddled his whole career.
Leading designers gave him empathy for the other side of the table. A PM sits in the center weighing trade-offs, while a designer must set those aside and insist on the best experience. He coached designers on how to win over PMs and speak their language.
He doesn't recommend the switch for everyone, only for people who really want to do it.
He found managing designers harder than managing PMs. Designers need to grow their craft, but the company's biggest problem may not be the place to learn a given skill. PMs just want impact, so a manager can point them at the biggest problems.
An onboarding funnel, for example, may be the wrong place to learn micro interactions. He thinks the same is probably true for engineers.
He says much of being a great PM is being a great storyteller. It starts with synthesis: turning many inputs into one message that moves a project forward. Even an early-career PM taking meeting notes is doing this.
He learned it in literature classes, turning observations about a Yeats poem into one cohesive thesis. Storytelling shows up in the performance review of everyone who has reported to him.
He turns research and data into memes that leaders repeat. People give about 30 seconds of attention at a time, so a story has to stick. At Uber, some insights became memes that Travis or Dara would cite mid-meeting.
He sees this as how knowledge moves through a company. When leaders question him, he asks what story or meme they are building in their heads about the project.
He tells his story as if the listener has zero context. PMs are caught in the middle of everything, so their context stops being obvious. He resets and rebuilds the story from nothing, as a user who knows nothing but wants the nuance.
He learned this as a computer science course assistant, explaining pointers with real-world metaphors. Once you can tell it to someone with no context, closer audiences become much easier.
He holds the PM uniquely responsible for the why. Ideas can come from customers, engineers or designers, but the PM owns the reason something is worth building. Microsoft specs covered every case, while at YouTube one PM could not specify everything.
A shared understanding of the problem was the only way to scale local decisions. In his words: "the why is something that I really always hold the PM uniquely responsible for".
He adds one more step to Figma's five whys for PMs. Figma engineering runs five whys in retros and postmortems on things that went wrong. PMs can go from the requested feature to the problem behind it, then ask why the customer has that problem at all.
That deeper layer can turn out to be a bigger product opportunity.
Figma asks its community in public but never builds their answers verbatim. The team tweets what it is considering, such as a bigger focus on prototyping, and asks for the top problems. Passionate users reply with many different answers.
The goal is a pulse on how people feel, not a feature list.
A private 'concerning tweets' channel triages weak signals from Dylan Field. Dylan has read customer feedback for about a decade and drops low-like tweets into Slack because he senses truth in them. That made teams feel they had to drop everything, so Yamashita and a colleague moved them to a small group.
The group checks whether a bigger pattern sits underneath. Tweets are treated as canaries in the coal mine, not verdicts.
He balances the vocal minority against a portfolio of other feedback. Support tickets skew toward dissatisfied customers, and sales conversations reveal how prospects perceive Figma. Many designers are on Twitter, but most of Figma's audience is not.
He built the research and data functions to get insight from those other sources, so PMs have no blind spots.
Yamashita makes Dylan Field's customer-built intuition explainable to the company. Dylan's intuition comes from hundreds of thousands of customer interactions. Yamashita fills in the logic tree for how Dylan reached a conclusion, so people can follow it at scale.
Dylan struggles to buy in step by step and needs to see the end implementation to feel whether a solution is good. A PM would rather set out the problem, three approaches and a review at each step.
Field treats every single user as worth attention. During the pandemic, on a walking one-on-one, Dylan stopped at Yamashita's house and met his partner, who was working in Figma. He asked what wasn't working, and they geeked out over a Google Fonts issue.
Dismissing one user as a single case is easy. Yamashita says Dylan does not.
He makes the whole company use the product every day. He moved PMs from memos to decks so they build them in Figma, and a FigJam template for performance calibrations went out through HR. FigJam now also runs interview debriefs and product reviews.
Designers spend about six hours a day in the product. People are not mainly raising hands to report bugs; they want their own workflows to be better.
He builds personal accountability by connecting builders with real users. At Uber, engineers who saw a driver struggle felt embarrassed and fixed the problem. Engineer-owned fixes tend to be estimated at about half the time of PM-assigned ones.
Figma designers know their customers from the community and Twitter, so they ship work they can defend. Uber staff rode Ubers to work, and the driver-side team went out driving.
He stays out of the way of engineers fixing what they notice. Bottom-up energy is one of the most powerful things in a startup, and it catches things a defined quality metric would miss. Asked whether a PM would block a fix to protect the roadmap, he says "by all means" for a real customer problem.
When developers are personally invested in a problem, their willingness and creativity spike.
He admits dogfooding fails for features built for customers unlike Figma. Branching and merging for design systems was a big investment that customers asked for, yet saw little early adoption. Causes included performance, an unfamiliar workflow and gaps Figma missed because it barely uses the feature.
As Figma serves organizations unlike itself, he says the team needs a new muscle for judging how well features work.
Figma began by building with designers and listening to them. Dylan Field kept putting the product in front of designers and came back with their feedback built in. He never expected them to adopt it at work.
Dylan also mapped the most influential designers on Twitter, was deliberate about whom to win over, and open sourced his code.
He equips champions inside companies instead of selling around them. The base of Figma's growth is the internal designer, not the sales team. Sales builds human connections and gives the champion data and stories, while product shares how the product is evolving and what other customers do.
He calls this community-led growth and sees it as a partnership to enable the champion as much as possible.
He says users champion a new way of working, not just a tool. Seeing everyone's work, or many designers in one file, felt threatening at first. One early reaction was "if this is a future of design, I'm quitting".
He reads that tension as a signal that you are changing something and are part of a revolution.
He credits intentional community building for much of the early traction. Designers can share a file and effectively open source it, showing how their company works, which draws others in. Friends of Figma has fans in different regions meeting in a Discord channel.
The loyalty from that human contact gives champions the enthusiasm and courage to push for Figma in skeptical organizations.
He says OKRs tend to be either unmovable or meaningless. A survey satisfaction score can be moved, but nobody showed it correlates with retention. A rider-experience team promising incremental trips can't prove it moved a number many hops away.
On core-experience teams at Uber, OKRs felt performative, and review meetings were dreadful because nobody could tell what the team cared about.
He asks teams for a headline goal first and measurement second. Teams state what they are optimizing for, even if it can't be measured yet. A report card works too: give yourself a score and explain how you got it.
A new head of data, also from Uber, found this too subjective, so OKRs returned with more rigor. The new problem was that OKRs read as after-the-fact labels.
He judges a goal by whether it is legible, actionable and authentic. Legible means people understand it without an obscure metric. Actionable means it makes you want to do something differently, and authentic means it honestly describes the team's day-to-day work.
If an engineer stopped in the hallway can't name the team's goals, they aren't working. Figma tried calling them commitments, and he says they haven't cracked it yet.
He interviews PMs by asking about a controversial product decision. A strong candidate sets up the conflict and presents both sides evenly. A candidate who can't take other perspectives worries him.
After hearing about a big problem, he asks himself whether he feels compelled to work on it. A great PM can make even a boring problem sound exciting.
He asks teams to fast-forward to an experiment's result before running it. Borrowing from Uber's first chief product officer Jeff Holden, he asks what an experiment will come back with. If nobody expects the result to change what they do, they skip the work.
He says deciding not to build something matters as much as deciding what to build.
He uses an alignment scale in FigJam to find hot spots fast. People click a widget to place their face between aligned and not aligned. If everyone is aligned, the team moves on; if not, the topic is worth discussing.
Figma uses it in product reviews and pulse checks.
More from Figma
GuestDylan Field
Co-founder and CEO of Figma
Figma2 sources · 30 tips
GuestClaire Butler
Senior Director of Marketing at Figma; first GTM hire and 10th employee
Figma1 source · 18 tips
GuestMihika Kapoor
Product manager (design, engineering and PM hybrid) at Figma, early PM on FigJam
Figma1 source · 17 tips