I'd argue for a combination of the two: a QA team that handles all products, with a mixture of specialists and generalists.
Within that team, you'd ideally want a mixture of skills: some who are skilled in product A, some in product B, and some who can float/are specialized in test areas/techniques (say, performance, security, usability, etc). This way, you can make sure people always have things to do. If you have someone who specialized in performance testing product A, what do they do when product A isn't ready for performance testing? (I'm assuming here that management won't allow someone to spend half their time improving their skills, or building tools, or something similar.)
The pros of this approach are the following:
- When a product needs focused testing for a time, you can shift people over to that product, and not have "idle" testers.
- It can allow for much easier sharing of tools, techniques, and so on.
- From a career point of view, it's easier to compare QA folks against each other versus a QA person versus a developer.
- You have to find the right sort of person for these various roles. Some people will want to specialize, and others will want to float. It can be a problem if you try to put one sort of person into a role they aren't suited for.
- Depending on the products in question, in may be that sharing skills/tools/etc is a problem, if they're different enough that they require vastly different test skills, tools, or whatever.
- The larger the team, the more institutional inertia there's going to be. On a small team, it would be easier for them to move to a new tool/technique/etc, as there would be fewer people to persuade.
Honestly, though, one advantage of the larger team model is that at some level, unless your management team is incredibly disciplined, there's almost always going to be some sharing between projects, as the problem project of the moment is going to request/require more resources. With a larger, unified team, you can absorb that more easily.
And, from a management point of view, it can be very helpful to have the QA manager equivalent in stature to development managers. This is because there are always going to be conflicts when development wants to ship, and QA doesn't think the product is ready. You ideally want that decision to be made on technical grounds, not because the development manager is somehow senior to the QA manager. Ideally, development management and QA management will report to the same manager/executive who is responsible for the overall quality of a product, and who can make trade-off decisions from a business point of view.
(This is ignoring another possibility of having the QA folks embedded in development departments, which has its own set of tradeoffs.)