The title of the ZDNet piece was “10 things your IT project manager never wants to hear.” Confusing that the CPM and Mr. Khan should both be featured, as both write about proDUCT management at software manufacturers, not proJECT management within corporate IT departments. But whatever. The CPM will take any publicity she can get.
Anyway, ZDNet just shared a few snippets of the Cranky Product Manager’s distilled wisdom. You, darling readers, deserve more. So here’s the CPM’s entire rant, as sent to Deb Perelman at ZDNet.
Three Things the Cranky Product Manager Never Wants to Hear a Developer Say. Ever.
1) “The product needs to be re-architected from scratch”
Re-architecting, it seems, is every engineer’s wet dream. How could an engineer possibly be expected to understand the code their predecessor wrote? Better to tear down the entire house — even though its residents are perfectly sheltered – in order to remodel the bathroom or put a cover over the patio.
Re-architecture seems to always be necessary because the predecessor never knew “what the hell he/she was doing”. Somehow the profession is littered with an innumerable number of idiots, except for the one currently doing the talking. If you believed the engineers you’d conclude that programming languages were all “WORN” – Write Once, Read Never.
Scratch that. Make it “WMRN” – Write Many Read Never.
2) “It’s technically impossible”
In the Cranky Product Manager’s experience, engineers only claim the really boring stuff is technically impossible. In contrast, the truly out-there stuff (building a warp drive, increasing Dubya’s approval ratings) is described as “potentially do-able, if only …”. Funny that.
Saying something is “technically impossible” makes marketing and non-tech types tremble like an espresso junkie. But fortunately the Cranky Product Manager has a solid code-slinging background and can call bullshit. Perhaps the WAY the engineer thinks is the Ideal is technically impossible, but almost always the customer requirements can be met via a different, more earth-bound implementation.
But too bad, the project will still be boring.
3)When a developer argues that a particular product component is PERFECT for implementation via the latest fad of development technology.
“Cranky Product Manager,” they say, “we should implement this high-speed encryption system using Ruby with an AJAX front-end. It fits PERFECTLY.”
First, in most cases the fad technology most certainly does NOT fit the problem.
Second, we’re under a deadline here! This thing needs to be DONE in 2 weeks and we don’t have time for the developer to learn the latest resume-enhancing technology on the job while that clock is ticking. And besides that developer’s slower speed, the QA team would need to figure out how to plug that new technology into their automated systems. The IT department has to figure out how to get the latest versions of the proper development tools on everyone’s desktops. Other team members need to learn the FAD Tech too, in order to do code reviews or pick up the code when that developer is sick or incapable of fixing his own bugs. The ripple effects are huge.
Don’t get the Cranky Product Manager wrong. Adding a new technology to the mix is often warranted, but it is not a decision to be taken lightly — most certainly not on some developer’s whim. Have the whole team consider FAD Tech in the planning stages of the next biggish release.
In the meantime, tell your developer to go screw around with FAD Tech at the next SuperHappyDevHouse or something. Just pray he doesn’t whip up some piece of s@#$ hack and expect you to stuff it into the product at the last minute.