The Cranky Product Manager

Three Things The CPM Doesn't Want to Hear

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.

A Parable on Fake Release Dates

One January, the DysfunctoSoft Veeps of Product Management and Engineering got together and decided the date for the next product release. 

Did these Illustrious High-Ups take into account how long it would actually take to develop the features they want? Hell no. They picked a date that would keep them from getting in trouble with the CEO.  A date approximately 8 months away -- in August. 

THEN, because DysfunctoSoft had a long and perpetual history of never completing a release even close to on time, the Veeps told Engineering that the release date was a mere 5 months away -- in May. And they goddammit they meant it: Come hell or high water you freakin' engineers better finish this release in May or the CEO will shut down our division.

Why the lie?  Why the empty threat? Because if those f-wad engineers knew the actual date was August, well then the release wouldn't really be done until November. Or so the thinking went. Gotta hold their feet to the fire, those untrustworthy lazy engineers.

So what happened next?  During the weekly PM Team meeting, the Veep of Product Management confessed to the team that the REAL release date was August, not May.  But this tidbit was Not To Leave This Room. Don't tell! Or else the engineers won't do anything between January and May except play foosball and porn-surf the Internet.

Meanwhile, the Veep of Development held his weekly meeting withall the development managers. He told them a secret: The REAL release date is not until August!  But don't tell the engineers!  Or else they'd do nothing between now and May but laze around eating bonbons and creating You Tube tributes to Star Wars.

Next a sham schedule was produced, one that required all design be finished by end of January, coding done at end of March, beta testing starting March, and the final release in late May. 

Somehow (and no one has any idea how this happened?!?), the engineers didn't fall for it. Maybe they remembered that NEVER before had DysfunctoSoft shipped a release within 6 months of the originally stated date. Maybe the engineers recalled that in every prior release, the Veeps lied to them about the actual "drop-dead" date for the release.  Maybe they saw that the schedule jammed over 8 months of work into just 5 months, figured it was impossible and just gave up.

So May passed, and then August. It was November before the release finally shipped. Three months after the "real date." Six months after the "fake date". The Veeps were so glad they said May was the fake date because if they had said August then the release wouldn't have come out until February!  Or so their thinking went.

(Note: If you are having trouble following this, you are not alone. Written clarity sometimes eludes the Cranky Product Manager, so refer to this diagram).

Then it was January of Year 2. Time again to plan for the NEXT big release. The Veeps met, and again picked a "real" release date 8 months away, in August once more. Recalling that the release slipped 6 months past the "fake date" last time, they figured this time they needed a "fake date" in February to make the "real date" in August.

And so the developers were presented with a sham schedule showing eight months of features being designed, developed and beta-tested within 2 months. 

And the release proceeded much as any rational human being would expect. Yup. The release came out in November - a full 9 months after the "fake date".  Once again the Veeps congratulate themselves on their decision to put out a fake date of February, because if they hadn't, well, the release would be that much later!

So what do you think will happen in Year 3?

Well, the Cranky Product Manager got an 800 on that GRE section with the funky logic problems (if Tommy is sitting across from Alan, and Alan is sitting next to Donna, where is the CPM sitting?), so allow her to calculate.  For the next release to be actually completed in eight months, the "fake release date" needs to be 9 months earlier. In other words, the Veeps will have to tell their teams to finish the release one month prior to even starting!

That is, if this "fake date" crap even works.  Which, of course, the Veeps insist it does. It seems ingrained very deep in their psyches, as it is with many executives in the software industry. No matter how much evidence there is to the contrary.

What, oh what, is a Cranky Product Manager to do?

FAD: The Methodology to End All Methodologies

The Cranky PM pronounces this send-up of Agile to be a work of comedic genius.

Enjoy your Monday.

Persona Non Grata

OK, contrary to popular theory, the Cranky Product Manager is not dead.  She blames her lack of blog posts on the holiday madness, especially her miserable attempt to play Santa for her infant. And then, just as the holidays wrapped up and the last thank you note was written, the Cranky Product Manager was held against her will in a smoke-filled hotel for a entire week, forced to give product training to a bunch of hungover sales droids. And then attend their booze-drenched, endless awards ceremony.

Anyway, back to blogular business. 

These days, seems like most in the product management blogouniverse think user personas are the shizz, the best thing going since the invention of the triple shot grande skim latte.

Never able to resist development fads, everyone at DysfunctoSoft is getting on this persona bandwagon.  Example:

