There are several legitimate reasons why product groups might not make sense for your organization.
There’s a risk of breaking your internal product knowledge into silos
In an agile context, the primary role of a product manager is to inform developers about the user personas and the problems the product needs to solve for those personas. In other words, product managers must have a complete understanding of the product as a whole.
However, if you break down your resources into functional area squads, you’ll essentially share overall product knowledge at a strategic level across multiple product owners. While they can become consummate experts in their respective functional areas, these product owners will most likely not have a complete strategic understanding of the entire product and its lifecycle. It can be risky for your project’s success.
Also, by making your developers hyper-specialists in several functional areas, without allowing them to work on other projects from time to time, you risk isolating the talent from the bird-eye view of your product. So if your squads don’t interact well and often with each other, you risk getting an information bunker.
Your product may not support the Spotify model
Because the product squad approach was developed and popularized by a SaaS company, it’s best-fit for Cloud-based projects.
What if you have several related products, and they are built so that an update to one part of the product can affect other parts?
You probably wouldn’t want to restructure your product development and management team into squads because their updates might compromise the stability of the rest of the product.
Also, if your product has many interdependent components, you will often have cases where one squad will have to wait for support from another squad. And that, in the first place, would eliminate much of the value of working in the squad.
You may lose advocacy from both PM and development perspectives
One more reason why squad-based development may not work for you is that the success of a product often depends on maintaining some distance and objectivity between product management and development. The product owner must focus on the vision, strategy, and roadmap, while the development team must focus on execution.
Developers will be motivated to solve their tasks as quickly and efficiently as possible. But sometimes, the product manager will have strategic reasons for pursuing an initiative in a predetermined way that may be against the way the development team is thinking.
But suppose the product manager is on the same team as the developers. In that case, you run the risk of them not asking for X because they know that the framework will make it easy to implement Y within their team’s functional area of responsibility.
The same potential problem exists when assigning a product manager to a development team.
A product is more likely to succeed when both product managers and developers strongly advocate for what they think is best for it, even if it creates some tension between both teams.