Inside Figma’s PM OS: 31 AI Skills, Better Bug Bashes, and an Automated Growth Loop

An AI bug bash found that putting 1,000 emojis into a text box could break it. It also caught something less spectacular and easier to ship: Figma’s seat-request copy used “a” where a particular team name required “an.”

Neither bug was glamorous, but both were easy to miss in a rushed test.

That bug bash says a lot about Ezra Mechaber’s approach to AI. A product manager at Figma, Ezra helped build an internal PM OS with 31 skills, then pushed into browser-based testing, automated growth experiments, and a writing assistant that checks your work whenever you stop typing. The ambition gets big. The starting point is deliberately modest: do the necessary work that otherwise gets skipped.

These are internal and individual workflows Ezra describes, not official Figma products. And their maturity varies: the PM OS is a shared working setup, the experiment loop is still approaching its intended operating model, and the writing assistant is a prototype whose live demo encounters an access constraint. They are at very different stages.

The useful part of a PM operating system is its context

Ezra’s original goal was to be “lazy in the right places.” He wasn’t looking for another way to generate more documents. He wanted help with jobs he did poorly or forgot entirely: looping support into a launch, taking meeting notes, finding the person who owns a piece of the product.

At a company of roughly 2,000 people, knowing who should review a decision is real work. Figma had several org-chart tools, Ezra says, but they weren’t stitched together usefully. PM OS added a skill for questions such as “who owns X?” and used that context while writing documents. A PM shouldn’t have to repeatedly explain that Charlotte is their designer and Aman is their engineering manager just to get the right reviewers included.

Claire’s framing is useful here: AI should “raise the floor” as well as “take off the ceiling.” Remembering to involve support may be less glamorous than generating a prototype, but it removes a predictable failure from the team’s operating system.

The implementation is a basic repo. It began in Claude Code as a terminal user interface and includes:

• An agents.md file describing how the assistant should behave.
• A memory file and context about the PM and their collaborators.
• Modular skills describing when to activate and what to do.
• Command hooks, including a startup check for a newer PM OS version.
• A shared template and a private workspace for each PM.

The workspace arrangement uses two Git repos: a shared parent repo and a per-PM workspace as a sub-repo, allowing people to write work back privately. A hidden dot-folder holds the base template context. The machinery was partly a practical accommodation for getting roughly 60–70 PMs, including people new to GitHub, onto a common setup.

Ezra’s most frequently used skill is “What’s Up,” which he says he runs about six times a day. It pulls together relevant Slack channels and projects, outstanding decisions, and things he owes other people. The instructions tell it which channels matter and to read whole threads rather than isolated messages.

That last detail is worth copying. A briefing is only useful if it can distinguish a new request from a request already resolved ten messages later.

The caveat: Ezra tried to build a benchmark and wasn’t successful. He doesn’t know how much this tailored setup now outperforms a vanilla agent. As models improve, he has been removing instructions that no longer earn their place. Treat the repo as maintained operating context, not a permanent monument to prompt engineering.

Adoption meant leaving the terminal—and pruning the skills

PM OS started with Ezra, Jinan, and Lawrence trading PRs in a small Slack channel. The initial explosion of skills was followed by editing. At a spring offsite, Figma’s PMs installed it, used it, modified it, and were invited to roast it.

The roasting helped the team decide which skills were worth keeping.

There is no usage telemetry. Ezra chose not to instrument it partly because he didn’t want people to feel watched and partly because this was work done on the side. Feedback came through conversation and a public channel; engineering managers began using it, and data scientists developed what he describes as essentially a fork. That supports a story of internal interest, not a measured productivity claim.

Some skills produce artifacts rather than briefings. “Build artifact” uses HTML and CSS templates plus an internal hosting tool to create and publish small presentations or dashboards. Ezra’s dashboard for this episode was one such artifact. Another PM built a FigJam builder using Figma’s MCP to generate workshop templates, with instructions reflecting the team’s visual preferences.

The coaching skill takes a different set of inputs: a career ladder, feedback, prior experiences, and a current problem. Ezra uses it for a first pass at his own coaching before taking the issue to someone else. Its value is partly in recalling patterns—for example, that a previous conflict with a colleague turned out to be a misunderstanding after a conversation.

That is useful preparation for human advice. It is not independent evidence about a colleague’s motives.

