&gt; Won&#x27;t nail down the customer&#x27;s actual problem, describe it clearly to you and let you come up with a solution. They will just pass on the customer&#x27;s proposed solution and insist that you build it.<p>It&#x27;s actually a bit worse than that. Customers almost never <i>know</i> their problems; instead, they <i>understand</i> their problems through the accumulated knowledge of their profession, and have a very hard time stepping out of “the way things are done” to nail down their ultimate goals.<p>One of our biggest challenges as developers is that software engineering is very much a meta-profession: Being fully competent in computer science is only useful if you can apply that competence to real-world problems, and that inevitably means having to become expert enough in a field to which you may never have had any exposure.<p>A good PM understands this and turns development into an iterative process in a tight loop with customer feedback: You push the project forward a little, check with customers, apply their feedback, and lather-rinse-repeat until you&#x27;ve come up with a good solution—one that typically <i>innovates</i> on the status quo.<p>A bad PM tries to spec everything ahead of schedule and never really gets off the ground, her best possible outcome being automating existing processes at the tail end of a waterfall-induced nightmare.<p>A worse PM is overwhelmed and avoids nailing down details, seeks no customer involvement, and leaves things to fester for weeks without any feedback. I don&#x27;t know anyone who enjoys being on the poor team tasked with dealing with that kind of work.<p>Incidentally, this is what I&#x27;ve always taken agile development to mean: It&#x27;s not about stand-ups and kanban boards, but rather about acknowledging and embracing the fact that programming is an inherently inexact science.