VINEETA
Vineeta is 33 years old and an entry-level IT manager at a mid-sized insurance company located on the Philadelphia Main Line. She manages a claims payment application for the auto insurance division. The application was developed before she was born. After a messy breakup with her fiancee one year ago, Vineeta moved back in with her parents. Her bedroom is now the same one she grew up in, and there's still a poster of Green Day on the wall.  Vineeta is an Aries and enjoys long romantic walks on the beach. She has a 7-year old cat named Whiskers, whom the ex-fiancee detested.

Well, gee. How nice.  What a nice, although potentially fragile, person that Vineeta seems to be. The Cranky PM sure hopes that DysfunctoSoft builds her some nice software.....

hmm.  yep.

OK, the Cranky Product Manager HAS to say it.  SO WHAT?  WHO FREAKIN' CARES about Vineeta's hobbies or pets or love life? Seriously, what do these colorful details have to do with how Vineeta uses DysfunctoCrank 7.5?   

Why are all the personas the Cranky PM sees littered with this type of crap detail instead of the facts that REALLY matter? Such as: How much time does Vineeta spend working with the application? What level of technical expertise does she have? What types of tasks does she usually do in the app?  What circumstances would make her depart from the usual routine, etc...?

ARGH.  Cranky Alert! Cranky Alert!  Shelter in place, please!

How to Get the Respect of Development

When starting at a new company, even the best product manager finds herself in an awkward position -- the position where most of the developers don't listen to her and disrespect her. While this is a temporary condition for the successful product managers, some are never able to dig out from this living grave. 

So, let the Cranky Product Manager help.  Gather 'round and sit at the feet of the CPM whilst she bestows her big-league wisdom upon your sweet little ears. Wait with baited breath as she whispers in your ear the Secret of Gaining the Respect of Development.

Step 1: Stop being an Asshole. 

For some of you, this might require a personality transplant. The CPM recommends you request a personality that is neither overly extroverted nor excessively introverted, easy to get along with yet somewhat stubborn, detail-oriented yet able to see the big picture, market-minded yet technical, diplomatic yet daring, a risk-taker but ultimately sensible, a visionary yet pragmatic. 

In other words, get yerself a personality that excels in its middle-of-the-road-ness.  A  personality that has reached the pinnacle of mediocrity in all respects and revels in it.  A personality that, lacking any strong characteristics, resembles tepid water in its complete nondescript-ishness and ability to go with any meal.

