Golly gee, the Cranky Product Manager was recently quoted a few times in the ZDNet blog, The IT Grind. As was Saeed "Wrath of" Khan, the esteemed author of The Blog On Product Management.
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.
Really.
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 shake in their boots. 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."
What crap.
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.
Recent Comments