After the introduction of AI, most Product Managers are buried under an avalanche of new features waiting to be validated with users and released later. Some companies address this problem by simply no longer testing new features with users and instead shipping them straight into the product – on the assumption that out of ten new features, at least two will probably be liked by users. Of course, this approach leads to a product that is functionally bloated, confusing, and technically unmanageable.
In the previous article, I showed that AI did not remove the development bottleneck. It shifted it: we can now build prototypes faster than we can validate them with users. Therefore, before testing, we must define what outcome we want to achieve, which metrics we will use to choose between alternatives, and when we will stop further development. AI can speed up certain forms of testing, but we still need users to uncover new needs, interpret them correctly, and identify unexpected reactions.
The article established functional frameworks for testing (how), but it did not address the root cause of the Product Manager’s overload and the work of the team that validates solutions with users and primarily fills the product backlog.
Let us look at what can be done about this.
Reducing the number of members in development teams
For practical reasons, classic Scrum development teams are limited to ten members. They are typically made up of 6–8 developers (architect, programmers, testers, UX/UI), a Scrum Master, and a Product Owner.
With a higher number, coordination becomes so complex that adding new members no longer brings a significant increase in team productivity. Moreover, many studies state that the optimal number of members is considerably lower than ten. A frequently cited reference is a 1970 study in which Richard Hackman and Neil Vidmar found that, statistically, members rated the most favorable team size at 4.6 members. Since it is difficult in practice to get a functional 0.6 of a member, the number has settled at 5. This is also the team size advocated by Scrum@Scale, a proven successful scaled agile framework.
Because the introduction of AI has made developers far more productive, in practice we need fewer of them to maintain cadence, and consequently we can form more smaller development teams.
This enables the organization to:
- expand the product portfolio without significantly increasing development costs,
- reskill “surplus” developers into scarce roles such as DevOps, AI integrator, AppSec, platform engineer, and legacy code integrator.
Reducing development teams is a realistic solution for organizations where non-development activities (product discovery) are already handled by other organizational structures. This is not an optimal solution, but it is a legitimate adaptation to the introduction of AI.
How large should AI-supported development teams then be?
Small enough for the cadence of solution development to align with the cadence of validation by the Product Manager.
An additional positive factor of this solution is the higher coordination efficiency of smaller teams.
A different structure of development teams
As I mentioned in the previous section, a Scrum team should have ten or fewer members.
Until now, developers made up the majority of a typical development team. The reason was simply that their development phase was the most time-consuming.
This very team composition has been one of Scrum’s bigger pain points so far. Let us look into it.
Successfully steering the development of technology products requires the engagement of the development team from identifying needs all the way to presenting to the customer and collecting feedback (feature teams*). Not just programming the solution.
* Feature teams are those that can deliver a feature across all required components, from idea to use. They are the opposite of component teams, which are organized around individual technical components.
For this reason, we are constantly trying to replace component teams with feature teams that are capable of maintaining contact with the customer throughout the entire solution development cycle.
The problem is that, to perform the mentioned tasks, feature teams also need analysts among their members (market, business, data), and usually also a representative from marketing, sales, and operations. In practice, this has always meant that in a “true” feature team – one that could take a feature from idea to monetization – there simply was not room for the required number of developers.
On the one hand, the classic Scrum team was therefore always under pressure to deliver an entire feature from idea to monetization, and on the other, to keep membership within manageable limits. The result was that few organizations actually practiced feature teams. The outcomes were predictable, ranging from building something the customer understood differently to duplicating work across parallel development teams.
AI has resolved this issue. Thanks to higher programmer productivity, we can now staff the development team with the other roles needed to deliver the full feature lifecycle without exceeding the practical limit of ten members.
Personally, I advocate this solution because it optimizes the work of development teams around what the customer truly needs and wants. At the same time, such an organization enables the unambiguous establishment of value streams and their relative independence, which increases organizational resilience.
With this solution, the Product Manager is relieved by shifting product discovery activities into the development teams themselves.
