A BIG thank you to the organizers of the 5th annual Silicon Valley PCamp.  As usual, it was wicked awesome.  650 Product Managers in one place!  Wow!

The Cranky Product Manager was very impressed by the quality of the presentations, as well as the organization of the event. Well done, everyone. The organizers did an absolutely tremendous job.  And to think that we get to attend for free!  It's amazing.

Except for one thing (and it is absolutely no fault of the organizers):

Ballot Stuffing.

The Cranky Product Manager (and no doubt your mother, who TRIED to raise you right) has one simple request for you:

==> If you are NOT planning to attend our PCamp, don't vote on the sessions! EVEN if a vendor bribes you with free stuff in exchange for your vote.

If you participated in this votes-in-exchange-for-free-crap scheme, SHAME ON YOU.

You screwed up the room assignments and screwed over your fellow product managers.

Sparsely attended sessions, that nonetheless fraudulently garnered a lot of votes, were assigned to the biggest rooms.  More popular topics were assigned to tiny rooms that ended up overflowing with people and unable to accomodate everyone who wanted to attend.

And a note to the vendor(s): Why are you even doing this?  The Cranky Product Manager doesn't get it.  It does not make you look good.  If no one wants to attend your sessions based on their own merits, why tilt the playing field in attempt to put the session on? Instead, why not take the untampered-with voting as market feedback on your offerings, and next time propose more compelling sessions?  

You've heard that old chestnut. You've seen it in a million articles. The big advice Sales Droids offer to Product Managers is "Don't just talk about features.  Tie the features to problems."

And whenever the Cranky Product Manager sees Yet Another Article offering this advice, she thinks, "Doesn't every product manager already know this stuff? Duh? How is the Cranky Product Manager going to create a blog post from this nugget of obvious non-wisdom?"

But then the Cranky Product Manager thought about it.  Then she had a nice glass of Chardonnay. Then more thinking. And then mentally watching the game film from all the customer presentations she's ever given or watched another PM give, and from her years of observing SEs and SalesDroids interact with the customers.

And here's what the CPM came up with.

When It's Good (with a sex analogy on the side)

There are times when the SalesDroid-PM-Customer interaction is, well, orgasmic: everyone is in sync, everyone is providing what the others need at exactly the time they need it, and everyone leaves satisified and revved up to do it again.

It does happen sometimes. About as often as the Detroit Lions winning a game, but it does happen.

When It's Bad (with yet another sex analogy)

But more often, it is a clumsy, inept dance, with everyone thinking he's/she's giving what the others need but completely missing the mark. Kind of like the Cranky Product Manager's freshman year boyfriend. (oooh! badump dum.)

In these cases, the Cranky Product Manager will bet ONE MILLION DOLLARS that the product manager in question truly believes she is tying each feature to customer benefits, all while the SE/Account Rep thinks the PM is just blathering on and on about features.

The Disconnect

How can this happen?  Because there are several steps between  the "we added Warp Drive in release 2.0"  PM-ish statement and the "Warp Drive increases your revenues AND decreases your costs"  Sales-ish statement.

Using this example, the PM would probably say "We added Warp Drive in release 2.0.  That makes our rocket ships now go faster than the speed of light, which means space travel will take one bajillionith of the time it currently does". And the PM often leaves it there, believing she successfully tied feature to customer benefit.

Meanwhile, the Droids think the PM left out the business benefit.  After all, she did not tie the warp drive feature to either "saving money" or "making more money" (the only two customer benefits some Droids can understand).

Thus the schism.

To most PMs, it is OBVIOUS that faster space travel means people will spend more time working instead traveling, and will thus become more efficient, saving money.  And that with Warp Drive we'll be able to reach more of the galaxy and thereby increase the number of customers we can reach, increasing revenue.  blah, blah, blah.

In fact, it seems SO obvious that many PMs worry they'll insult the customers' intelligence or annoy them if the Product Manager explains how each and every feature ultimately saves money or increases revenue.

Truth is, the customers probably need a bit more hand-holding.  As Product Managers we are genetically engineered for our superior feature-X-yields-benefit-Y perception. We forget that not everyone thinks like that.

