Product team caring about quality: Devs need to balance quality with speed, and feel appropriately ashamed when something breaks on prod. To the extent that devs optimise for speed, I don't see why product would be any different. The product team has a large backlog and many important deals blocked by certain features. The incentive to optimise for speed is just as strong. The tension you get between a dedicated QA team and a dev team arises precisely because the QA team cares _only_ about quality. So by moving the responsibility to product you'll either see more corner cutting due to product optimising for speed, or more tension due to product optimising for quality. I don't think you can have your cake and eat it too.
Feasibility of no-code testing: having your browser interact with the page in the way you would like is a good fit for a no-code approach. But most of the effort in writing tests, I've found, is setting up the data (e.g. with factories or fixtures). I'm not so sure that you can no-code that side of QA as easily. If I'm right about that, it means product will end up dependent on devs to write the tests.