好产品经理首先是讲故事的人：Figma 产品负责人如何持续做出好产品

Yamashita traces his career from product manager on Hotmail and Windows at Microsoft, to leading the YouTube iOS app, to Uber, and then to Figma. At Uber he moved from product into design, managing teams for the company's bikes and scooters. He had brought Figma into Uber experimentally as part of a push for a more transparent, inclusive culture, and was drawn to how Figma blurred the boundary between design and product.

He recommends a stint in design only for those who are passionate about it, but says it builds empathy and lets a PM push for the best experience without balancing every trade-off. It also helps each discipline learn the other's language; he coached designers on how to win over PMs. He finds managing designers harder than managing PMs because designers need to grow their craft, which may not match the company's biggest problem, while PMs are simply hungry for impact.

Asked for the one habit behind his success, Yamashita names storytelling, and says it shows up in the performance reviews of anyone who has reported to him. The first element is synthesis: distilling the many opinions in a review into a message and a direction, which he compares to turning observations about a poem into a thesis. He also loves offering frameworks, which are another form of synthesis.

The second element is that a story is only as good as the action it drives. Because people give only about 30 seconds of attention at a time, insights must be memorable. At Uber, he says, some data and research insights were "memeified" so well that leaders would cite them unprompted in meetings.

To improve, he suggests resetting your mental context and imagining a user who knows nothing but wants to understand the nuance. He learned this partly by teaching a computer science course, where explaining pointers required grounding metaphors. If you can tell a story to someone with no context, he says, it becomes easier to reach every closer audience.

Yamashita says the PM does not have to come up with the idea, since customers and teammates offer plenty, and the what and how are shared. But the why is the part he holds the PM uniquely responsible for. He learned this at YouTube after Microsoft, where specs had to be perfect and specified every error-handling table; at YouTube he was responsible for a whole app and could not specify everything.

If everyone understands why the team is doing something and what problem it solves, people can make good local decisions without the PM, which he calls the only way to scale. Figma's engineers use the five whys in postmortems after something goes wrong, to find root causes. Yamashita thinks PMs can apply the same method to customer requests, and take one more step by asking why the customer has the problem in the first place, which may reveal a bigger opportunity.

Yamashita ties Figma's customer proximity to its origin. When few believed a design editor could work in the browser, the founder, Dylan Field, repeatedly put the product in front of designers, implemented their feedback and came back, with no assumption that they would adopt it. That listening turned the community into evangelists and shaped the product.

Team members tweet questions to the community, and Field has read the most customer feedback of anyone for a decade. When he began dropping concerning tweets into Slack channels, people felt compelled to drop everything, so Yamashita and the CTO created a private "Concerning Tweets" channel for a small group. These are often tweets with one or zero likes that Field feels contain an essence of truth.

As research and data functions grew, Yamashita stresses balancing the vocal minority with other inputs. Tweets are canaries in the coal mine, support tickets skew dissatisfied, and sales conversations reveal perceptions of Figma. Most of Figma's audience is not on Twitter, so he wanted capabilities for extracting insight from other sources.

Describing Field, Yamashita says they are very different. Field works from intuition built on hundreds of thousands of customer interactions, and part of Yamashita's job is to build out the logic of how he reached a conclusion so that others can follow. Field often has to see an implementation to feel whether a solution is right, but it is not random.

He tells a story from the height of the pandemic: during a walking one-on-one, Field used the bathroom at Yamashita's home, saw his partner using Figma, and immediately started asking about the biggest problems. They ended up geeking out about Google fonts. For Yamashita this shows that Field cares deeply about any single user, and that obsession informs his intuition.

Not everything works, Yamashita says. Branching and merging for design systems made sense and had been requested by customers, yet adoption was initially low because of performance problems and the unfamiliar workflow, and the team found gaps because it does not use the feature much itself. As Figma grows it builds features for organizations unlike itself, so it must find new ways to evaluate them beyond internal dogfooding.

His main answer on quality is to use your own product. He pushed Figma from a memo culture to a deck culture so PMs would build decks in Figma, and the company recently ran performance calibrations in FigJam using a template from the Head of Design. He adds that engineers are far more motivated to fix a problem they have experienced, as Uber engineers did when they saw drivers struggle, and Figma designers feel accountable because their customers are people they know in the community.

He tries not to block bottom-up fixes, since an engineer who notices something broken can improve quality better than a top-down quality metric. He also notes that engineers' estimates for work they advocate for are usually about half what they would be for something a PM asks for.

Yamashita calls his relationship with OKRs love-hate. On core experiences you either choose a secondary metric nobody has proved matters, or you anchor to a business metric you cannot control and cannot show you moved. At Figma, he found people treating OKRs as to-do lists, with dreadful review meetings where he could not tell what teams cared about.

He deprecated them and asked teams for a headline of what they were philosophically trying to do, measurable or not, even suggesting a self-scored report card. After a Head of Data joined, OKRs came back with more rigor, but they looked like post-rationalizations, and engineers could not name their team's goals. The company then experimented with calling them commitments, which sit between the why and the what.

His three criteria for a good one are legibility, actionability and authenticity, meaning it honestly reflects what the team is doing day to day. He admits Figma has not cracked the code. Lenny praises hearing the full journey of experiments rather than only the current process.

Figma has about 22 product managers, according to Lenny. Yamashita says one of his favorite interview questions is to describe a time you were part of a controversial product decision. A strong candidate can represent both sides of the conflict in an even-keeled way. He also asks about a big problem the candidate worked on, and wants to feel compelled by it however boring it sounds, because good PMs can explain why it was existential.

He also looks for people who move quickly up and down the tree of solution branches and talk at many altitudes. Citing Uber's first Chief Product Officer, Jeff Holden, he values the ability to fast-forward to the future, imagining what an experiment would show, so teams skip work that would not change a decision. Deciding not to build something is as important as deciding what to build.

Yamashita says Figma has a sales team that knows the product well and has credibility with design and product leaders. He prefers to call the growth community-led: certain people inside a company feel strongly about Figma and push for it. Sales empowers them with data, stories and connections to broaden deployment, so the most powerful spreader of Figma is the internal designer rather than the salesperson.

Early on, he credits intentional community building, including files shared publicly as a way to show how a company works. More recently Figma has run a program called Friends of Figma, where enthusiasts from many geographies meet in a Discord channel. He says there must be an almost irrational emotional love for the product, cultivated internally first, and that Figma also equipped people with a philosophy of a new way of working, one that provoked reactions like "if this is the future of design, I'm quitting."

Asked about the pending Adobe acquisition, which had not closed, Yamashita says he does not yet know what will change. He is excited about making product design more seamless for people who juggle Adobe tools like After Effects, Illustrator and Photoshop alongside Figma, and about combining Figma's real-time multiplayer and browser approach with Adobe's broader creative tools. What he wants to keep is Figma's closeness to its community.

In his closing thoughts he stresses that Figma has not figured everything out, and describes living in a work-in-progress world where products, plans and even the way PMs run processes keep changing. Lenny adds that people tend to assume things are designed by someone smarter, when it was usually someone like you deciding quickly. In the lightning round Yamashita mentions FigJam's Alignment Scale widget, used for quick pulse checks in product reviews.