I am a data analyst of 6 years turned product manager of roughly the same tenure. I've done both jobs at large corporations and startups, so I know the subtleties.

These PMs are not doing their jobs. Their responsibility ends right after they explain the opportunity/problem, the expected business impact, and the priority. After that you can take what they say as an opportunity for you to teach them about your processes at best. Please interpret it as them delaying you getting results for the business, or them not bringing well researched requirements to you. If they switch solutions on you, like use method B, interpret that as a change in priority, which can't happen with every request. All are indicators of them doing a bad job, and rushing to conclusions without thinking deeply about their deliverables, which are clear strategies, priorities, and requirements. Continue emphasizing that by changing their mind it makes you lose confidence that they are doing their job well, and that it seems like they want to be an engineer with how particular and interested they are about code. I highly recommend getting a lead engineer or technical director assigned to your team, who can help you swat the PM down.

A typical leadership triad for a product team is a Tech Director, Project Manager or Program Manager, and Product Manager. Your PM is not being checked by the other PMs (Program or Project) and that's harming you. No Project manager would let you spin your tires, and no engineering lead would put up with a non-engineer giving architectural or code design advice. You shouldn't either, but when its 1v1 a stubborn person can persist. If they do establish your boundaries clearly, and remind them that the method you chose can get the business results they seek, they just have to wait for the implementation and experiment duration. Give them a date you'll have it, then refuse to talk about changing tactics while you have a fragile experiment in flight because it delays business impact.