Don't feel bad if you need a personality transplant. It won't shock you to learn that the Cranky Product Manager needs one too. In her cranky old age she's become too likely to say exactly what she thinks, much to her development team's (and her boss's) chagrin.

Step 2: Become an expert in the current customer base.

First, before the Pragmatic Marketing folks jump down the Cranky Product Manager's throat and start screaming "be a MARKET EXPERT not a CUSTOMER EXPERT, you effing IDIOT," let the CPM explain: You gotta walk before you run. 

Before the Code Boyz  (and Grrlz) will accept the Neophyte PM's market expertise as gospel, they first need to believe that the NPM actually knows the names of some customers.  Because, for some reason, the Code Boyz/Grrlz assume that Product Managers have no clue about customers. This is because the average developer or development manager thinks it's OBVIOUS what the customers want. After all, they actually MET two or three customers once, and maybe they even fixed a few bugs at a customer's request.  And if you, the Neophyte Product Manager, disagree with the "obvious" course of action... well, then, it must be that you don't know anything and are pulling requirements out of yer ass.

This is called "projection" in psychiatric circles.  The Code Boy/Grrl who pulls requirements out of his/her posterior quarters or "gut" or whatever accuses the Neophyte Product Manager of doing the same.

The way out of this quagmire?

Learn WAY more about the current customers than the development team.  Then, prove it to those hateahs beyond a shadow of a doubt.  Club them over the head with your wellspring of customer knowledge.  Until no one can deny you know yer shite.

Fortunately, becoming a customer expert does not take that long if you really concentrate on it. But the CPM is tired. Worn out from dealing with a screaming infant all day. And she's not talking about her beloved spawn. Nay, she's referring to her (usually) favorite sales engineer who has a major case of whiney-itis.  (a story for another day)

So, tune in next time for the CPM's "100-day plan for Becoming a Customer Expert and Proving it Again and Again and Again to Development". Coming out sometime in the next 6 weeks. Promise.

Happy Halloween and Peace out.

So You Think "Agile" Methodologies Exempt You From Product Management

Yo, yo, yo!  Listen up, Enterprise Software Developers.  Yeah, you!

The news: The Cranky Product Manager knows that there is a certain percentage of you that doesn't really care for her or her PM brethren.

And why?  Because the Cranky Product Manager is a pain in your ass. Because, YES, she totally cramps your style. 

For one thing, the Cranky PM always prioritizes the boring projects higher than creating super-cool new products, or rewriting existing products from scratch. In other words, she wants you to FIX (not completely rewrite) Joe Idiot's effed-up code so it can handle multiple users.  Instead of doing that WICKED COOL feature -- the one you pet-named "Extreme E" -- that 64-bit, Web 2.0-ish, open source, DRM-defeating wet dream (based on an SOA architecture and Ruby on Rails, of course). You know, the idea that occurred to you in between that mega-bong hit at Softwarehaus's annual Geekapalooza party and 4am, when you started drunk dialing all your ex-girlfriends.

The other thing the Cranky PM does that is TOTALLY annoying is always say things like "we're not seeing market demand for Extreme E."  And whenever you try to shoot down her proposed projects as being stupid or irrelevant, she always starts reciting a list of customers who want it or need it, explains the new markets her beloved project would help DysfunctoSoft attack, and then she starts explaining use cases. Ugh.  If that wasn't bad enough, if you persist, she'll bore you to death with a freakin' slideshow containing revenue projections for her stupid, dumb-ass project. 

Doesn't she realize that her projects are freakin' BORING?  No technical challenge. And who wants to sully his hands fixing some other engineer's code?  Disgusting -- like sloppy seconds.  None for you, thank you. You need excitement in your life. You need to create something cool, something from scratch, something you can brag about or at least put on your resume.  Her project does not qualify.

But the thing that REALLY pisses you off about the Cranky Product Manager is when you try to shoot down a project with the "it's technically impossible" bullet. This jujitsu move is supposed to be a winner, that's-it, end-of-discussion type of pronouncement.  It works all the time, especially with the Marketing weenies. They all run and hide under their desks, shivering with fear. But it doesn't work with her. The Cranky Product Manager always says something like "Can you explain why not in more detail?  Because I'm not sure I understand how <Competitor X>, <Competitor Y> and <Related Software Product Z> can do something that is VERY similar.  How were THEY able to do it?" And then when you spew some crap about multi-threading, messaging protocol design patterns as a confuse-the-enemy tactic, she starts talking about possible approaches to prove you wrong.  Bitch.  Doesn't she understand that it is technically impossible because her project is so BORING it is not technically possible for you to stay awake to work on it?

If only you could get rid of product management, life would be so much easier.  What do you need them for, anyway?  You talk to 2 or 3 customers (out of 2500) a year, and you know at least two of them would totally LOVE Extreme E.  And you pretty much know what the customers and market need, anyway, at least if they are SANE. Because it's not that complicated. It's OBVIOUS what the product needs to a SANE person.  Fortunately, you are sane.

And THEN, you read about this thing called "Agile Product Development."  And you learn about Scrum and Extreme Programming, etc... And you think, "AHA!  At last! This is the solution! Who needs the Cranky Product Manager and her ilk when I have this awesome methodology?!?  Instead of having that old school, waterfall-worshiping PM prioritize me to death, I'm going to code blissfully for two weeks and then get feedback directly from the customers!"

Well, nice fantasy, Code Boy.  But the Cranky Product Manager says, Not. So. Fast.

Realize why the purest form of Scrum and other agile methods do not provide for a Product Manager: because they were designed for CUSTOM SOFTWARE DEVELOPMENT.  As in, there is just ONE customer.  This is typical of IT projects in big companies, or even consulting engagements.  And guess what, if there is, in fact, just ONE customer, then Hell Yeah, the Cranky Product Manager agrees with you.  Product Management is not needed.  Get a PROJECT manager (aka ScrumMaster) and a customer project owners (aka Product Owner) and go to town.

But what if you are at a commercial software vendor, where your software has to meet the needs of MANY customers, maybe thousands?  And where your software has to not just meet the needs of those many CURRENT customers, but also attract new customers in the future?  New customers whom you haven't met yet. New customers in different industries who are solving problems you never even knew about.

Are you, Code Boy, going to show ALL the customers the result of your latest sprint cycle, every 2-4 weeks?  And are you going to gather up a good representative panel of all future customers and get their direct feedback every 2 weeks as well??  And how are you going to decide which customer has the final word?  Oh wait, that sounds like a lot of work, doesn't it?  Maybe it isn't even "technically possible."  If you had to get the feedback from all those customers and prospective customers every 2 weeks, well you wouldn't have any time to code. And neither would any of the other developers.

In fact, getting all this customer feedback sounds like a full-time job, as does identifying who the  prospective customers are and what they are likely to require.  And sifting through the contradictory wants and needs of such a wide customer population, well, it will be time consuming. You can't do everything that every customer wants or thinks is vitally important.  You need to prioritize. You need to come up with the feature set that would make the company the most money.  But that kind of analysis needs extensive research and familiarity with the current (and future) customer base. It will take time. A lot of time.  Time you don't have.

Then a solution occurs to you.  Maybe you should hire someone to be the "Voice of the Customer" for your Scrum team.

And when you do, the Cranky Product Manager or one of her colleagues would be glad to help you out. Call the role "Voice of the Customer", "Product Manager,"  "Product Owner", "My Enemy" or whatever... Whatever title floats your boat. They all mean same thing.

And then, the Cranky Product Manager (or someone just like her) will be back to cramping your style once again.

That "All the Responsibility and No Authority" Saying

"The most challenging thing about product management is that you have all the responsibility but none of the authority," the job candidate said. Quite satisfied with his answer to the Cranky Product Manager's stock interview question, the candidate flashed her a knowing, gleaming white smile. That was the signal. The Cranky Product Manager was supposed to epileptically shake her head in agreement and, at last, connect with the candidate.

No such luck. Instead, she rolled her eyes... violently. Very violently indeed, almost murderously so. Not the best manners for an interviewer, but seeing as the Cranky Product Manager is not exactly a, well, refined individual, she had no control over her response to his clichéd answer. The Cranky Product Manager already heard two other candidates spin the same old tired yarn that morning. In fact, she read a version of that I'm-a-powerless-product-manager-woe-is-me tale on at least one other blog that week (Product Beautiful, a great blog that the Cranky Product Manager recommends very highly, despite that one post).

But worse than trite, overused and unoriginal, this sentiment -- universally shared by the world's lamest and whiniest product managers, and even by some of the good ones -- is way too self-congratulatory and is just plain wrong.

Yes, as a product manager, you are indeed responsible.  Your job is to corral and coordinate the hoards of developers, testers, marketers, writers, sales folks, support engineers,  professional services staff, and more -- the entire cast of characters needed to successfully bring kick-ass products to market.

And, yes, as a product manager, it is true that you rarely have authority. No one (except maybe a few more junior product managers) reports to you. You can't fire people for not taking your orders.

But here's the thing... SO WHAT!?  So these people don't report to you. So they don't have to respect your au-thor-i-tah.  Big freakin' DEAL! If they DID report to you, do you honestly think your job would be any easier?  Do you think they'd magically start listening to you and doing what you say?

Last time the Cranky Product Manager checked, high tech product folk, no matter what their job functions, were not minimum wage workers. As intellect workers, high tech-ians don't do anything  just because their bosses command it. Nope. Those damn independent thinkers need to be persuaded. They need to buy into the plan and then they act. Sure, sure, those folks might occasionally placate the powers-that-be by half-heartedly lying there, closing their eyes, and thinking of England. But that kind of soulless attempt to merely get the boss off, uh, your back... well, it's usually worse than no attempt at all.

So, in this respect, those other "real" managers -- and by "real" I mean managers who officially manage people -- have just as tough a job as product managers. Probably tougher. People managers must ALSO corral and coordinate their people, and get them to do things that they wouldn't normally consider if left to their own devices. Like product managers, they legitimately do so ONLY by persuading and inspiring. NOT by fear nor the unspoken threat of bad performance reviews or firings. NOT by flexing their so-called "authority."

In fact, as someone experienced in both people and product management, let the Cranky Product Manager assure you that the only effective difference between a manager with "authority" and a manager without is that with authority comes a lot of tedious crap: paperwork galore, mind-numbing sexual harassment seminars, and -- most dishearteningly -- the occasional hell of laying off a subordinate who does a great job .

So, whiney product managers of the world, STOP bitching about "all the responsibility with none of the authority" right now. Get out of your minimum-wage-oriented headset and recognize that official authority is irrelevant to anyone in high tech companies. Instead consider, even if briefly, that your difficulty in getting others to follow your lead might be because your arguments are not compelling.

Or maybe, just maybe, they don't listen because they know you think of them as minions who are motivated by fear. In other words, maybe you're a jerk.

The Joy of the Bug Scrub

  Please help the Cranky Product Manager.  She believes she is slowly losing her mind. Her grip on reality is oh-so tenuous at the stage of the product release cycle, approximately a month before a major release.

The source of her frustration / dismay / blinding rage / abhorrent taste of bile at the back of her throat?  The ludicrous arguments she gets into during the Daily Bug Scrub meet. Witness the joy for yourself:

*********

Sally, the Spineless Release Manager: Bug 17854 is "The product's main launch page contains blatant spelling errors. These must be corrected prior to release."  It was filed by the Cranky Product Manager.

Larry, the Lazy Development Manager: Oh COME ON, Cranky Product Manager.  PUH-LEEASE.  This is NOT a high priority. (Turns to the Spineless Release Manager.) Defer it to the service pack.

Cranky Product Manager: Whoa there, Beeyatch! What the effing eff are you doing?  Don't you dare defer that bug or the Cranky Product Manager will open youz up like a can of tuna fish!  These errors are blatant, and on the first product screen the users encounter! Our company's name is misspelled in four different places!  And since when is "Welcome to Techno Prodoct Suit 6" acceptable English?  It is all SO sloppy and SO in-yer-face! EVERY customer will see it and conclude that we outsourced development to dyslexic third graders from Cambodia!

Larry, the Lazy Development Manager: Duh, Cranky Product Manager. I'm not saying that everything is spelled correctly. Of COURSE it's a bug. But our release criteria is clear! We shouldn't hold a release for a severity 4 bug, which THIS is.  Let me quote: "Severity 1 - Data loss or software crash. Severity 2 - Major functionality is missing or doesn't work with no workaround. Severity 3 - Functionality is missing or doesn't work, but there is a workaround.  Severity 4 - Functionality is unaffected."  Spelling errors don't affect functionality - Sev 4 it is!  Defer it!

Sally, the Spineless Release Manager: He's right. I'm deferring it. 

********

Oy.  Double Oy with cheese on top. These arguments are enough to make the Cranky Product Manager feel like she's stuck in the smoking room of the Tokyo Narita airport, suffocating on the toxic fumes, unable to breathe and developing a profoundly splitting headache (or maybe it's like that hangover after a night of chocolate martinitis and smoking cigars... hmm).

