1. Items should not be added to the backlog for any of the reasons that you list, because the idea is to build valuable software, not become a feature factory. The role of the product owner is to maximise work not done, so unless the CEO, VP or internet has genuine evidence of user need, they need to sit back down.
2. Product Discovery is a specialist skill that takes years to learn how to do well, and understanding customer needs is too important to get wrong: no market need, no sales. The person leading the research should have the word 'Researcher' in their job title - Market Researcher, UX Researcher, or Customer Insights Researcher. Non-researchers doing research is a lot like someone with no software development background coding your new app.
Leading the research doesn't mean doing it alone: I normally invite the whole product team to a kick-off meeting to gather their assumptions about their users, and then invite them to watch me test those assumptions (taking turns to join the interview call on mute, and asking a few of their own questions at the end). We then workshop the findings afterwards to decide on next steps.
3. The work of UX is to validate assumptions, not validate the product or feature. There's a crucial difference. If you give me your set of assumptions that your customer needs X and I tell you that, actually, they need Y instead, that saves you a buttload of development time. If you say "We want to build X and we want you to validate that they want X", you won't be very happy when I come back and tell you that they don't.
A useful mantra: fall in love with the problem, not the solution.
Ideally, you want to start from a position of understanding a user need, for example: "as a busy working mother, I want an overview of what school trips my child has coming up, so that I can make sure they have everything they need on the day." (You would validate these assumptions through interviews.)
You then want a list of what they're doing right now, and where those current solutions fall short.
"I currently manually enter the school trips into my personal Gmail calendar, but sometimes I forget, and have to scrabble around to find the letter from the school."
You can then gather the whole team (including a UX designer) to swarm around the problem:
How might we develop a product or service to remind caregivers about upcoming school trips?
and this problem might have dozens of different possible solutions.
By developing an experimental mindset, you can weed out the unworkable and user-unfriendly solutions early through rapid prototyping and early and frequent user testing until you are just left with one or two 'winning' product ideas.
