Recently, in industry exchanges, I frequently hear a management perspective argument: "Teams should be small, and everyone should do more, so that great products can be crafted."

This view seems to align with the intuition of "agile development" and is often used to explain the success of some startups. But if it is taken as a universal management logic and forcibly applied to the context of daily complex product iterations, there are obvious logical flaws and survivor bias.

This article will dissect the three major attribution fallacies behind this management myth from the professional perspective of product design.

Confusing "technical complexity" with "business complexity"

Many managers like to cite today's hottest AI startups as examples, marveling that a dozen or so people can create a world-disrupting product, and conclude that "we can also build complex systems with just a few people." This is a serious misjudgment of the leverage properties of products.

The objective fact is that the complexity of these two types of products goes in completely different directions:

  • Underlying technical services (such as foundation large models): Their characteristic is extremely convergent interaction (usually just one input box or API interface). The core complexity of the system is in the backend, digested by massive computing power and top researchers' algorithm models. At this point, "fewer people" is reasonable, because adding frontend or business personnel is of no help to core technical metrics.

  • Heavy business-oriented products (such as large collaboration systems, trading platforms, or professional tools): Their characteristic is extremely divergent interaction. They face real-world workflows full of mixed quality, involving complex permission control, multi-role state collaboration, handling of non-standard data, and massive edge cases.

In other words, real business complexity cannot be solved simply by machine "computing power." It must be addressed by product managers, designers, and frontend engineers investing real cognitive bandwidth to sort out and reconstruct one by one. Using the staffing configuration for "single-point technical services" to carry heavy business systems will inevitably cause the product to degrade into a semi-finished product lacking foolproof design and with broken operation flows.

Deliberately stripping away the cost structure fallacy of "talent density"

When we talk about the "small team myth" of certain top teams, we often only see the "small absolute number of people" but filter out another core premise:Extremely high per-capita human capital.

The cost structure of teams that create myths is often an inverted pyramid. They are "special forces" composed of the industry's top architects and senior product experts, and the salary of a single member may equal the entire R&D department expenses of an ordinary company. Under extremely high talent density, individuals possess strong system abstraction capabilities and full-stack execution capabilities, enabling them to complete complex closed loops with minimal communication loss.

If an enterprise, while maintaining an average or even low compensation structure (i.e., low talent density), unilaterally copies the form of "cutting headcount" and "increasing per-person workload," this is not replicating the agile model. In the absence of capability leverage, this approach drains employees' energy and not only fails to bring a leap in efficiency but instead triggers disastrous decision fatigue.

Lower communication costs do not equal higher output quality

The strongest argument for "small teams create miracles" is the so-called "low communication cost." According to the communication cost law, it can also be theoretically deduced that reducing the number of people can indeed significantly reduce the loss of cognitive alignment.

But "running fast" does not equal "running in the right direction."

The core of complex system design lies in systematicness and rigor. When a person is required to handle multiple tasks concurrently at high frequency, limited by finite cognitive bandwidth, what is sacrificed first is inevitably implicit quality: in-depth user research, rigorous deduction of exception scenarios, and standardized construction of design systems—and this is just design.

If "fewer people" is merely to compress labor costs rather than based on a reasonable division of business boundaries, then the time saved in communication upfront will ultimately be repaid with interest in the form of "design debt" and "technical debt" in subsequent iterations.

Conclusion

A good product is delivered under reasonable resource constraints through restrained requirement management and high-standard design execution.

"Fewer people" should be to maintain organizational agility and focus, and "doing things finely" is the goal. If we depart from objective laws, ignore talent density and business complexity, and treat "doing more" itself as a management pursuit, the final result will most likely be a mediocre work with stacked features and fragmented experience.