Smaller teams, wider roles: how far can Product, Design, Data and Engineering blend?

The same signals keep showing up across several companies: Product Managers prototyping or writing code, designers pushing changes straight to production, more generalist engineers, data analysis done directly inside product teams. At Instagram, a typical team is even moving from a dozen specialists down to a pod of six or seven people.

Should we conclude that the Product–Design–Data–Engineering squad is disappearing in favour of a handful of all-purpose "super-builders"?

The available cases tell a more interesting, and more demanding, story. AI makes the boundaries of execution far more porous. It doesn't, however, remove the need for expert depth. The real question probably isn't merging four roles into one, but telling apart what each role can now do beyond its own remit from what still demands specific expertise, accountability and judgement.

In brief

• •Role hybridisation shows up in several of the cases observed, but is still rated medium confidence: smaller, more generalist teams are a signal, not yet a market norm.
• •Instagram is experimenting with a 6-to-7-person product unit, with 4 to 6 generalist engineers, a "product staff" role, and a specialist brought in depending on the subject. The change is recent, and doesn't prove specialisation is becoming pointless.
• •Alan shows how far hybridisation can go: designers and PMs can contribute directly to the codebase. But the setup is deliberately bounded by scope, CI, engineering buddies and human review.
• •Conversely, Gorgias created a Machine Learning Analyst role at the interface between product and generative-AI systems: AI can therefore produce generalisation in some places and more specialisation in others.
• •The relevant question isn't "how many roles can we cut?" but: which boundaries can we make porous without losing the depth that protects the quality of decisions?

Smaller teams exist. But it isn't a new standard yet

The Instagram case is probably the most spectacular signal.

Adam Mosseri describes a historical team close to a "baker's dozen": several Android, iOS and server engineers, a PM, a data scientist and sometimes a researcher. The new target unit instead has four to six more generalist engineers, one "product staff" member combining several dimensions historically split between Product, Design, Data Science and Research, and a specialist suited to the problem at hand. Mosseri himself presents this as a major change under way in 2026, not as a model that's been stable for years.

What this shows: the organisational cost of systematic specialisation can become less acceptable once tools let a single person go further in analysis, prototyping or execution.

What this doesn't show: that a six-person team is now optimal, that specialists are becoming pointless, or that this model would work the same way at a regulated fintech, on a complex B2B product, or at a company that's less technically mature.

This caution matters: the "hybrid product team" model is itself still classed as an experiment, observed in a handful of cases selected for their organisational signals, with no claim to being representative.

And not every case points the same way. Lucca is precisely a counter-example: AI is built into its products and into some roles, while its small product teams remain structured around something close to how they already worked. It would therefore be premature to turn the tight pod into the new reference org chart.

The most solid phenomenon isn't the disappearance of roles — it's the widening of what each one can reach

Two forms of hybridisation need to be distinguished here.

The first is hybridisation of execution: a PM can build a working prototype; a designer can fix an interface directly; an engineer can run an analysis that used to require an analyst; a data specialist can produce more software.

The second would be hybridisation of accountability: assuming a single person can durably own product strategy, user research, experience quality, metric definitions, statistical analysis and technical architecture.

The available cases document the first far better than the second. It's a structuring distinction: being able to perform a task doesn't necessarily mean you've acquired all the expertise of the role that used to perform it.

Product: the builder PM removes handoffs, not necessarily the other roles

The evolution of the Product Manager is especially visible. AI sharply shrinks the distance between an intention and a first artefact: a prototype, a data query, a spec, a screen, a script, or sometimes a pull request. At Finary, a PM can build a set of screens matching the design system using agents, ahead of review. Alan also lets PMs contribute directly to the codebase in some cases. The potential organisational gain is obvious: fewer back-and-forths to turn an idea into something that can actually be tested.

But Alan also shows the limit of that reasoning. Non-engineers' contributions there go through the same quality pipeline as the rest of the code. Every non-engineer has an engineering buddy, and the engineer keeps ownership of the merge. The setup was initially bounded to the front end, precisely to avoid riskier back-end and data-model changes.

The programme produced more than 350 PRs merged by designers and PMs, and more than 1,000 tasks handled by the internal agent. But the teams also report PRs of variable quality, difficulty testing certain states, hallucinations that are hard for less technical contributors to spot, and a heavier review load. No clear overall ROI figure was yet available in the published account.

It's almost a controlled experiment on the boundary of the role: the PM can go further into "doing", but the system doesn't remove engineering accountability. It shifts it toward scoping, guardrails and review.

The wrong conclusion, then, would be: "the PM becomes PM + designer + developer". A more realistic phrasing would be: the PM becomes less dependent on other functions to turn a hypothesis into a first testable version. That is not the same thing.