But on the OTHER hand, the SalesDroid who can only talk about "saving money" or "making more money," (aka "lower TCO" and "increased ROI"), often seems like a huge dumbass to the customer. Trust the Cranky Product Manager on this, she once was a customer.

An Obvious Tactic That Often Works

So, for Product Managers, here's a technique that sometimes works:

1. Before demo-ing or presenting the roadmap or whatever, ask the customer about his/her problems and the benefits that he/she is seeking from your software.  
2. NOTE THE EXACT WORDING THE CUSTOMER USES TO DESCRIBE THE SOUGHT-AFTER BENEFITS.  
3. During your demo/presentation, tie the features back to the specific benefits the customer seeks, using EXACTLY the same wording.

Of course, this technique only works if you are able to talk to this customer one-on-one beforehand; it works less well if you are presenting to a huge crowd at a conference.  Also, this technique does not guarantee that the SalesDroid will be happy, only the customer.  After all, the SalesDroid might not understand the benefits the customer seeks - they might be too  "low level" for a Droid to possibly comprehend.

This concludes the Cranky Product Manager's "Obvious Lesson of the Day."  

No doubt, huge swaths of PMs are out there saying "Isn't this advice obvious?  Doesn't every product manager already know this?"  Hopefully, most of you do.  But for those who don't, or who occasionally forget, hopefully this advise is more specific and more actionable than that "Tie features to benefits" platitude.