Did the Cranky PM already mention a similar argument about a toolbar button that was so large it didn't actually fit on the toolbar? Or the dialog box that instructed a user to hit "any" key to dismiss, but in reality only accepted the space key?

It is enough to drive the Cranky Product Manager toward office supply abuse, specifically of monitor cleaner and dry-erase markers.

But don't you worry. Rest assured that the Cranky PM nearly always gets her way in the end. Despite her crankitude, she is persistent and ultimately persuasive.  She might lose the Bug Scrub battle, but she ultimately wins the war. There may be spelling (and grammar) mistakes in her blog posts, but never in her products.

How to Piss Off Development in a Really Big Way

The Cranky Product Manager knows an individual -- let's call him The Asshole Product Manager (APM for short) -- who once committed that most grievous of product management sins: pissing off development. 

We're not talking about an ordinary "pissing off" here.  This was big -- well beyond the annoyance that developers typically feel when their PM asks for an idiotic new feature at the 11th hour of a release. No, that oh-so-typical tension pales in comparison to how Engineering felt about the APM.  This was extraordinary; mammoth, even. A level of pissed-offishness that defied reason. Maybe you'd even call it hate.

How did the APM do it?  How did he rise to such high levels of intense animosity? How did he sink to such low levels of respect?

Allow the Cranky PM to recount actual quotes from this ghastly creature's mouth:

