When Kate Mas asked me to sit on a panel about how AI is reshaping product and design, I said yes immediately. Vaska Vlahova (staff designer, Qonto), Justine Potin (PM, Finary), and I (lead PM, Orus) tried to answer her questions in a coworking space in Paris' 19th, on April 16th. The topic was Blurred Lines: Evolution of Product and Design with AI. It sent me into a rabbithole on how often roles have changed in tech.
The convergence debate is older than the hype
The arguments for role collapse have been running for years. Lately the product builder sums it all: one person designs, ships, measures, and owns the outcome.
But it is not the first time. Who remembers the webmaster?
Every round makes the same case. Tooling has matured. Specialists are overhead. The future is fewer people, each doing more.
A few hours of research later I had a timeline of roles with their origins since 1840.
A few patterns stand out. Six lanes have been continuously occupied since computing became an industry. Whatever the prevailing title, someone has held the problem, the design surface, the code, the data, the operations, the frontier. Convergence and divergence happen in waves: the webmaster collapsed in the late 1990s, the EM/Designer/PM trio crystallised in the 2010s, the Builder is the latest swing back. Every wave gets evangelised as the future, then overwritten by the next. Roles do not collapse because tooling improved or because a manifesto won. They reform in response to ground conditions.
The current iteration's convergent-role orgs are mostly tech-forward, selling to technical buyers (Posthog is the obvious one). When the person ordering the thing speaks your language, one builder can translate between their need and the shipped surface. The moment the customer does not speak your language, the merge stops working. Someone has to hold the domain, someone has to understand the customer, someone has to shape the product to meet their needs. When the domain is complex enough, one person cannot hold all of it, and the team fragments back into specialists.
The shape that fragmentation usually settles into is the trio: product, design, engineering. Three specialists because there was too much to explore, know and decide for one person to hold. The trio is the compromise between "one builder can do it all" and "a department of specialists."
It is also recent, and assembled. The PM role was formalised on Microsoft's Excel team in the early 1980s under Jabe Blumenthal; user experience arrived as a title when Don Norman joined Apple in 1993;[1] EPD (Engineer, Product, Design) only consolidated as peer-level shorthand at companies like Airbnb in the early 2010s. Forty years from naming to default. The trio works, but it is one shape among several, not the natural order.
For a lot of domains, the trio is enough. For some, it still is not. At Orus we run a quatuor on many product launches: tech, product, design and a domain specialist (insurance, underwriting, claims).[2] I was frustrated by this at first, but now I have realized that this is not waste. The domain has no reference implementation (insurance is behind on so many levels), and the trio cannot see the mistakes an actuary would catch.
Team shape follows two unknowns: how clear the problem is, and how mature the category's solutions already are.
Put both on a grid and the convergence debate stops being a single argument. It becomes four quadrants. Pick the cell wrong and the team ships worse.
Two kinds of unknown
The two unknowns are problems (what the customer actually needs, which frictions matter, which regulatory edges bind) and solutions (how to ship, which patterns to apply, which technical moves to make). The lineage is pedigreed: Abernathy and Utterback called the right-hand column a dominant design, a category-level convergence that lets specialists apply patterns instead of inventing them.[3] Jon Lax mapped the two unknowns as a Known/Unknown matrix at Made By Many in 2015,[4] and the deeper ancestor is Hayes and Wheelwright's 1979 product-process matrix for manufacturing.[5] Put both on a grid and the convergence debate dissolves into four team shapes.
| Low solution maturity | High solution maturity | |
|---|---|---|
| High problem maturity | MTS (Member of Technical Staff): customer knows what, team explores how. AI research labs, Waymo, Web3 infrastructure, new-category tools. | Builder (solo): customer knows what, solution is standard. Indie SaaS, dev tools, marketplaces. |
| Low problem maturity | Quatuor with domain experts: specialists define the problem AND invent the solution. Insurance, healthcare, legal tech, frontier regulated domains. | Trio: PM and designer find the problem, engineers apply known patterns. Fintech, e-commerce, logistics, consumer. |
Forces that move teams between cells
Team shape is not destiny. Forces move teams between cells, and the cell a team ends up in depends on which forces are dominant.
AI matures the solution side. This is the dominant force of 2025-2026. Across categories where the customer-builder overlap was already high, AI has compressed the solution space enough that a team that would have been a trio two years ago can now ship as a Builder. The observable pattern is a rightward drift across the top row of the matrix: Anthropic and OpenAI normalising the Member of Technical Staff title, Shopify retiring UX Designer in favour of Designer in mid-2025, LinkedIn adding Product Builder to its job taxonomy in late 2025. All three happen at companies whose customers are technical and whose categories already had dominant designs.
Tooling matures unevenly. Solution-side tools (Cursor, Claude Code, v0, MCP, Skills) compound fast and lower the floor of the solution space. They compound fast partly because they are opaque and subscription-gated. The floor of the solution space drops, but the ground beneath it is rented from a vendor whose pricing model and roadmap can shift under you. Problem-side tools (jobs-to-be-done, discovery practice, customer research) compound slowly. The asymmetry creates a false maturity signal: teams feel the floor of how drop and assume the floor of what dropped with it. It did not. Builders who confuse the two ship into the wrong cell.
Time and community mature both sides. The longer a category exists, the more reference implementations accumulate and the more mature the customer's understanding becomes. Novel categories drift rightward and upward over five to ten years. Fintech in 2010 sat closer to the bottom-left; fintech in 2026 sits firmly in the bottom-right.
Risk acts as a specialist multiplier. This is where the matrix becomes more honest than a single-axis picture. Risk (the cost of being wrong, the density of regulation, the depth of prior knowledge required) does not move a team between cells. It pulls the team leftward toward the quatuor shape inside any cell. Regulated fintech sits technically in the bottom-right (mature problem, dominant design in place), but runs a quatuor in practice because the cost of error warrants redundant judgment. A consumer SaaS and a retail-trading platform may share cells on the grid. Their team shapes differ because the consequences of error are not comparable.
Novel-category launches reset both sides. A team shipping into a new regulatory regime, or ahead of what customers know to articulate, drifts leftward and downward. Teams that enter the space with a trio often find themselves needing a quatuor before their first product ships.
Hype is the last distortion. The Builder template is real in the top-right cell. It has been indiscriminately applied to teams whose problem is murkier and whose solutions are less standardised than the template assumes. Most of the "role collapse" failures of the past two years are teams in the wrong cell following a pattern from the right one.
The strongest version of the convergence case is worth granting. DHH runs 37signals as something close to a one-person framework. Call it the Tech Atelier shape: small teams, generalists, taste over process. Pieter Levels ships solo on a timeline that humiliates teams of twenty. swyx made the case for AI Engineer as a distinct role because the new tooling genuinely lets one builder hold what three used to hold. They are reporting from inside their cell, and inside that cell they are right.
The three names do not stand on equivalent ground, though. DHH runs Rails, a stack he can inspect, fork, and repair. Levels ships on a small set of services he controls. swyx's AI Engineer runs on closed APIs whose pricing and capability surface can shift overnight. They occupy the same cell on the matrix; the conditions that keep them there differ, and which version of the Builder survives the next contract change depends on that difference. The Builder cell also presupposes a dominant design, and in 2026 AI does not have one. Diffusion language models still contest the autoregressive default; test-time compute opened a new axis the previous frame did not predict. Teams branding themselves "AI Builders" are often operating in the top-left MTS cell, on tooling that mimics maturity it does not yet have.
The useful question is not "what shape is our team" but what forces are acting on us, and are we in the right cell for the ground we actually have?
Builder, MTS, trio, quatuor: four team shapes
Quatuor (bottom-left)
The quatuor's defining move is the embedded expert. A PM dropped into insurance, healthcare, or legal needs six months before they can catch the errors that matter, and that is on a fast track; if no one already on the team (engineer, founder, designer) carries the domain, an embedded specialist is the shortest path to judgment that is otherwise unbuildable on the timeline of a product. The PM, designer, and engineer apprentice to them by proximity. As Justine Potin put it on the panel: knowing what not to build is the skill that keeps a team from vibe-coding its way to a preventable regulatory incident. Lose the embedded specialist and the team stays in the same cell but quietly ships worse decisions; nobody catches the degradation until something breaks.
Trio (bottom-right)
AI has raised the floor inside each specialty without collapsing the structure. Vaska Vlahova said it on the panel: "Average results are now free. If you want to go beyond average, to understand why a colour creates friction, why a pattern works, why a pricing model converts, you have to go deeper than the AI output." The trio holds because the value is above the floor, not at it.
This is proletarianization read in reverse. Stiegler used the word for skills exteriorised into machines and judgement degraded inside a stable shell.[6] When the floor rises, the same dynamic flips: the trio holds only if its members refuse to externalise the skills the floor has just commoditised.
MTS (top-left)
A Builder ships; an MTS group investigates. The problem space is clear but the solution space is not, so peer exploration beats solo execution. The Member of Technical Staff title at Anthropic and OpenAI is not new. Bell Labs ran on the MTS classification from its 1925 founding; Lockheed's Skunk Works ran on the same shape from 1943; the cell has a continuous European public-research version in Inria's équipe-projet model.[7] A hundred-year-old shape is back because the conditions that produced it are back.
Flat does not mean leaderless. The cell rests on a benevolent technical apex: Kelly Johnson at Skunk Works, Marc Raibert at Boston Dynamics, Astro Teller at X, Tom Mueller on Merlin.
Builder (top-right)
swyx's 2023 AI Engineer essay named the role from inside this cell. Levels.io's Photo AI is the canonical instance: one person, one product, one revenue stream, all built on a stack the builder can hold in his head. The cell is real where it sits. The trouble starts when the template gets exported[8] into the bottom-right, where the customer does not speak the builder's language and the solution space lacks the reference implementations the template assumes. The matrix above sorts on two axes. A third axis decides whether the cell holds: how transparent the tools beneath it are. (See Let it break. See if you own it. for the prior piece on this.)
Trios and quatuors are snapshots
Role scope depends on which cell a team actually occupies, which forces are acting on it, and how well the current shape matches the ground. The matrix is itself a non-neutral design: picking a cell ships a preference about whose judgment counts. Don't crystallise around technique; when the technique shifts, the identity is left stranded.[9] Crystallise around judgment, taste, and the ability to decide what should not be done — the irreducible powers AI cannot carry. Judgment held atop an opaque agent vanishes the day the API contract changes; the judgment that survives is the one whose tools you can still inspect when the vendor moves. Kate's line on the panel named the thing that survives: what remains is judgment, taste and the ability to decide what should not be done.
Back at Kate's panel, we all added examples of where AI use went wrong. An intern who handed a PM a bloated financial model built by AI and could not answer a single question about how it worked. Managers catching their PMs enthusiastically using AI agents to ship improvements without checking if the problem was worth fixing. Each was performative agency: looking like ownership without holding the problem. The title is going to keep moving, and what stays is the judgment underneath it. That is true in any decade.
Don Norman, 1998 email to Peter Merholz, quoted aloud at the start of the Adaptive Path podcast interview in 2007: "I invented the term because I thought human interface and usability were too narrow. I wanted to cover all aspects of the person's experience with the system." Norman's own retrospective on jnd.org gives the longer naming history at Apple ("I do not know how we arrived at the name") and corroborates the period and intent. ↩︎
Author's direct practice across product and insurtech teams at Orus, 2022-2026. Four-role launch shape: tech, product, design, domain specialist (insurance regulation / underwriting / claims). ↩︎
James M. Utterback, Mastering the Dynamics of Innovation (Harvard Business School Press, 1994), p. 24: "A 'dominant design' in a product class is, by definition, the one that wins the allegiance of the marketplace, the one that competitors and innovators must adhere to if they hope to command significant market following." The concept itself was introduced in William Abernathy and James Utterback, "Patterns of industrial innovation," Technology Review 80, no. 7 (June/July 1978), pp. 40–47; the polished definitional sentence is from Utterback's 1994 book. ↩︎
Jon Lax, "Known/Unknown matrix", Made By Many, 2015. The cell archetypes (Builder, MTS, trio, quatuor) and the forces that move teams between cells are this essay's contribution; the underlying 2×2 is older. ↩︎
Robert H. Hayes and Steven C. Wheelwright, "Link manufacturing process and product life cycles," Harvard Business Review, January 1979, pp. 133–140. The product-process matrix that maps process structure (job shop → continuous flow) against product life cycle (one-of-a-kind → commodity) is the manufacturing ancestor of the team-shape matrix used here. ↩︎
Bernard Stiegler, Automatic Society, Volume 1: The Future of Work (Polity, 2016; original French La Société automatique 2015), p. 11, on consumers being "proletarianized, just as producers had been proletarianized in the nineteenth century by instruments that short-circuited their savoir-faire." Stiegler frames automation not as labour replacement but as skill externalisation; the trio's defence against AI is the same defence the artisan had against the factory. ↩︎
Inria, "Project teams: an agile and open model". Ten to twenty permanent researchers and engineers, a single principal investigator, four-year cycles capped at twelve years, around eighty per cent of teams jointly run with an external partner. Two hundred and twenty teams operate under that template. Where Anthropic revived the MTS title, Inria has been operationalising the same shape at public-research scale since the 1990s. ↩︎
Albert Borgmann, Technology and the Character of Contemporary Life (University of Chicago Press, 1984), pp. 41–42, defines a device by the way it makes a commodity "instantaneous, ubiquitous, safe, and easy" while the machinery that produces the commodity becomes progressively concealed (his recurring example: a central heating system displacing a hearth). The exported Builder template applies the same paradigm to team shape: the team ships a commodified surface while the judgement and handoffs that produced it are hidden inside an opaque pipeline. ↩︎
Ivan Illich, Tools for Conviviality (1973): "Tools foster conviviality to the extent to which they can be easily used, by anybody, as often or as seldom as desired, for the accomplishment of a purpose chosen by the user." The mechanism: when a builder's identity is supplied by a specific tool rather than by a purpose they hold independently, the tool's shifts become identity shifts. ↩︎
