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.

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.

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.

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.

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.

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.

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).

Organizing by activity gets in the way of lowering batch size of work that is handed-off between teams.