The first time you come across this it's a bit of a culture shock as I think most in the US are more used to having a back and forth exchange.
I probably lose 1/4 of my time to unclear specs and things that PMs assume I would know. Why they think I know anything about the industry is another question.
No one in their right mind would put an engineer on a factory line because said engineer built the machine. Yet people are completely ok handing off tasks to developers and asking them to do the mechanical part of the job.
In both cases you're only extracting half the value from that person that you could be.
That back and forth with your PM isn't wasted time, it's you digging in to better understand, and in doing so are given the opportunity to identify and make suggestions due to the expertise you have that the PM doesn't. I'll go one further. Your company should endeavor to put you face to face with the "customer" making the request if it's practically possible for exactly the same reason, and your PM shouldn't be involved at all outside of setting the priority for the work itself. This is of course ideal circumstances and there are always reasons why the reality can't match exactly, but in general this is what you should be endeavoring to do.
Strongly prefer the current system over that :)
A "bunch" is not a valid item count.
They are going to be dissatisfied by whatever colour "red" is chosen. Or with the sequence of steps to get to a goal in a paginated step flow if not ironed out first.
If something is going to expire, they need to specify the time along with the date and whether it is attached to the user's timezone or UTC.
They are going to say Firebase when they mean Mixpanel because they might have Googled something and badly misunderstood it.
You are trying to do a structured activity based on the thoughts of someone who often isn't.
Given the choice between writing code that gets tossed or a tedious and repetitive conversation where I am endlessly asking "can you be more specific?", I choose writing code. Someone else can have that conversation.
Often people aren't sure themselves what they want until they see it, or they get new/better ideas after seeing it in motion (or decide they don't like it). Good software dev is like boiling water. It's tumultuous with a smattering of chaos, but in general drives towards the goal.
It also allows you, as a developer, to take more ownership of the software as a solution. At the end of the day you're helping solve someone's problems. For me that's satisfying, even if it's a small problem.
And it's been my experience when you do that well, people love you for it.
And to be clear, I put customer in quotes for a reason. Sometimes the problem you're solving is that batch job needs to be realtime, or that one query is slow as the data got too large, ad nauseum. It's not always non-technical people.
What I never want is a PM to just tell me to make a query faster without being able to discuss with the people it affects what their use case is so I can start optimizing for the specifics rather than just in general (although sometimes that's the right approach).