As AI is getting better at many software development tasks, the composition of the Product team is changing.
AI as a software supply shock
Looking at software development through an Economics lens, you can make a few simple observations:
- Engineers are getting faster
- Supply shifts: software is produced at lower cost
- Software demand increases (settling at a higher equilibrium)
AI acceleration seen as a supply shock in software production
Super-powered Engineers
Engineers around me (operating on a large code base in a regulated environment) are seeing perhaps a 3x acceleration in development, going from technical design to fully tested delivery. And they’re finding that specialization is starting to matter less: front-end and back-end Engineers move to full stack, and they more comfortably contribute across languages. In short, Engineers are super-powered.
For UX Designers, the same holds to a lesser degree: while their AI tooling is less advanced, their design explorations and execution are already moving at significantly higher speed.
Product and the PM bottleneck
Engineering & Design acceleration is opening up the product roadmap: products & features previously not worth building are now ROI-positive. Niche solutions for niche customers start making sense. More software is delivered.
PMs are racing to keep up. The squishy human parts of software development, much of which falls on them, aren’t accelerating as much: talking to customers, aligning across a large organization, driving a new strategy, all rely heavily on slower human interaction.
Solving the imbalance
The result is an imbalance between Eng/UXD and PM. Some of it is solved by Engineers taking on a hybrid role: the rise of “Product Engineers”, single people that take on initiatives end-to-end (smaller customer requests and product improvements are particularly well-suited for this). Some of it is solved by a change in PM:Eng ratios: Andrew Ng famously noted that a team he worked with in his AI fund proposed not a 1:6 PM:Eng ratio but an inverted 2:1 (truly an Engineer’s nightmare!)
For now, a more modest combination of both ideas makes sense. Smaller teams, with more hybrid roles. Reduced specialization, more role overlap, and more capacity for non-technical work.
| Traditional | New |
|---|---|
| Technical specialists | Technical generalists |
| Larger teams | Smaller teams |
| Coding-bottlenecked | Human-interaction-bottlenecked |
Facets of an AI-native team
The specific team composition will depend on the domain: young software startups might get by with tiny or even single-person teams. Teams in highly regulated, sensitive or technical domains will err on the larger side.
An example team adapted to the AI age
Is this the Product team of the future? I anticipate that in a year, the ideal team composition will look different again. For 2026, it’s a healthy adaptation.