Product management after Figma

Figma's own research contains the most quietly radical number in product development: 60% of the files created on the platform in the past year were made by non-designers. Prototyping has escaped the design team. With tools like v0, Lovable and Figma Make, describing what you want in plain language now produces not a mock but a working application — front end, data, logic — in an afternoon.

The commentary calls this "vibe coding" and argues about code quality, which for production software is a fair argument. But the production codebase is not where this lands first. It lands on how product decisions get made — and early research on AI-assisted product teams suggests the boundary between "defining the product" and "building the product" is dissolving faster than most organizations have noticed.

The artefact was the bottleneck

Classic product management is a chain of proxies. A PRD describes the idea in prose. A wireframe approximates its shape. A mock renders its look. Months later, working software finally tests whether anyone wanted it — the only artefact in the chain that ever generated real evidence arriving last and most expensively. Every stage exists because working software used to be too expensive to use as a thinking tool.

Each handoff in that chain loses information, and each artefact is an argument waiting to happen — about interpretation, about feasibility, about what the author meant. Because none of the artefacts can be used, the arguments are settled by seniority, persuasion and document quality rather than by evidence. Whoever writes or presents best wins, which is not the same thing as being right.

When a working prototype costs an afternoon, the chain inverts. Discovery starts with the clickable thing rather than ending with it. Requirements are extracted from something customers have already touched — observed behavior, not predicted behavior. The expensive stages of the old chain do not disappear, but they move: they come after the evidence instead of before it.

Vision stops being a document and becomes a prototype — and prototypes settle arguments that documents only start.

What changes for the product function

Product managers spend less time authoring specifications and more time designing experiments; the skill that appreciates fastest is knowing which question to put in front of a customer next, and which prototype would answer it. The weekly rhythm changes from writing about the product to testing versions of it.

Designers shift from producing screens to setting the system — the standards, patterns and design language that keep a thousand generated prototypes coherent and on-brand. That is a more senior job than the one it replaces, not a lesser one: when everyone can generate an interface, the scarce skill is the taste and system-thinking that make interfaces good. The 60% number is not designers being displaced. It is design judgement becoming the constraint instead of design production.

Engineering gains a cleaner brief. Instead of interpreting a document, teams receive a prototype that has already survived contact with users, plus the evidence of how it survived. The build is still the build — production quality, scale, integration and security are not vibes — but far less of it gets thrown away, because far fewer wrong things get built carefully.

The governance edge

There is a risk to manage, and it is organizational rather than technical. Sixty percent of files made by non-designers also means a flood of prototypes that look shippable while being nowhere near production quality, and executives will mistake one for the other — the demo that "just needs finishing" is the new version of the spreadsheet that became a core system. The discipline is a hard line between evidence and product: prototypes prove direction, engineering makes it real, and the organization has to know which side of the line any given artefact sits on.

Teams also need somewhere for all this generation to point. A prototype answers a question; without a clear product thesis, a hundred prototypes answer a hundred questions nobody asked. The companies getting value from this are not the ones generating the most — they are the ones whose product leadership got sharper about which questions matter, because the cost of asking dropped to nearly nothing and the cost of focus did not.

Why this matters beyond the product team

The deeper shift is in who participates. When having a testable opinion required a design team and an engineering sprint, product direction belonged to the few people who could commission those. When it requires an afternoon and a clear intent, the circle widens — founders, operators, domain experts and field-facing teams can put their understanding of the customer directly into something clickable. The organizations that benefit will be the ones that treat that as a widened funnel of evidence rather than a threat to process. The ones that suffer will be the ones that respond by requiring the PRD anyway.