Design: as execution becomes less scarce, the system and the judgement gain value

The Finary case pushes this reasoning into design. Its Design System Engineer describes a workflow in which Claude Code relies on codified rules and components to generate screens that match the design system. A Product Manager can then produce certain interfaces without going through Figma. The distinction stays explicit: the agent performs well on bounded execution, far less well on creation.

This suggests a paradox. The more graphic execution becomes accessible to non-designers, the more important it becomes that the structural choices have been turned into a system: components, rules, conventions, accessibility, interaction principles, design tokens, quality criteria.

AI therefore doesn't necessarily make the design system less important. It can instead turn it into the infrastructure that lets more people produce work without immediately degrading consistency.

The designer's role could then partly shift.

Before: producing a large share of the screens themselves.

Tomorrow, on some teams: defining the principles, exploring new solutions, building the system, handling ambiguous situations, and reviewing what falls outside the frame.

This opens up a possibility of leaner teams — but only if design depth still exists somewhere. An organisation that replaces its designers with PMs able to generate screens mainly risks confusing visual compliance with design quality.

Data: self-service can remove some handoffs and create new specialties

Data probably provides the best counter-example to a naive reading of hybridisation.

In the model described at Instagram, some of the analysis once reserved for a data scientist can move up into the generalist product-staff role. Elsewhere, though, the sophistication of AI products is creating new specialised roles.

Gorgias documents the creation of a Machine Learning Analyst role, tasked with sitting at the interface between product vision and the generative-AI architecture, prompts, APIs, experiments and feedback loops. The arrival of large language models hasn't just let data capability be distributed more widely: it has also created a new need for expertise.

The same caution applies at Qonto, which shows a marked convergence between ML and software engineering: its Machine Learning Engineers see their role evolving toward AI Engineering, moved closer to the back-end teams to strengthen their software-engineering skills. It's therefore safer to speak of growing ML–software hybridisation than of the outright disappearance of the ML specialty.

The plausible trend is then twofold: routine analysis becomes directly accessible to Product and Engineering teams; Data teams focus more on the problems where depth remains hard to distribute — reliability, context, architecture, data quality, experimentation, and evaluating systems.

Hybridisation doesn't necessarily reduce the amount of expertise. It can simply move it.

Engineering: generalist doesn't mean shallow

The generalist engineer comes up in several cases across this body of work. At Instagram, the old Android / iOS / server split is being replaced, in the pods Mosseri describes, by engineers able to cover a wider field. At Dust, the current organisation runs with no dedicated Product Manager: around twenty engineers with a strong product culture directly own part of the prioritisation, while the share of code attributed to agents rose, according to its CTO, from about 20% to nearly 70% between December 2025 and February 2026.

But Dust also supplies its own warning: its model applies to a company of around a hundred people, and its leadership doesn't claim that having no PM is a universal doctrine. Its CTO instead stresses the need for profiles who can be given strong autonomy without degrading the codebase.

Broader research into AI-assisted development also calls for caution. During the rollout of Claude Code and GitHub Copilot CLI to tens of thousands of Microsoft engineers in early 2026, adopters merged roughly 24% more pull requests than the researchers' counterfactual estimate — though the researchers are explicit that a merged PR is not equivalent to value produced.

One further conclusion follows: AI acts as an amplifier of existing engineering systems. It can improve throughput, but an organisation with weak foundations may mainly end up producing the wrong outputs faster, or degrading its stability.

Increasing an engineer's ability to touch more technical layers doesn't make architecture, security, performance or deep understanding of certain systems any less necessary.

The augmented generalist is probably more viable when specialists haven't disappeared, but simply stop being assigned full-time to every small team.

The model taking shape: a more generalist core, expert depth available on a different basis

Across these cases, an organisational architecture is starting to emerge. Not a team full of specialists each working in their own lane. Nor four roles merged into an improbable "full-stack Product–Design–Data–Engineering" role.

But rather:

• •a smaller, more versatile permanent core, able to move quickly from idea to execution;
• •specialists called on where depth genuinely changes the quality of the decision;
• •explicit review and evaluation systems, so that higher throughput doesn't turn into more rework or more risk.

This is in fact the model summarised for the "hybrid product team": product staff or builder PM, generalist engineers, specialised agents, and domain expertise mobilised on demand. Its identified risks are precisely loss of depth, overload of the hybrid roles, and diluted accountability.

How far to hybridise? Three criteria help draw the line

A simple rule follows: the more standardisable, observable and reversible the work is, the more porous the boundaries can become. The more ambiguous, hard to reverse, or dependent on tacit expertise it is, the less reasonable it is to do away with specialisation.

