Category: The PM Profession

Some Laughs for Product Managers

You might not know this, but the Cranky Product Manager has special abilities.  Ones that go beyond her prowess with requirements documents, her ability to read customers’ minds, and the way she can get developers to actually do what she asks without offering bribes or sexual favors.

Deanna_Troi_Season_3_smCan’t guess what these abilities are?  Well, the Cranky Product Manager is an “empath” (sorta). Kind of like Deanna Troi. But without the skin-tight, low-cut lavender jumpsuits and penchant for stating the blindingly obvious.

As an empath, the Cranky Product Manager can sense how all of you — the Product Management Crankerati — are feeling at this very moment.

She’s sensing that you are feeling frustrated and that you have too much to do. That your days are filled with hundreds of emails, dozens of meetings, tons of documents and reading, customer visits, travel, presentations, strategic planning and and more and more and more. The onslaught  just won’t let up, and you are feeling just a little overwhelmed (although you won’t admit it).  As such, you’ve lost a bit of your sense of humor.

So, the Cranky Product Manager is here to help.  Maybe give you a smile or even a few chuckles.

First, re-live your daily conference call hell with the video “A Conference Call in Real Life“:

Second, the next time you have to deal with that caustic-yet-brilliant CTO, remember this Dilbert:

Third, check out the Cranky Product Manager’s Pinterest board, for EVEN MORE cartoons on product management, software, and Silicon Valley (mixed with a dash of working-mom humor).

And fourth, try to get a bit more sleep, rein in your inner control freak, and remember that you just LOVE product management! It’s WICKED AWESOME.

 

No Excuses Product Management (Part 4) – Do Yer Damn Product Strategy Already

LAME-ASS PRODUCT MANAGEMENT EXCUSE #3: “I’m too busy to work on product strategy.”

The one REALLY gets the Cranky PM’s scowl going, enough that she’s considering Botox simply to appear more slightly more pleasant and plastic and less sarcastic and cranky.  Too bad there are no injections to prevent eye rolling.

Grrr. Too busy to NOT work on product strategy, is more like it.

Sure, as a product manager you’re fighting fires and constantly bombarded with emails and phone calls and meetings and X and Y and … That’s life in the big city.

Whatev, we all deal with it. Rumor is that Product Management is a leading cause of Adult ADD.

The simple fact, though, is that if the Product Manager doesn’t do the product strategy, well, WHO THE HELL DOES?  Perhaps you are expecting a visit from the Product Strategy Fairy – expecting her to leave some market trend analysis under your pillow?

Ok, ok, if you’re at a release 1.0 startup, the Cranky Product Manager will give you a pass on this one, because often the founder knows the problem space.

Seriously, the job of Product Management is to make sure the team is scaling the right freakin’ mountain. You might be a demo genius, ..

NO EXCUSES!

 

Common Product Management Fuck-Ups That Strike Even the Experienced

Common Product Management Fuck-Ups That Strike Even the Experienced

  1. Acting like a Requirements Monkey.
  2. Punting on strategy.
  3. Not focusing on a particular target market.
  4. Not meeting with enough customers often enough.
  5. Not meeting with prospects and non-customers often enough.
  6. Not truly understanding the real problems faced by your target market.
  7. Hearing only what you want to hear.
  8. Being afraid to draw pictures.
  9. Writing a Magnum Opus of a requirements doc or strategy doc, primarily to cover your ass.
  10. Forgetting to incorporate features into your product that help you measure success or failure, and thereby improve over time.
  11. Going along with a development process that can't adjust when faced with negative market feedback
  12. Becoming Development's Co-Dependent, and having them come to you about the placement of every freakin' pixel.
  13. Allowing a piece of shit to ship.
  14. Making the product hard to buy or up-edition.
  15. Thinking that landing reference customers for a new product/release is someone else's job.
  16. Letting the release treadmill create a "boat anchor" editioning and pricing situation.
  17. Assuming that everyone that stands in your way is an asshole or a political player.
  18. Neglecting to spend the time building rapport and credibility with engineers.

What the Cranky Product Manager Hates About Aspiring “Product Guys”

Hey there, aspiring “product guy“!

First off, you’re a douchebag for your calling yourself a “product guy.”  

What IS a “product guy” anyway?  Do you mean “product manager” or “product marketer” or something?  Or is the GUY part the emphasis here?  What’s the equivalent female term anyway?  Product Gal?  Product Princess???

The Cranky Product Manager says *gag*.

Second off, you’re pretty frackin’ unqualified to do product work.  

After all, until last week, your only job experience was as a programmer. Or as a student. Yet you think you should be in charge of all of Product (the department).  Or at least of one product.

