Collective Code Ownership vs. Collective Product Ownership?

Collective Code Ownership (CCO) is one of the major cornerstones of Agile. I guess this is, by now, a widely accepted axiom (as if axioms need someone's acceptance...).
No doubt, it is great when the developers have that genuine sense of responsibility for their software product's code quality.
But... I hate to use "but" after something as important and as beautiful as CCO, but (errr) I'll just have to...
That's code. Now, what about features?
No, I am not talking about the team's commitment to deliver a shippable feature by the end of the sprint.
What I mean is developers' trying to make the features better.
Of course, that is motivated by the desire to make the end product better, to improve the user experience, to further delight the customer... But just how far should the developers be allowed to go in their chase of the ideal product?

I am willing to say: watch out; that's a dangerous, slippery slope...
It is great when the developers care about the product, and don't just come to the office to write code from 9 to 5 (although that is legitimate, too). But this comes with the danger of anarchy.
If every contributor starts deciding what's good for the product and what isn't, you can say "good-bye" to the idea of having the sprint commitment as a contract between the team and the Product Owner.
The latter is the only one that is supposed to have the full picture of all the factors, and as such is allowed to decide what "goes in", and what gets postponed till the next version.
Individual developers may just simply not have that full picture (business considerations, time for market, competitors, etc.); if they start propagating their own agenda into the product (without getting PO's approval for that), the company may end up having:

• Sprint time spent on something that doesn't bring much business value (effectively resulting in a loss of velocity).
• Features worked on by multiple teams in parallel, with one team doing that based on a user story, while the other just follows the private initiative (as a result, loss of velocity, again; plus potentially multiple implementations of the same feature, resulting in incoherent code).
• The concept of PO-Team contract blurred.
• Features not approved by the PO creeping into the product (in some extreme cases the features may even contradict the PO's vision of the product).
• Potentially inconsistent functionality between different product areas.
• Features not covered by Help topics.

Don't get me wrong: I am all for the team members proposing new features and other product improvements that in their opinion would make it better.
But there should be a clear line between proposing and actually implementing those.

If the team members are mature enough in their adoption of Agile - great, encourage them to come and speak with the PO. But they should be prepared NOT to get frustrated if all their suggestions are played down or postponed till some indefinite future release.  ;-)

Otherwise - it may be safer for the ScrumMaster to remind the team, from time to time, that - as the name hints - Product Owner is the one that owns the product!
:-)