This rule isn't a figure drawn directly from a study: it's an inference drawn from the cases observed.

The hidden risk: creating roles so broad they become impossible to hold

Hybridisation also carries a human cost rarely visible on an org chart.

If the PM has to simultaneously do discovery, analyse data, prototype, write specs agents can execute, and contribute code, where does their attention actually go? If the engineer becomes developer, architect, reviewer for five agents, user contact and product owner, what gets dropped? If the designer becomes researcher, art director, design-system owner, agent evaluator and front-end contributor, where do they find time to explore?

The problem with a hybrid role isn't only skill. It's also attentional capacity.

And agents don't necessarily remove that constraint. A study of 306 practitioners deploying agents in production shows reliability remains their main challenge: 74% of the systems studied rely mainly on human evaluation, and 68% run at most ten steps before human intervention.

The organisational consequence matters: a person able to launch more work can also end up with more things to check, arbitrate and supervise. This is already visible at Alan, where the rise in contributions is surfacing a "review fatigue" problem.

Cutting the number of producers while forgetting to size judgement capacity accordingly would be a false economy.

What the data does not yet let us claim

• •We can't claim that classic Product squads will become half the size. Instagram is a recent, spectacular, but still isolated case.
• •We can't claim that PMs will replace designers or data analysts. The cases mainly document an increased ability to perform certain tasks that used to depend on another role.
• •We can't claim that AI makes specialists less important. Gorgias shows exactly the reverse phenomenon on certain skills.
• •We can't infer from higher code throughput that a team can shrink its headcount proportionally. The available research measures varied proxies and shows organisational context strongly shapes the results.
• •Nor can we assume that an organisation built around AI from the start is the target state for a scale-up with an existing history. This limit on transposing the model is explicitly flagged by the cases themselves.

This body of thirty companies was assembled to identify organisational signals, not to provide a representative sample of the market.

The conviction: hybridise the actions before hybridising the accountability

The most credible transformation is probably not the disappearance of the Product, Design, Data and Engineering roles. It's the gradual erosion of part of their monopoly on execution.

The PM no longer necessarily has to wait to prototype. The designer no longer necessarily has to wait to fix an interface. The engineer no longer necessarily has to wait for an extract to explore a data question. The Data specialist can build more software without creating as many handoffs with Engineering.

This shift can genuinely enable smaller, faster teams. But the relevant boundary isn't the tool's. It sits at the level of judgement and accountability.

The best teams probably won't have fewer experts. They will have fewer specialists permanently assigned to each pod, more generalists in the operational core, and deep expertise organised as an accessible capability, with specific moments where it takes back the wheel.

The org chart therefore becomes less telling than three other questions: who can act? Who has to check? Who has the final say?

Self-diagnostic: can your team genuinely become smaller and more hybrid?

Before merging roles or shrinking a pod, ask these questions about a real product.

Work

• •Have we precisely identified which tasks can now move between roles?
• •Can we tell a task that's become easier to execute from expertise that's genuinely become unnecessary?
• •Are the main operations delegated to AI reversible and observable?

Quality

• •Do we have sufficiently explicit standards: design system, metrics, tests, evaluations, architecture rules?
• •Is review capacity growing at the same rate as production capacity?
• •Do we measure rework and errors, and not just the number of prototypes, PRs or features produced?

Expertise

• •Do we know which decisions still require a Design, Data or Engineering specialist?
• •Can those specialists be brought in fast enough without becoming a bottleneck again?
• •Are our experts spending more time on hard problems, or are they now spending their days fixing other people's output?

Roles

• •Do final responsibilities stay explicit despite the overlap in tasks?
• •Do our hybrid roles genuinely have time to master their expanded scope?
• •Are we avoiding turning a "builder PM" or a "product engineer" into four jobs stacked under one title?

Organisation

• •Can we trial a tighter team on one scope for 60 days before reorganising the whole function?
• •Are we tracking speed, quality, user satisfaction and review load at the same time?
• •Are we ready to put a specialist back into the core if quality or decision speed degrades?

If several answers are uncertain, the point probably isn't yet to shrink the team. It's first to make the new boundaries of the work visible.

Conclusion

Tomorrow's Product teams may well be smaller. Several credible cases are starting to show it.

But their most important trait will probably lie elsewhere: they will depend less on functional boundaries to act, while having to be far more explicit about where expertise remains irreplaceable.

AI makes it easier to cross boundaries. It doesn't automatically remove what years of experience let you see on the other side.

The right goal, then, isn't to manufacture generalists who can do everything. It's to build an organisation where more people can do more things, without losing the depth needed when the decision genuinely matters.