Inside Figma’s PM OS: Ezra Mechaber on Skills, Bug Bashes and Automated Experiments

Ezra Mechaber, a growth product manager at Figma, wants to avoid wasting traffic that could be used for experiments. He describes AutoXP, an automated growth workflow that has already found a win, and the broader product management system from which his experiments grew.

Claire Vo introduces Mechaber and Figma’s PM OS, a shared collection of skills for everyday product work. Their conversation also covers browser-based bug bashing and a writing assistant using the fast, inexpensive model Jev.

Vo asks how the system began. Mechaber says he expected everyone at Figma to be using AI when he joined, but found little use outside engineering. He started automating his own work and exploring what Claude Code made possible in a terminal.

After a challenge from Figma’s then chief product officer to get PMs comfortable with AI, he and colleagues Jinan and Lawrence began turning his personal setup into something others could reuse. The aim was to find the work PMs were doing poorly or not doing at all and raise the baseline.

For example, Mechaber often forgot to involve support operations at the right time before a launch. Meeting notes were another weak spot. He wanted assistance that was good enough to stop these omissions from blocking colleagues, as well as a way to find people and code owners in a roughly 2,000-person company.

One early skill helped write detailed specifications grounded in how the codebase worked. Vo describes the broader goal as both raising the floor on necessary tasks and removing the ceiling for ambitious work; teams need help with both.

The system began as a simple repository used through Claude Code. At startup, it loads information about the PM, their colleagues, and a memory file, then makes a set of skills available. Mechaber jokes that the phrase “chief of staff” is useful shorthand even though he dislikes it.

One skill connects information from fragmented org-chart tools to answer who owns a team or project. When a PM writes a document, it can add the relevant engineering manager, designer, reviewers, and other stakeholders without requiring the author to remember each name.

Another frequently used skill, “What’s up,” gathers relevant Slack conversations and projects, including outstanding decisions and people awaiting responses. Mechaber runs it several times a day; a variant also brings together his live experiments.

The skill reads whole threads in selected channels and follows organization-specific instructions for finding useful context. Vo notes that this foundational work—finding stakeholders and related efforts—is easy to overlook but makes more strategic workflows possible.

Mechaber says he unsuccessfully tried to benchmark the system and would be interested in comparing it with an uncustomized current model. He found its guidance particularly helpful while models were less capable and Figma’s information architecture was difficult to navigate.

PM OS is fundamentally a repository: an agent instruction file, skills, hooks, and a folder structure. A startup hook checks for a new version so approximately 60 to 70 PMs can stay in sync. The shared parent repository and a private workspace sub-repository let people keep their own work separate.

A small group initially submitted many pull requests and experimented freely. At a PM offsite, the team installed, used, criticized, and modified the system together. Some skills were added and others removed; Mechaber keeps trying to take instructions out when improved models make them unnecessary.

The team chose not to instrument usage, partly because Mechaber wanted the project to feel fun rather than intrusive and it was built in spare time. Feedback came through Slack instead. Engineering managers became interested, and data scientists created a fork.

Among his favorite skills is an artifact builder that produces simple HTML and publishes it on an internal hosting tool. He also uses Figma’s MCP integration and a FigJam builder to create workshop templates, with design preferences encoded in the instructions.

A coaching skill combines a career ladder, feedback, and prior context with a current problem. Mechaber uses it for a first pass on his own development, including reminders about earlier misunderstandings and suggestions for communicating with colleagues.

The interface evolved from a terminal to a local web front end with formatted Markdown and mobile support. Mechaber now mostly works in Codex, citing improvements in browser use; he has even scheduled an agent to book an office desk.

For bug bashes, his team prepares FigJam instructions with test accounts, paths, actions, and things to inspect. He gives one account to himself and another to the agent, asks it to follow the scenarios in the browser, and has it write its findings back to the board.

The team is still tuning how the agent writes comments, but its diligence has surfaced issues he missed. One text box broke when filled with a thousand emojis. Another issue involved the English article used before a team name in a seat-request flow, which appeared only for certain names.

Vo asks about experiment automation. Mechaber explains that a growth PM sees unallocated traffic as a missed opportunity: there are product surfaces where the team would never normally spend enough time to run a test.

As models improved at bounded engineering, data analysis, and UX writing, he built AutoXP, drawing inspiration from others working on similar systems. An engineer was running five experiments at once, he says, and the first experiment produced a large win.

AutoXP uses Cursor automations and a dedicated Slack channel. A person can suggest a surface, or the system can run in a loop. A data-science agent looks for funnel drop-off and changes in user mix; a UX-writing agent proposes copy; an engineering agent picks up the code.

Each stage writes to the same Slack thread so people can follow the work. After an experiment ends, a webhook triggers analysis using instructions based on Mechaber’s growth experience: assess the result and decide whether to explore or exploit further.

The intended human checkpoint comes before launch, when someone can review the analysis, hypothesis, copy, and code together. The system can then watch results and begin another iteration. Mechaber stresses that the fully automated loop is the goal and the implementation is still approaching it.

Vo recalls founding Experiment Engine years earlier around a similar question: how to make better use of traffic and increase the number of experiments. She is excited that a team can now prototype much of the workflow with current tools.

The conversation turns to Jev, which Mechaber describes as a fast, cheap model that answers structured questions, such as a rating or a choice. He wondered where repeated low-latency checks could change the way people work, especially where slower models interrupt a collaborative flow.

His writing prototype checks text whenever the author pauses. It looks for placeholders, unfinished thoughts, and claims that may need support, then consults a library of source material. The idea was partly inspired by a writing application called Marker.

A live call initially encounters an internal firewall issue. Mechaber then demonstrates that a “TK” placeholder is recognized as an unfinished thought, while the system can say it lacks enough context to complete it. A different sentence prompts it to retrieve relevant interview excerpts from the library.

Mechaber is excited that a model can both identify a pattern and connect a passage to related material through retrieval in real time. He jokes that candidates might use a similar helper during product interviews, then suggests that building one could itself be a reason to hire them.

Vo recaps the 31 skills: tracking daily work, finding colleagues, writing specifications, and coaching, alongside the bug-bash and writing workflows. She asks about Instinct, a proactive agent that communicates through text messages.

Mechaber says Instinct’s memory and proactive behavior were useful. One practical example is reporting potholes encountered while biking with his children: he can send a message with the location and have the agent remember to submit a report. He says he has since mostly moved to Dots.

Asked how he reacts when an AI assistant fails, Mechaber says he prefers to remain kind. He does not claim the systems are conscious; his concern is that habitual meanness changes his own behavior. Vo distinguishes her frustrated all-caps questions from personal abuse and jokes about the cost of wasted tokens.

Mechaber adds that poor instructions or polluted context often contribute to a bad result. He describes a frustrating permission loop when moving a Codex session between environments and says that, when a conversation becomes unrecoverable, starting a fresh one can be more useful than repeating the same demand.

Vo offers a joking parenting-style prompt: express confidence in the agent’s abilities while taking responsibility for giving better direction. Mechaber likes setting high expectations and encouraging the assistant to build a prototype he can show engineers.

To close, Mechaber says he shares his work online and that Figma is hiring product managers, engineers, and designers. Vo thanks him for demonstrating a range of practical approaches to AI-assisted product work.