> don't expect engineers to do anything other than exactly what is requested. and no more. > don't expect engineers to answer question that was not asked. be t

> don't expect engineers to do anything other than exactly what is requested. and no more. > don't expect engineers to answer question that was not asked. be thorough in your requirements. don't make assumptions about prior knowledge. The inverse unfortunately describes just about every PM I've had to work with. Good developers should be asking questions to fill in any gaps in requirements that aren't likely to be considered by non-developers, but it ultimately shouldn't be their responsibility to figure out the requirements. If a PM can't provide useful feature requirements, then they probably should be fired. Here's how things typically go: - PM comes back from meeting with product owners and writes a bunch of tickets with a title and single sentence like "do the thing." - During backlog grooming, engineers are forced to ask the PM to provide more context and acceptance criteria. The PM pulls some AC out of their ass. Because the grooming is capped at an hour, all AC and behavioral descriptions are half-assed, and contain contradictions. Developers are burned out from constantly wondering WTF and just want to get out of there. Most if not all groomed tickets are wrong in some way. - PM meets again with product owners and designers to discuss changes to features being worked on. PM fails to update most of the tickets that relate to said changes. Designers, who seem to usually work outside the sprint process, make changes to their mockups without notifying developers. Developers stumble across changes to the mockups midway through developing a feature and go "WTF?" Or they've already submitted a PR and another developer notices that the work doesn't match the mockups. - Developers have Zoom meeting with PM and designers to ask "WTF?" Nobody takes responsibility. PM pretends to clear up ambiguity by taking suggestions from the developers and changing the AC of the ticket. Designers pretty much roll over to whatever the group decides because they just want to get out of there. - PM presents merged feature to product owners. Turns out the PM didn't read their minds correctly, and so follow up tickets are filed. Some of those tickets vindicate the developer's concerns or revert changes made to the AC during the sprint. - Developers are told to "ask more questions" in order to "close the loop" during sprints so that this circus doesn't happen again, passing blame to developers and further guaranteeing that the circus continues.