Seems like everyone in the Product Management blog-o-universe just loves to chat about where Product Management should report in the organization.  (Sorry, I don't have time to provide the links right now,... maybe someone can provide some in the comments?)

Unsurprisingly, among us Product Management weenies of the world, the overwhelming consensus that Product Management should report directly to the CEO.  

Thing is, asking this question of product managers is a little like asking a five-year old if candy should be served with every meal instead of vegetables.  OF COURSE the five-year old will opt for candy instead of nutritious veggies.

OF COURSE, the head of Product Management will say that he/she should report to the CEO, because it's cool to say you report to the CEO. By reporting to the CEO, a whole new world of wicked awesome job titles becomes available. Ones like "Executive VP of Product Management," "Chief Product Officer," and "Grand Master Poobah of Productulation and Productification." Just think of how much more awesomer your business cards could be with that type of kick-ass title on it!  Your mother -- and more importantly, your mother-in-LAW-- would be so freakin' impressed.

OF COURSE the in-the-trenches product manager will say that the Product Management function should report directly to the CEO. That elevates the perceived importance of Product Management in the organization, doesn't it? It brings you one, or maybe even two, steps closer to the CEO, and you're only a few heartbeats away from the throne after that! Maybe they'll even ask you to take over the company if all the executives die in a tragic if a plane crash (hey, it could happen; last year, they all went to that executive retreat in Hawaii together)! World domination awaits.

OF COURSE the product management training firms and product management consultancies say that Product Management should report directly to the CEO, because that makes it easier to sell higher-priced engagements. They need even more money to stuff into their money chairs and money sofas, plus it's fun to make money angels on the floor next to that huge pile of money. (!!!MONEY!!!) 

But will any of these self-interested parties acknowledge these reasons?  OF COURSE NOT.  Instead they will all put forth the argument that reporting directly to the CEO is indeed the Best Thing For The Company, and quite possibly for civilization at large.  They might even believe their own arguments.

But is it REALLY the best thing for Product Management to be so-elevated?

If it is indeed the best organizational structure, why do so few companies do it?

If it's the best, where's the proof that companies with elevated Product Management functions actually get better results?  To the contrary, one of the most successful companies in the industry - Apple - has a significantly DE-ELEVATED (that's not the right word... is it deflated? depressed? ) Product Management function.

The Cranky Product Manager has said it once, she'll say it again.  If you have _good_ product managers, who are savvy influencers and can set a true vision and roadmap for their products,  it does not matter one freakin' bit where they reside in the organization.  Because they will get the job done no matter what.  They will make the necessary alliances and get people on board. no matter if they are within the same organization or not.

In fact, the Cranky Product Manager usually suspects that those who whine too much about Product Management's place in the organization are likely not so great at their jobs.  Her five-year old child would agree.

The Cranky Product Manager has returned from the land of sweatpants and spit-up (aka maternity leaave), and is now back at Dysfunctosoft three days a week. She's still sleep deprived and cranky, but is enjoying the conversations with adults and the astonishing luxury of going to the bathroom BY HERSELF IN PEACE without someone having a mammoth conniption fit.

50s mom

We'll see how it goes, being a part-time product manager. The Cranky Product Manager is skeptical about the plausibility of such an undertaking. Can product management be done part time? The Cranky Product Manager would love to hear from anyone who has done it successfully, or unsuccessfully for that matter.

Surprisingly, Dysfunctosoft did not fall apart while the Cranky Product Manager was on maternity leave. The place is indeed still standing. However, they did do some really stupid shit.

Example: they pushed out a release with release notes that were a direct export from Bugzilla, and apparently no one bothered to read them before publication.

So what, not a big deal, right?

Reading the release notes is one of those minor details, part of that 80% of cruft that delivers little value to the customer. Product managers should just blow that stuff off, and concentrate on the most meaningful 20% of tasks – the product strategy, the positioning, the user experience, the pricing, etc. – right? Besides, it's probably someone else's job to dig through the release notes. Surely, some QA weenie will be delighted to file a separate bug for each and every grammatical error.

Well...WRONG!

Apparently, the Bugzilla export contained the details of each and every person that reported the bug, including their e-mail addresses and personal telephone numbers. And no one checked it or even noticed. Even though reviewing the release notes was on the release checklist.

As you can imagine, the customers are thrilled beyond words that the world now has their cell phone numbers, although they would be more happy if their names and numbers were inscribed on a bathroom wall ("for a good time call…"), because at least spammers don't usually read bathroom walls. As for the Dysfunctosoft Sales Force, well they are SO psyched that a competitor is now using the release notes as a to-do list of prospects to lure away.

So what can we learn from this parable?

That the main purpose of product management is to have some FREAKIN' common sense, when no one else seems to have any?

That the seemingly little things, that ones you would assume can be safely ignored, might blow up into big effing messes?  

That this is the natural result of the Cranky Product Manager's control freakishness, and that she obviously created a product team culture where no one else can or will take responsibility for such matters?  (Believe the Cranky Product Manager when she says that this is the first thing that occurred to her. )

That the Cranky Product Manager's new intention of "focusing on just the big things" and letting the small stuff go, so that she can fit her full-time job into a mere three days a week, is doomed to failure?

Stay tuned.

(Seriously, if any of you have figured out how to do product management with two small kids who get sick a lot, a spouse that work full-time and travels a bit, and no family in the immediate area, please give the Cranky Product Manager some advice.)

There will be no chuckles or laughs in this post.  

Why?  Because it is about a serious topic - how a DECENT company deals with the death of one of its employees.

The Cranky Product Manager has a bit of first-hand experience here. It was long ago, but the wounds are still fresh.   Let's just say that DysfunctoSoft handled some of it well, and some of it was handled just horribly. Enough that people still talk about it.

So, managers and execs, listen up.  In the unexpected and unfortunate event that an employee dies, keep the following in mind.

1. If the employee died in the office, hire some grief counselors and bring them onsite the very next day.  Maybe you should requirethat the people who actually found the dying employee (or tried to help/revive him/her) spend at least 30 minutes in a room with a grief counselor, even if they say they do not need it.

2. If you are the manager of this employee, be decent and either call or meet with the spouse or next of kin yourself.  If you knew the employee pretty well, you are most likely the most appropriate person to break the news.  Don't be a wussy and leave this to some anonymous HR person. BE SENSITIVE.  If you have difficulty being sensitive, ask someone who IS sensitive what you should say.  And don't delay!

3. When the time is right, ask the next of kin about funeral arrangements and ask if co-workers might attend.

4. If co-workers are invited, allow employees to attend the funeral.  If you don't give them time off, well you're just an asshole. 

5. If the employees manager is at a different location, have him/her travel to the funeral.  If the employee was particularly close to workers at remote locations, perhaps offer to pay for travel for these other workers.

6. Stop worrying about "setting precedent" with regard to offering benefits or assistance to the family.  Just do the fucking right thing, okay?  Hint: if you use "setting precedent" as an excuse, more than likely you're being a douchebag and NOT doing the right thing.

7.  As the manager (or other point of contact for the family), keep in touch with the family over the next month or so.  At least once a week.  Ask how they are doing, what you can do to help them out.  

Realize that despite the awkwardness, the next of kin might need to immediately learn about financial matters (such as last paychecks, medical benefits, life insurance, pensions, stock, etc). Some people live paycheck to paycheck, and the stress of figuring out their future financial situation is one thing you CAN do for the family during a time like this.  The family also needs to figure out how to get the deceased's personal effects back  and how to return company property the deceased employee had at home.

8. Please, be decent and extend COBRA benefits to the widow(er) and dependent children for at least 18 months at no cost to the family.

9. Have someone set up a fund with the bank where people can make donations for the support of the deceased's children. Publicize it through the company, but don't strong arm people into donating.  And maybe make the donations anonymous so that the family doesn't have to write thankyou notes (another detail that they must attend to at a very hard time for them).

10.  Send flowers.  For employees who cannot make the funeral, allow them to write notes of condolence and deliver them to the family.

11. When packing up the employees stuff and returning it, please be sensitive and respect his/her privacy.

12.  Don't move another employee directly into the deceased employee's cube or office.  Leave it empty for a while. It might be a good place to store server equipment and such in the meantime.

 In her previous post, the Cranky Product Manager unloaded on Code Boys & Grils who don't fix their damn bugs.  She dropped the eff bomb and everything. Indeed!

This post is the flip side. The developer's point of view when faced with a nasty bug.  And it's an extremely well-written piece by a Code Boy who is  a reader of this humble and cantakerous blog.  

This post is required reading for product managers. And the Code Boys/Girls will probably like it too.

(Oh yeah, go visit Quantum Whisper.  The Cranky Kid loves them so much s/he stopped mid-tantrum and calmly whispered, "Mother, I can't be expected to do agile product management without 1) candy, 2) my teddy bear, and 2) Quantum Whisper. I can't and I won't.")

-------------------

The Five Stages of Debugging

by A. Working Coder

Being confronted with a serious and difficult-to-diagnose bug can be one of the most traumatic and stressful experiences of a professional programmer's career. Those who have been through such an ordeal rate the stress as on a par with that accompanying serious injury, divorce, or the death of a family member.

Researchers who have studied the psychology of computer programming have lately constructed a framework to understand the stages through which the programmer's mind progresses as she/he works through the difficult process of resolving a bug. These stages are similar in concept to the well-known Kübler-Ross Stages of Grief, and for similar reasons. Like death and its attendant grief, fixing a bug is a process initiated by an event, at first unbelievable, which causes great anguish in the affected mind. However, this event must eventually be grappled with, endured, and brought to a satisfactory conclusion. Understanding the stages of bug fixing will make us better prepared to survive, persevere, and eventually bring closure ... to our bug queues.

STAGE 1: RESISTANCE

How you're feeling: Skeptical. Offended. Petulant.

1. Ignore it.

Maybe it'll go away.

2. Mark it as "Works for Me".

Maybe it was user error, or a local configuration problem. Yes, I'm sure that's what it was. It'll just go away.

3. Call it a Glitch.

I think it was just a weird one-off that nobody will ever see again. There's no point in figuring out what went wrong. The {database/network/browser/something} hiccuped and that's all this was. It won't come back, I'm sure.

4. Hide.

I'm taking a couple of days' sick leave. Maybe they'll assign the bug to somebody else.

5. Mark it as "Working per Spec".

Hey, look, I just implemented what was spec'd. If they want to change the behavior, UI will have to update the spec. Maybe they'll decide they can live with it as-is.

6. Demand More Information.

I can't do a thing with this bug until and unless I see the error logs for this particular exception scenario.

7. Assign it to another team member.

I was getting badly-formatted data from that other module, that's the problem. Give it to the guy who maintains that module. I could check for that one weird corner case in my module, but the proper fix is for that other guy to make his code correct. He's offshore anyway, so I'll never have to face him.

STAGE 2: ACCEPTANCE

How you're feeling: Resigned. Defeated. Annoyed.

1. Accept it.

All right, all right, all right! It's my bug. I'll fix it.

2. Put it on the bottom of your queue.

Maybe I can find another job before I'll have to fix this bug.

3. Bargain with your manager.

OK, look: I could fix it the right way, and that will take a month. On the other hand, I could apply a band-aid to the problem, which won't really solve it, but it'll make it go away as far as the end-user is concerned. And that will take a couple of days.

4. Mark the bug with an outrageously padded estimate.

God, I hope that's enough time.

STAGE 3: ENGAGEMENT AND DEPRESSION

How you're feeling: Giddy. Light-headed. Nauseous.

1. Initial Research.

I can do this. I can do this! All it takes is a little organization, a little focus, a lot of caffeine, and a little time. I can do this.

2. Befuddlement.

Shit. This is unbelievable. I can't make heads or tails of this code. It's a mess. It's a mystery to me how this code could even compile, let alone work. What chance do I have to figure out how it can fail?

3. Hide Again.

Look. I'm sorry. I had to have my appendix removed. Again. Yes, now that you mention it, I did used to have two. Now I don't have any. Happy now?

4. Bitching.

Well, what did they expect, anyway? Trying to do this without so much as a decent debugger. What am I, clairvoyant? I had better debugging tools on my Commodore 64!

5. Spitballing.

What if I try ... this? Nah, that doesn't work. How about ... that? Nope. How about ... that? Shit, that makes things worse.

6. Despair.

I'll never fix this bug. I'm a lousy coder. I'm stupid. What am I doing here, in a place full of smart people? Sooner or later they're gonna catch on, and then I am finished around here.

7. Humiliation.

My manager asked me why I've taken the better part of a month to fix a bug I'd spec'd out as taking a couple of days' worth of work. I don't know how to read the logs and I broke my own build scripts. Now I'm afraid to ask for help because it'll just make me look stupider than I already do.

8. Panic!

This thing is way more complicated than I thought it would be! The parts I thought would be really hard turned out to be really easy ... and the parts I thought would be easy turned out to be a complete rewrite of about a half a dozen classes. Why did I ever tell my manager I could do this?

9. All-Nighter(s). Withdrawl from friends and family.

(incoherent mumbling, punctuated by bursts of loud profanity.)

STAGE 4. POSSIBLY FOOLISH EUPHORIA

How You're Feeling: Grateful. Relieved. Awfully Impressed with Yourself.

1. Revelation.

Oh! Now I see how to do this...

2. Write the correct code.

I am so good. I am a coding machine!

3. Test it.

Yes! It passes that test. Yes! It passed that test. Boo! It fails that test. And I have no idea why...

4. Hide the test failures.

It's a totally unrealistic corner case anyway. Nobody will ever see that in the field. It was really a pointless test.

5. Check it in.

I'm awesome. Is there pie in the kitchen?

6. Close the bug.

I heard there was pie in the kitchen.

STAGE 5. GRAPPLING WITH THE DEFINITION OF "DONE"

How You're Feeling: Twitchy. Nervous. Superstitious.

1. They've Reopened the bug.

Really? They found another way to break it? Shit - it's that corner case I swore would never come up.

2. Fix the fix.

Yes, I'm even checking cases where the employee age is an imaginary number, just to be sure.

3. Close the bug.

Yeah, bitch. You're closed. Once and for all. Now stay dead!

4. Vow to never take on such a task ever again.

5. Realization that you are now considered the expert on that module.

Oh no! Now I've got three new bugs on that module.

At this point, you are expected to GOTO: Stage 1.

Furthermore, as a working coder, you will DO_UNTIL: Death, retirement, or promotion into management.

The Cranky Product Manager has actually not been so cranky lately.  She's started a job at a spankin' brand new startup and for the first time in her professional life is part of a team - that for the moment, anyway - seems free of major dysfunction!  OMFG!  

She has a major crush on this company and loves (LOVES) going to work in the morning.

(oops, need to insert an ad for Quantum Whisper here, cuz they buy me grande skim lattes each month. Quantum Whisper is wicked pissa. They link customer feedback to your agile backlog and all that fun stuff.  OK, back to the post.)

But being a born-New Englander -- a cynic through-and-through, to the core of her jaded, oft-broken heart -- the Cranky Product Manager knows better.  She knows this is merely the honeymoon period.  At some point, an idiot will be hired. At some point, a customer will demand something ludicrous and a SalesDroid will get simultaneously hysterical and rabid as a result, causing the Cranky Product Manager no end of aggravation. At some point, the PR agency will start arbitrarily tossing the buzz word du jour in every sentence of every press release, even if the results are nonsensical and utterly laughable.

But in the meantime, before the other shoe drops (where did that shoe dropping phrase get started anyway?), the Cranky Product Manager is trying to enjoy her enviable situation. 

The only downside of all this has been that is has been hard to get the Crank up to write this blog. Thus the drought of blog content.

So, you should all thank SugarSync for irritating the Cranky Product Manager enough that she should post.  

Some background...SugarSync is a cloud backup service that the Cranky PM pays for. She uses it at home to keep her 3 computers backed up and in sync. Cool in concept, but not so cool in reality. A few months after subscribing, instead of just backing up her files, SugarSync decided to duplicate over 10,000 files - eating up all her hard disks and cloud storage. The Cranky PM then spent lots of time using 3rd party tools to remove the duplicates. The end result was a lot of lost time and at least a few lost files.  

Irritating, to be sure. But the Cranky Product Manager is nothing if not forgiving of buggy newish products. It's what SHE DOES, after all.  So, reassured by the SugarSync Support that this was a one-off situation related to their latest upgrade, the Cranky Product Manager carried on and continued to use their service.

And then a month later it happened again.  Argh! This time the Cranky Product Manager searched the SugarSync Forums for answers and found multiple threads related to this duplicate file issue.  The most enlightening was this: http://sugarsync.hivelive.com/posts/c6fb6fb9db 

This thread reminds the Cranky Product Manager about everything that is frustrating about dealing with a certain type of Code Boy:

1. Despite overwhelming evidence in its own forums that MANY customers experience this mass-duplication of files, the SugarSync CodeBoy(s?) (username "admin") insists that this problem is a "corner case" and never really happens.  

(We can tell that it is an actual code-slinging CodeBoy in the forum, because no self-respecting Customer Support Engineer would ever take this kind of attitude with a customer).

2. The SugarSync CodeBoy then pushes the burden of the bug onto the customer -- insisting that they open support tickets, collect and mail in logs, etc... 

3. The customer doesn't send the logs in because: 

(A) They are busy manually cleaning up the duplicate file mess and don't have time to also help debug SugarSync's software, and 

(B) From the tone of the previous messages it is OBVIOUS to the customer that SugarSync does not recognize this as a genuine problem, and realizes it will be an uphill battle to convince SugarSync otherwise.

4. The SugarSync CodeBoy declares victory:  "The customer won't cooperate with me in reproducing this bug!  I can't do anything!  So, this bug must not really exist! Plus, I AM RIGHT! HAH!"

........................

Excuse the Cranky Product Manager while she strangles a voodoo doll that she created of this CodeBoy....

...OK, feeling better now.

Gotta say, it's kinda rare to see this type of exchange played out in a public forum like this. Usually the Support people rightly prevent this type of unempathetic, obnoxious Code Boy from interacting with customers and others outside the company.

But within the company, who in Product Management has not encountered almost the exact same crap from a CodeBoy/Girl, at least once a release cycle?  It is ABSOLUTELY MADDENING!   

To have someone deny that a problem exists when MULTIPLE people have encountered it?  To be told that the problem you are clearly experiencing  is a "corner case" that doesn't ever really happen?  To be told its somehow your fault - some kind of user error situation?  To have the Code Boys & Girls demand that YOU do THEIR effing jobs by spending ungodly amounts of time reproducing their damn bugs and verifying their alleged "fixes"?!?  

AS IF product managers don't have ENOUGH to do near release-end (market launch, get pricing proposed and approved, write collateral, and sales training, not to mention being neck-deep in planning the next release....the list goes on and on.), but now they have to be QA engineers as well?  

All because some frigtard CodeBoy/Girl has no effing pride in his/her work??!!  How can s/he think it's okay to release what is obviously a steaming pile to customers?

WTF!!!!!!

---

BUT THEN, serendipitously, the Cranky Product Manager received a Truly Awesome article from a Code Boy who reads this blog.  It's about the process an Engineer goes through when faced with a thorny bug.  

And now the Cranky Product Manager understands just a little bit better.  She still wants to keep her voodoo doll collection of CodeBoys close at hand, but at least she'll feel a bit more empathetic when sticking it with pins.

Read the guest post from Code Boy Extraordinaire in the next article (coming in a few minutes). It's required reading for any product manager who has ever had a bug s/he reported marked as "not reproducible."

This post is sponsored by Quantum Whisper. The Cranky PM loves them because 1) they pay her, and 2) they are maestros of the agile product management tango.