The interface also changed. Reading and writing in a terminal’s monospace text was unpleasant, so the team built a local browser front end with Markdown formatting and mobile support. Ezra now says he works in Codex essentially all the time, particularly because browser use has improved. The durable investment was the context and skills, not loyalty to the original interface.

Give the browser agent a test plan, not a vague assignment

Ezra’s team writes a FigJam test plan for an upcoming experiment or redesign. It spells out:

• The test account to use.
• The path to follow.
• The actions to take.
• What to inspect.

He gives himself one account and the agent, Astra, another. In a persistent Codex conversation, he asks it to follow the documented scenarios in the browser. When it finishes, it writes its findings back to the FigJam board.

The example involved simplifying Figma’s request modals. The interface changes were mostly UX and writing, but the underlying logic was complex. Ezra’s instruction was to keep working through the specified scenarios rather than stopping after a quick pass.

The 1,000-emoji failure and the team-name article error were findings he reported from the preceding month, rather than bugs discovered live during the episode. They illustrate different benefits: stress-testing an input and exercising a copy variation dependent on account data.

The remaining annoyance is output quality. The team is still tuning the comments so the agent’s contributions aren’t irritating. Finding something useful and reporting it usefully are separate jobs.

To adapt this approach, start with an executable test plan:

• An appropriate test account.
• Explicit steps and expected behavior.
• A shared place for findings.

Keep a human responsible for deciding which findings block launch. This checklist is an adaptation of Ezra’s setup.

Auto XP compresses the experiment handoff, but keeps a review gate

“As a growth PM,” Ezra says, “the biggest sin you can commit is wasting traffic.” His next project, Auto XP, asks whether agents can run experiments on surfaces the team would otherwise never prioritize.

The system uses three Cursor automations triggered through Slack. Auto XP has its own channel, and each stage writes back into the same thread so someone can follow the experiment’s progress.

A starting request can be as loose as:

“Hey, Auto XP, go find an experiment to run on our settings page. See what you can do. Go crazy.”

Behind that casual request are three agent automations:

1. A data scientist examines drop-off, funnels, and mix shift.
2. A UX writer proposes copy.
3. An engineering agent picks up the implementation and PR.

Ezra says the team is moving toward more front-end design work as well.

The intended human checkpoint comes before launch: review the data science findings, hypothesis, UX writing, and code together. When the experiment finishes, a webhook triggers analysis and instructions guide whether to explore further, exploit a result, or treat it as a win or loss. The next iteration can then begin.

This is where the distinction between goal and current operation is essential. Ezra calls the theory great and the practice “almost there.” Engineer Marion has been pushing it forward. At the time of the conversation, Ezra reports five concurrent live experiments on work the team would not otherwise have done, and a “huge win” from the first experiment. He does not provide a lift figure, metric, or statistical detail.

The result worth taking seriously is the expansion of what the team can test. The result we cannot independently evaluate is the size or reliability of that first win.

My adaptation would be to preserve the human gate and define experiment eligibility before expanding autonomy. Ezra’s system draws on his accumulated growth-PM instructions; it is not evidence that any team can delegate experimental judgment to a generic agent.

A writing assistant that waits for you to pause

Ezra’s final prototype uses Jev, which he describes as a cheap, fast model that can answer constrained questions with outputs such as a number, a boolean, or a multiple-choice selection.

Instead of asking a large model to continuously rewrite a document, he makes a call whenever the writer stops typing. The check looks for blanks, unfinished thoughts, and claims worth supporting. The assistant can then consult a supplied library for relevant material.

During the demo, a recent move of the API behind an internal firewall initially interferes with execution. Later, Ezra shows the intended behavior with two examples. A sentence ending in “TK” is recognized as unfinished, but the assistant says it cannot know what he intended because the answer is absent from the library. A sentence beginning “We spoke with X writers and they said…” triggers retrieval of interview quotes from the example library.

That contrast is the interesting part. Detecting a hole is different from having evidence to fill it. The prototype’s useful behavior includes admitting the library cannot supply the missing thought. Retrieved quotes still require the writer to verify that they support the claim being made.

The verdict: copy the context layer and the documented browser bug bash first. They are especially suited to PMs in busy organizations where coordination and diligent testing regularly lose to urgency. Auto XP is a more ambitious pattern for growth teams with existing experiment infrastructure and enough expertise to review the whole proposal before launch. The Jev editor suggests a promising interaction for writers with a trusted source library, but remains a prototype. Across all of them, the human job is still choosing the evidence, setting the boundaries, and deciding whether the output deserves to ship.