## How Figma Builds Product ### How Figma Builds Product  #### Metadata * Author: [[lennysnewsletter.com]] * Full Title: How Figma Builds Product * Category: #articles * URL: <https://www.lennysnewsletter.com/p/how-figma-builds-product> #### Highlights * 2. Do you use OKRs (e.g. objectives, key results, 70% goals, etc.) in some form? We've had a fun relationship with OKRs. When I first arrived at Figma, I actually deprecated OKRs. We had dreadful companywide OKR meetings where we went through a spreadsheet tracker of hundreds of OKRs that were really more like tasks assigned to individual contributors. While it was good at creating some level of accountability, it was hard to understand why any of this mattered. I asked teams to instead define headlines—essentially, claims that they'd like to make by the end of some time period. For example, it might be something like "Figma is the most efficient way to design," and the team offers both quantitative and qualitative ways to evaluate that claim. * This helped me understand what a team was philosophically going for. It produced the right debates, and it allowed teams to be a bit more creative around how to measure whether they've achieved that headline (e.g. a combination of a variety of metrics and qualitative signals). It recognized the reality that some things, like the core experience of Figma, are hard to measure and can't be reduced to a single metric; it gave room for teams to invest in a roadmap of exploring different KPIs versus artificially elevating a metric that ultimately people didn't believe actually mattered. * Our OKR process is actually run on FigJam. We have teams write "commitments" (our rebranded OKRs) in these widgets that Lawrence made: * Product reviews are more about making decisions and debating directions. Here's our template. We have different kinds: ones where we're trying to align on the problem or ones where we're trying to align on the solution. One thing I encourage for both is to first present the "option space"—it's really powerful to have a framework that maps all possible solutions or problems and use that as a device to discuss high-level tradeoffs or philosophical differences. * It's been interesting to see the evolution of the format. When I arrived, people were projecting docs and there was more of a memo culture. I switched this format to decks, mostly because I wanted to push for more of a storytelling culture (and also so my PMs can use Figma more!). And recently we've been using FigJam more, because it allows for more of a two-way conversation and it's easier to gauge people's reactions. My favorite is adding the alignment widget, which lets people share/vote on their sentiments toward specific decisions; I find this so much more powerful than allowing the loudest people in the room to dictate the outcome! # How Figma Builds Product  ## Metadata - Author: [[lennysnewsletter.com]] - Full Title: How Figma Builds Product - Category: #articles - URL: https://www.lennysnewsletter.com/p/how-figma-builds-product ## Highlights - 2. Do you use OKRs (e.g. objectives, key results, 70% goals, etc.) in some form? We’ve had a fun relationship with OKRs. When I first arrived at Figma, I actually deprecated OKRs. We had dreadful companywide OKR meetings where we went through a spreadsheet tracker of hundreds of OKRs that were really more like tasks assigned to individual contributors. While it was good at creating some level of accountability, it was hard to understand why any of this mattered.  I asked teams to instead define headlines—essentially, claims that they’d like to make by the end of some time period. For example, it might be something like “Figma is the most efficient way to design,” and the team offers both quantitative and qualitative ways to evaluate that claim. - This helped me understand what a team was philosophically going for. It produced the right debates, and it allowed teams to be a bit more creative around how to measure whether they’ve achieved that headline (e.g. a combination of a variety of metrics and qualitative signals). It recognized the reality that some things, like the core experience of Figma, are hard to measure and can’t be reduced to a single metric; it gave room for teams to invest in a roadmap of exploring different KPIs versus artificially elevating a metric that ultimately people didn’t believe actually mattered. - Our OKR process is actually run on FigJam. We have teams write “commitments” (our rebranded OKRs) in these widgets that Lawrence made: - Product reviews are more about making decisions and debating directions. Here’s our template. We have different kinds: ones where we’re trying to align on the problem or ones where we’re trying to align on the solution. One thing I encourage for both is to first present the “option space”—it’s really powerful to have a framework that maps all possible solutions or problems and use that as a device to discuss high-level tradeoffs or philosophical differences. - It’s been interesting to see the evolution of the format. When I arrived, people were projecting docs and there was more of a memo culture. I switched this format to decks, mostly because I wanted to push for more of a storytelling culture (and also so my PMs can use Figma more!). And recently we’ve been using FigJam more, because it allows for more of a two-way conversation and it’s easier to gauge people’s reactions. My favorite is adding the alignment widget, which lets people share/vote on their sentiments toward specific decisions; I find this so much more powerful than allowing the loudest people in the room to dictate the outcome!