Dude, they're too busy talking to hacks like me ;) Instead of running our mouths at each other, we should both just install the software and draw our own conclusions. Of course, that'd mean that the software would have to be easy to install...zing!

Boy, this really hit home. As a PM, I always felt like I was the QA department... I would install code that was set to go out in a few weeks, find 10 bugs in the first 10 minutes, and ponder "don't they test this stuff?"... Invariably, my laptop being "non-standard", whatever that means, was always the root cause of the problem! :-)

Remember, Steve and the bunch at Pragmatic get paid to sell services to other PMs, and they also get to practice their craft in their market. One of the 2-3 core principles of product management is that your products must solve problems that customers will pay money to rid themselves of (that's called value). I have no idea what Steve's real opinions on the Garmin are, but he's done an excellent job of defining a problem to his target market that his educational products can help solve - how to deal with lazy developers. It's the top of the mountain in product marketing - using your expertise & brand to define a problem that only your expertise/brand can solve.

Wow, so developer "laziness" is defined as when programmers don't implement functionality NOT spelled out in a requirements document? I don't call that laziness. I call that respecting the scope of the product requirements document.

Man, it kills me when developers go out in the weeds, spending days and days, writing functionality that was never called out as a requirement or needed by the customer. Eek.

To me, developer laziness is failing to write a good suite of unit tests. Failing to properly document code. Failing to have their code reviewed. Failing to test their code effectively.

As a product is being coded, developers, leads, and dev managers should work together with product managers to point out holes in a PRD... and even propose revisions. Iterative development demands this kind of cooperation. So does Agile.

I think author in the article must have been on some bad teams, with poor communication, and poor leadership. I'm pretty sure the developers themselves weren't the problem.