Sure thing. Go for it. Be the “product guy” you always wanted to be. Dictate features and future product direction from up high on your Product throne.  Wow the Silicon Valley startup scene with your spankin’ new title on mod business cards…

…Just as soon as you let the Cranky Product Manager become your Head of Engineering.  Or your Senior Technical Architect.

Oh wait. That’s probably not a good idea, is it?

Because the Cranky Product Manager is unqualified for those roles.  Even if she took a 3-day “certification course” in software development, she would not be qualified.  

In fact, the Cranky Product Manager is probably far more qualified to be your Head of Development than you are to be Head of Product.  (She at least has a degree in Computer Science, and actually worked as a programmer for a few years early in her career.)

Alas,  just WANTING to be a Product Guy/Gal/Princess/Manager/Marketer/Dweeb is not enough.  You actually need some education, skills, and above all, some EXPERIENCE. 

Professional Services Engineer or Surly Gifted-and-Talented Teenager?

Professional Services Engineers and Senior Customer Support Engineers, the Cranky Product Manager loves you.  She truly does.  

You get in there and make our products truly work– sing even! –for our most important customers, many of whom have really bizarre requests.  

You are ingenius, a MacGyver for the new century.  You can work around any product deficiency with a wad of gum, a Perl script, and a laptop stuffed with SSDs.

You keep the Cranky PM informed about what the customers are experiencing and the problems they face, and keep the Cranky Product Manager apprised of the experience of using her product day-to-day.  

You are great. And the Cranky Product Manager could not be prouder of you.  

Except for one thing:  your attitude.  You remind the Cranky Product Manager of a surly teenager.  A “gifted and talented” teen, to be sure, but an adolescent with all the part and parcel attitude problems.  

Witness the Cranky Product Manager’s awesome chart:

  Surly Gifted-and-Talented Teenager

Professional Services Engineer
/ Sr. Customer Support Engineer
 

General Attitude Embittered and feeling put-upon by parents’ rules. Embittered and feeling hampered by all the product’s warts and failings.
Opinion of self

Convinced she is brilliant and her parents are biggest idiots ever, and that everyone else’s parents are cooler.

Convinced that Dysfunctosoft Engineering are biggest idiots ever, because Engineering requires months to add the product feature when he hacked up an absolutely brilliant work-around within a few weeks. 

Ability to Understand Not Everyone is Like Him/Her If her best friend thinks something is cool, then she does too. Even if any reasonable person can clearly see otherwise. Believes that if his customer needs this feature, then surely everyone does.  Even if it has no alignment with future product direction, obfuscates the user interface, or would take effort away from more critical areas.
Understanding of Broader World Remarkably naive about life outside her home/school, but thinks she knows all from watching a lot of reality TV. Knows nothing about writing production-worthy code that will work for hundreds of customers, not just one: scaling, internationalization, integration, standards, platform support, testability, user experience, error handling, APIs, etc.  Thinks he already solved 90% of the problem when he really only solved 10%.
Political Savvy If Mom says no, asks Dad. If Dad says no, ask Mom.  If both say no, involves the grandparents or teachers.

If Engineering says “no” to including the hacked-up workaround in official code-base, lobbies Product Management, Sales, and the CEO/GM.

Unreliable 

To gain a privilege, promises to do an unpleasant task like cleaning out the garage.

Then does not do it.  Parents nag her for weeks before finally giving up.

Under political pressure, Engineering caves and agrees to add the hack to the official product code base, but ONLY if the PS engineer makes the code thread-safe, uses standard libraries, etc.

Naturally, this never happens.  Count on the PS Engineer to get very busy on a customer crisis instead.

Why Sales Bitches About Product Management & What to Do About It

You’ve heard that old chestnut. You’ve seen it in a million articles. The big advice Sales Droids offer to Product Management 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 Product Manager give, and from her years of observing Sales Engineers and Sales Droids interact with the customers.

And here’s what the Cranky Product Manager came up with.

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

There are times when the Sales Droid-Product Manager-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 satisfied 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 Sales Engineer/Account Rep thinks the Product Manager 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″ Product Manager-ish statement and the “Warp Drive increases your revenues AND decreases your costs” Sales-ish statement.

Using this example, the Product Manager 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 bajillionth of the time it currently does”. And the Product Manager often leaves it there, believing she successfully tied feature to customer benefit.

Meanwhile, the Droids think the Product Manager 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 Product Managers, 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 Product Managers 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 Sales Droid 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 Sales Droid will be happy, only the customer.  After all, the Sales Droid 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 Product Managers 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.

What Do Five-Year Olds and Product Managers Have In Common?

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.

Guest Post from a CodeBoy: The Five Stages of Debugging

 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.