>> problem-solving for others. This. I like to say that customers don't have requirements, they have problems they need solved (I hate the buzzword "solutions"

>> problem-solving for others. This. I like to say that customers don't have requirements, they have problems they need solved (I hate the buzzword "solutions"). They're non-technical so they don't know what is possible or reasonable. It is up to the PM or lead to propose ways to solve those problems. Another issue is that (this appeared on HN recently) you can't tell people anything, so it's often necessary to show them something before they can really get on board with it. At that point things start to change and people will claim the requirements are changing, when in fact they are just starting to get fleshed-out. There is a second layer of requirements which are essentially a design. Not design by a designer but an internal software design. The customer doesn't care about this level of requirement but people tend to confuse the two. Some developers ask for too much detail and some customers try to micromanage. It's the PMs job to manage this boundary.