---------------------

In their spare time, the Product Management Crankerati just LOVE writing haikus.

Check it: here (Pivotal PM), and here (previous Cranky PM post), and here (Product Management Meets Pop Culture), and here (Tyner Blain), and here (On Product Management), and here (Spatially Relevant).

The fun just never ends.

Anyway, here's some brand, spankin' new haiku from the Cranky PM.  From her sleep-deprived, addled brain. (Too many products to manage, too many kids to parent - at home and at work.)

As always, submit your own Product Management Haiku in the comments!

Feemium product
has too many great features.
No one upgrades. Crap.

CTO sees the
bright shiny object du jour.
Development stops.

Virtual dev teams.
Half of meetings are now spent
debugging A/V.

Agile dev process
moves bottleneck from Dev to
Product Management.

Product Manager
who cannot use his product
should be fired. Now.

The new Architect
always demands rewrite of
every line of code.

Hey, Support Martyr,
some enhancement requests won’t
get done ever! Chill!

Sales Droids always bitch.
Unless they can do no work,
but still collect checks.

The Agile stand-up
should be 10 minutes, not hours.
My feet really hurt.

Quantum Whisper was kind enough to supply the Cranky PM with expensive lattes this month.  They are a wicked awesome company that links customer feedback to your backlog.  Crank-tastic!

