How Figma gave 60 PMs an AI repository with 31 skills

The problem before PM OS

When Ezra Mechaber joined Figma as a growth PM, he noticed something that stood out from the rest of the company: outside engineering, almost no one was using AI to produce real work. He already had a personal setup of Claude Code running day-to-day tasks. The idea of turning that individual use into something collective came from the obvious observation that product teams were reinventing the wheel on their own, each one figuring out the hard way what already worked for the colleague at the next desk.

Together with two other PMs, Ezra took that personal setup and turned it into a shared repository: PM OS. The interview, given to the How I AI podcast, hosted by Claire Vo (Lenny's Newsletter), published on November 2, 2026, details how this repository went from a hallway experiment to infrastructure used by 60 to 70 PMs within Figma.

Lazy in the right places.

Ezra Mechaber, growth PM at Figma

The phrase sums up Ezra's stated goal: automate repetitive, bureaucratic work so that energy is left over for product decisions, not for operating tools.

Why it's a repository, not a product

The detail that matters most to anyone thinking about scaling team practices is the deliberate choice of format: PM OS is a code repository, not an internal product with a polished interface. It's made up of "skills" (reusable prompt and automation blocks that Claude Code executes), hooks that trigger actions automatically, and private sub-repos for teams that need specific context without exposing everything to the entire company.

According to Ezra's account, the skills went through a tough curation process before arriving at the 31 that survived: they were built, "roasted" (critiqued without mercy by fellow PMs), and cut down until only what was actually used day to day remained. That selection process matters more than the final number: an AI repository for a team only works if someone has the nerve to kill the skill that looked good in theory and never caught on in practice.

The skills that take over day-to-day work

In the demo, Ezra shows a set of concrete uses that went from individual habit to team standard:

• A "chief of staff" skill that he runs six times a day just to tame the volume of messages on Slack;
• A bug bash routine that uses Codex to find issues that, by his own account, he would never catch alone through manual review;
• Integrations with Figma's MCP server and with FigJam to generate build artifacts directly from specs;
• Coaching skills, designed to help less experienced PMs structure decisions without depending on a mentor who's available all the time.

There was also an interface shift: the team started out operating everything via terminal and migrated to a local web front end, making the repository accessible to PMs who weren't familiar with the command line. This is the kind of product decision that usually stays invisible in AI case studies: the technology behind it can be the same, but without an accessible interface layer, 31 skills become a tool for just one person.

AutoXP: the agent that runs experiments with one human checkpoint

The boldest piece of the system is AutoXP, described as an "automated growth PM." The idea is for the agent to run a growth experiment end to end, with just one human checkpoint in the middle of the process, instead of a PM reviewing every step manually.

The result cited in the episode is straightforward: the first experiment run by AutoXP already brought a big win for the team. The source doesn't detail the metric or the exact size of the gain, so this data point is best treated as qualitative, not as a replicable benchmark.

What matters more to anyone designing a product process is the control architecture, not the one-off result. A single checkpoint implies a bet: the agent has autonomy to decide test design, segmentation, and result analysis, but there is one specific moment where a human needs to sign off before the experiment moves forward or gets published. The episode doesn't detail exactly what that checkpoint covers (whether it's approval of the hypothesis, the sample, or the final decision), and that's a real gap in the material: the question left for anyone copying the model is where, exactly, to place their own checkpoint.

The writing assistant that became part of meetings

Alongside AutoXP, Ezra built a real-time writing assistant with Jev. According to the episode's rundown, this tool started following almost all of Ezra's meetings for two weeks straight, suggesting text and structure as the conversation happened.

The case illustrates a pattern that shows up in other episodes of the same podcast (like the earlier conversation on how to use Jev in practice, also published on Lenny's Newsletter): generative AI tools for text are shifting from "asynchronous editor" to "synchronous copilot," present inside the meeting itself, not just after it.

What remains open

Figma's model is consistent on one point: every relevant automation keeps a point of human intervention, whether in the bug bash with Codex or in AutoXP's single checkpoint. That's different from simply "giving the team AI" without process design.

But the account also makes clear that this system was born bottom-up, from a personal setup that turned into culture, not from a top-down decision by product leadership. For anyone leading a smaller product team, the question worth taking from this isn't "which tool to copy," but rather: what would be the one step in your growth process you wouldn't give up approving before an experiment goes live?