The difference between a product and project team is essentially about ownership. The difference between a team taking responsibility for an outcome, versus a team just there to deliver a project (output), and then move on to something else.

activity-oriented teams are prone to optimize for their own activity and not for the bigger picture of delivering useful software.

Software development is an iterative design process. In order to achieve true iteration and realize the value of fast feedback, its activities need to be performed with a single team (having a common reporting line) as far as possible. Many internet business and independent software vendors (ISVs) already operate in this way.

In large organizations... The lower tier teams (infrastructure/security) treat the higher tier teams as their (internal) customers in a problem-solving (not scope-delivery) manner.

More generally, one of the things we learned many years ago is that success does not come from projects, but rather from continuously working and iterating on an area until we achieve the necessary outcomes.

While on the topic of utilization, it is important to note that optimizing for utilization is detrimental to reducing end-to-end cycle time. You don’t improve the flow of traffic on a highway by improving its utilization (i.e. introducing more vehicles).

Specialization isn’t the problem; organizing along lines of specialization is.

The signs of project teams are plain to see: teams of mercenaries (order takers), slow velocity, little to no innovation, ballooning technical debt, no ownership of results, orphaned projects and blame directed everywhere.

In product-mode, will we end up with new, business-capability aligned silos such as catalog, order management, payment and fulfillment? Perhaps, but they are nowhere as bad as activity-oriented silos. Product-mode teams, being outcome-oriented, may at worst result in silos that still work towards a business outcome.