-----------

At LONG LAST, the World's Most Generic Product Management Interview wraps up.

The Cranky Product Manager will just say that creating these videos is a lot more tedious than you might expect. Especially since she is a lousy speller and the xtranormal thing lacks spell check. She is really sick of those monotone voices! So this will be the VERY LAST CARTOON for a while.

(And if you received this post via email or your RSS reader and cannot see the embedded video/cartoon, view it here.)
 

Check it, Part 6, THE FINAL CHAPTER!

And if you haven't seen the previous videos, find them here.

PARTS 1 &  2 - The interview dress code.  The first slew of generic questions.

PART 3 - Even more generic questions.  Round manholes, anyone?

PART 4 - Questions that require you be a much better PM than the hiring manager.

PART 5 - Do you have any questions for me?

PART 6 - The Final Chapter - What are the next steps?

( And don't forget to buy your colleagues holiday gifts.  How 'bout some Cranky PM mugs? )

This hideously cranky post is sponsored by Quantum Whisper, a wicked awesome company that links customer feedback to your backlog.  Can you say OMFG!

-----------

Ack, almost done.  At long last, our glum product management applicant gets to ask a question of his cranky interviewer.

(And if you received this post via email or your RSS reader and cannot see the embedded video/cartoon, view it here.)
 

Check it, Part 5:

And if you haven't seen the previous videos, find them here.

PARTS 1 &  2 - The interview dress code.  The first slew of generic questions.

PART 3 - Even more generic questions.  Round manholes, anyone?

PART 4 - Questions that require you be a much better PM than the hiring manager.

( And don't forget to buy your colleagues holiday gifts.  How 'bout some Cranky PM mugs? )