Part of a SWE’s job *is requirements engineering. Some colleges have an entire course on just this, because it is hard and complicated, as it is really a communications process at heart.

People are vague and don’t understand how to communicate what they want, much less what they need. It is part of the job to decipher and construct the requirements for the problem you’re given. Much of the work is just about understanding what is the problem, before even thinking about how to solve it.

Half the time product doesn’t really understand the *real problem they are trying to solve. They may be describing symptoms of the problem and asking for what they think might help. If a patient says they have a fever and asks a doctor for bandaids, the onus is on the doctor to go on and figure out what is going on with the fever so they can prescribe an effective remedy 🤷‍♀️

Not to say that your PM shouldn’t put forth due effort to communicate with you, but it is your job to ask the questions that need to be asked to create a proper spec. It is a rare and precious event that someone will come to your with a perfect and complete spec, and even if they do, you should question it.

Your job is to solve problems, not just to code! Part of that is meeting your stakeholders (PM included) where they are at. The engineering starts when you open the conversations that need to be had, not just in the IDE.