"I'm pleased to introduce the new features for MY product, the <generic product name here>."

"This feature here is really cool. The idea for it came to me while I was vacationing in the Cote d'Azur."

"I decided to have my team work on this great feature first.  Next I'll get them to work on Y."

"<Insert Sales VP name>, the reason the release is late is because Development isn't doing its job."

Comments like these liberally peppered the APM's presentations to higher-ups and customers.  Each time she heard them, the Cranky PM nearly gagged from the pungent bullshit smell emitted by the APM. Who knew that the APM was the creative force behind these bold new products, that all the credit was due to him (unless the product sucked, of course)? Who knew the APM controlled such a large team of developers -- that they reported to him? 

Although the APM's words were not outright lies, and even might be "technically" correct, they were definitely not true. He deliberately misled to make his own role seem that more important. Development knew about it and hated the APM for it.

And now for the Cranky Lesson of the Day:

The product belongs to the entire team, not the Product Manager. Because the Product Manager might be the most visible member of the team (getting quoted in the industry magazines and giving presentations to the Board, etc.), the Product Manager has a responsibility to promote the team as well as the product.  She must highlight their herculean efforts and amazing results, give credit and praise early and often, deal with team conflicts and problems in a respectful, private manner, and not hang the team out to dry when bad news is coming down the pike.

It's simple, common decency. Developers will despise any product manager who does not, at least, afford them that.