web counter

Posts tagged as:

product management

Quick Clarification and How to Convince Your Boss to Get You Training

by The Cranky Product Manager on June 3, 2010

in The PM Profession,Your Career

Just wanted to clarify the Cranky Product Manager's previous post on training.

The Cranky Product Manager is NOT against training for product managers.  Not at all.

In fact, she HEARTS training, and any effort product professionals make to improve their skills and knowledge.  There are some really great classes out there! (see note 1)

It's the PASSIVE nature of the 'sit-back-and-train-me' attitude that drives the Cranky Product Manager bonkers.  Especially when used as an excuse for not getting the job done.  

The Cranky Product Manager says this as someone who has supervised a fair number of product managers: if you want to use 'lack of training' as an excuse, your performance review had better NOT be the first time your boss hears about your training needs.  

Instead, you should have been making the business case for training as soon as you concluded your skill gaps were getting in the way.

Now, here's the Cranky Product Manager's recipe for "Convincing your boss to give you training."  It works.  Really.  Well a lot of the time (probably not in early-stage startups).

1. Make a 30 minute appointment with your boss.  

2. Go into this 30 minute appointment with a half-page, bulleted printed handout that he/she can review.  This handout should make the case for getting you trained and give your boss several options to consider.

3. If you're stuck, structure your doc according to a classic "Situation, Complication, Recommendation" outline.

Situation:

  • The specific skills you already have
  • Where you would like to be, and why your boss should agree that this is a good goal for you. (maybe refer to a previous performance review)

Complication:

  • The gap between your current skills and where you want to be
  • If you were to remedy this gap, how would the company benefit? What's in it for your boss?  In which release would your boss's life improve, due to your improved skills?  

Recommendations:

  • List a few different options for closing the skill gap (bosses love to pick from different options).  For each, list the pros/cons, the cost, and the time frame. 
  • The Cranky PM recommends that you suggest at least one option that involves no budget but instead involves time.
    • For example, your boss could tutor you in this specific skill and meet with you once or twice a week.  In proposing this option, you should be very specific about how often you'd want to meet and what you would need from the boss (without seeming too needy).  Example: (provide face-to-face feedback on the latest version of my product strategy document once a week, help me brainstorm how to segment the market, give me a lollipop and a "you're a SUPERSTAR" sticker at the end, etc).
    • Note that the bigger the time commitment needed for your "free" option, the more likely your boss is to pick another option.  
  • Make sure you highlight which option YOU recommend and why. 
  • Acknowledge that there are several constraints at play: budget, release schedules, who will pick up the slack while you sit in training, etc. Explain how you will minimize these impacts.

4. Go over the handout in the meeting.  Get your boss nodding "yes" as you mention each point.  Hopefully that yes-nodding will get her/his neck limbered up, and s/he will also agree to one of your training options.

5. If your boss immediately picks an option, great. Go back to your desk, write an email to the boss saying something "Thanks for meeting with me today. We agreed that I should sign up for training class X."  Then go sign up. Hurry. (But pray there is a decent cancellation policy if your boss is one of those people who changes his/her mind every 3 minutes).

If your boss wants more time to think about it, do NOT leave the meeting without nailing down a time frame for a decision.  Immediately set a meeting for follow-up.

6. Remember, NO WHINING!  No "you owe me." Keep focused on the benefits of your training to YOUR BOSS and the company.  

7. If the boss says "no," be mature about it. Try to understand why. Then go educate yourself as directed in the previous post, using all the resources of the online PM community.  And then, in a few months, try again.

Now, you might worry that all this would be pestering and annoying to your boss. That's a valid worry.  But more likely is that your boss would be 20% annoyed (because now s/he has to make a decision and maybe spend some money) and 80% patting him/herself on the back for hiring such a high-potential, results-focused product manager. Because the way you approach the training issue shows how you would also approach the rest of your job.

Note 1: The Cranky Product has partaken of many training opportunities (a self-funded MBA, Product Camps, UC Extension, Pragmatic Marketing), but her employers never paid. Apparently, she did not master the above-described technique until too late in her career, when she became the boss and found herself on the receiving end.

{ 22 comments }

Is There Anything as Predictable as a Sales Droid?

by The Cranky Product Manager on May 19, 2009

in Sales

For years, the Cranky Product Manager has been dealing with all those whiny Sales Droids. 

You know, those people who moan all the time about how Sales is The. Hardest. Job. Ever., as they yap on their bluetooths while driving around in their Porche 911s?   You know, those dudes/dudettes who always win deals because of their mad persistence, unequaled interpersonal aptitude, and their wicked awesome sales skills? Yet when they lose it’s always the fault of the product or the price?  

Yep.  Those Droids.  You know who the CPM is talkin’ about.

Anyway, the Droids have been bitching for YEARS to the Cranky Product Manager about the price of her product.  “It’s way too expensive.”,  “I can’t sell it at that price,”  “The competition is priced so much lower we can’t compete,” “We need to drop the price by at least 20%,”  blah, blah, blah. 

All that time the Cranky Product Manager resisted dropping the price.  Yes, her product was priced higher than the competition, but it offered way more value.  Plus, being a wicked big geek, the Cranky PM created this elaborate pricing model spreadsheet based on shitloads of historical pricing and sales data .  It showed price was relatively inelastic. 

Well, fast forward to 2009.  The economy is in the shit and the Droids all miss their numbers by a mile.  Their screaming about the “too high” price reaches 120 decibels.  Loud enough that it catches the attention of The Man, AKA The Quasi-Playboy, AKA The Dirty Semi-Old (50-65 years old) Man Who is Always Scanning the Marketing Events Planning Staff for New Blond Mistresses.  AKA  The CEO.

So, the CEO calls the Cranky Product Manager into his office.  After complimenting her hair and the way her jeans fit, asking her if she is still happily married, and trying to give her a George-W-style shoulder rub,  The Big Boss tells her to drop the price to the one the Droids are begging for. 

The Cranky Product Manager sez, “No Effing Way,  Mr. CEO (and I mean that in the most respectful way).  Behold my awesome spreadsheet!  Dropping the price will NOT lead to more units sold and will make the product unprofitable.”

“You look hot when you’re angry,” sez the CEO, “But we’re still dropping the price.  I want you to create a new forecast based on the new price.  Not your lovely theoretical spreadsheet.  Instead, do it bottoms-up and go ask each sales rep how much he’ll sell at the new price.  Oh, and let me know when you tire of that husband of yours.”

And so the Cranky PM announces the price cut to the field. She then asks each rep, one at  a time, how much product he/she was committing to sell based on the new price.

And SHOCK OF ALL SHOCKS, the Droids sandbag it.  Apparently, even with a 25% price cut they can only sell about 3% more units than the numbers they had signed up for just 3 weeks earlier. 

Guess price wasn’t the issue after all.  WHO COULD HAVE GUESSED THAT WOULD HAPPEN?   Oh wait, I know this one…. Yep.  The CRANKY PRODUCT MANAGER guessed it!

AS EXPECTED, the New and Improved bitching and moaning from the Droids began immediately .  “The price is too low”,  “You just made it 25% harder to make my number!“, “With a price like that, people will think we offer less capability than the competition”, blah, blah, blah, blah, blah.  Will. It. Never. End.

Even the 2-year-old CrankyKid changes his mind less often.  And even the CrankyDog can remember past events  better than Sales Droids. 

There are two things you can always count on at DysfunctoSoft: 1) The Droids will never like the price, and 2) The CEO will always skeeve you out.

{ 20 comments }

10 Things That Piss Off the Cranky Product Manager

by The Cranky Product Manager on January 12, 2009

in The PM Profession

Here are 10 things that make the Cranky Product Manager so frakin’ ANNOYED that she’s getting one of those bite plate things. You know, to keep her from grinding her teeth into small nubs while she sleeps. No doubt, the mouth plate will drive her husband WILD.

Here they are, listed in no particular order (and these are by no means the “top 10 of all time,” but are just for today):

  1. Endless arguments about the worth of product planning via a top-down process versus a bottom-up process.
  2. EVERYONE claiming they are strategic. Will NO ONE ever acknowledge that their job or abilities are primarily tactical?
  3. Insincere CEOs who ask the Cranky Product Manager about her Cranky Kid, but cut her off four words into her answer.
  4. Developers who think the Cranky Product Manager is some kind of user interface expert.
  5. Developers who ask for the ROI of each and every aspect of a feature. Example: What’s the ROI of the user being able to save his work?  Honestly, how are you supposed to do this? And is it even worth it?
  6. Engineering managers who think that delivering  50% of a feature should result in 50% of the revenue. Usually, a half-baked feature is worse than no feature at all!
  7. CEOs who move entire release schedules by 6 months or more during quarterly earnings announcements.
  8. Product Marketing weenies who are too “visionary” and “big picture” to bother trying to use the product – even though it is targeted at business users (not tech people).
  9. Customers who demand you support operating systems and platforms so old that you can’t obtain them anymore.
  10. Maintaining the frakin’ Supported Platforms List.  ARGH.  Is anything more thankless or tedious?

{ 25 comments }

Divine Rules for Product Managers #2: On Dealing With Unreasonable Customer Demands

by The Cranky Product Manager on December 31, 2008

in Customers,Divine Rules for Product Managers

View all the Divine Rules of Product Management here.

Law #2: On dealing with customers who can’t understand you don’t develop custom software just for them.

If a customer presents a detailed list of features, demands they be developed immediately, and then tries to extract firm commitments with specific dates for each feature, the Product Manager shall adroitly step around the trap as follows.

The Product Manager shall assure the customer s/he understands the  issues by paraphrasing them back and sympathizing with the customer’s frustrations. 

The Product Manager shall, in front of the customer, write the details of each issue, for posterity, inside a high-class notebook with gold gilded page edges.

The Product Manager shall frequently say phrases like:

  • I can see why that’s important to you
  • We’ll see what we can do
  • I wish we had the resources to work on all these great ideas… which two are most important to you?

The Product Manager shall not definitively promise a feature will be developed nor its delivery date, unless the feature is already done, tested, and due for release within the next 2 weeks.

The Product Manager shall also take copious notes of the entire conversation and circulate these notes to the Product Manager’s boss and the customer’s account team, highlighting that NO PROMISES were made.

If thou does this according to THE SOFTWARE LORD’s wishes, the customer will calm down and perhaps take a less adversarial approach in the future. Even better, the Product Manager won’t get fired in 6 months for allegedly promising the customer something that can’t be delivered.

—————-

Have the Software Gods been speaking to you as well?  Have any additional Divine Rules for Product Managers you wish to share?  Share them in this post comments.  The Cranky Product Manager will feature the best Divine Rules as posts on this blog, with appropriate link-backs to the destination of your choosing….

Also in Divine Rules of Product Management

  1. Divine Rules for Product Managers #1: Prepping for Engineering Meetings
  2. Divine Rules for Product Managers #2: On Dealing With Unreasonable Customer Demands
  3. Divine Rules for Product Managers #3: On Helping the Press with Product Reviews
<< Previous in series | | Next in series >>

{ 11 comments }

Divine Rules for Product Managers #1: Prepping for Engineering Meetings

by The Cranky Product Manager on December 29, 2008

in Development,Divine Rules for Product Managers

The Cranky Product Manager had a religious experience recently, where the gods of enterprise software came to her in a vision and presented her with the Laws of Product Management. Being gods, they instructed her to share these sacred Laws with y’all. 

The Cranky Product Manager shall post each Law in a separate post. Eventually, when several Laws are posted, you can view them all together via the Divine Rules for Product Managers category.

Law #1: On preparing for potentially contentious meetings with Engineering

If thou plans to meet with the Engineering team, where thou suspects the Engineers will disagree with the recommended priorities for product development, then thou shall endeavor to informally meet with each member of the team individually beforehand. 

Over burritos or sushi, thou shall endeavor to convince each Engineer of your point of view, describing the use cases and the research thou has done to arrive at the recommendations.  Thou shalt be charming and nice and personable and actually listen for a change.

If the time allotted for lunch is too short to convince the Engineer, thou shall continue the conversation over beers after work.  An official “meeting” is to be avoided.

Again, it is emphasized that thou shalt meet with everyone on the team individually, from the mightiest architect to the meekest junior engineer.

If thou does this according to THE SOFTWARE LORD’S wishes, the big meeting with the Engineering team will go smoothly and everyone will leave with common agreement as to the features and priorities of the next release.

Also in Divine Rules of Product Management

  1. Divine Rules for Product Managers #1: Prepping for Engineering Meetings
  2. Divine Rules for Product Managers #2: On Dealing With Unreasonable Customer Demands
  3. Divine Rules for Product Managers #3: On Helping the Press with Product Reviews
| Next in series >>

{ 15 comments }

The 5 Types of Beta Testing Programs and Why 4 of Them Suck

by The Cranky Product Manager on December 18, 2008

in Beta Testing

Let the Cranky Product Manager remind you all of the purpose of  Beta testing programs:  To get customers to actually use your about-to-be-released software.  Why? To find and fix problems that would not have been found by internal-only testing.

So WHY then, WHY(!?) do so many so-called Beta testing programs seem explicitly designed to PREVENT this type of feedback?

Let the Cranky Product Manager classify and explain the different types of Beta programs, of which the vast majority  do NOTHING to improve product quality or identify customer issues.

1. The “Don’t You Dare Complain Because This is Free” Beta

This type of Beta is otherwise known as the “Google Beta”.  An Example? Take Google Gmail, which put out its Beta release on April 1, 2004.  As of this writing in December 2008, 4.5 years later, Gmail is still officially in Beta, with no word for an official release. Ever. 
Clearly, the purpose of this type of Beta is NOT to collect customer feedback.  More likely, the “Beta” designation is a euphemism for “No Support. Take It Or Leave It. Don’t Complain To Us If It Doesn’t Work Because It’s Free.”
If there is no mechanism in place to actively contact Beta customers and solicit their feedback (as opposed to just relying on them to send messages to a forum or send YOU an email), and if there is no path to ever release this product, well it’s a “Don’t Complain Because It’s Free” Beta.

2. The Paper Beta

This is where a company has a ridiculously short Beta period, and as a result recruits very few (if any) test customers and thus gets very little feedback.  The whole goal here is to NOT uncover issues.  Instead it is to push a piece of crap out of the door on a certain date, regardless of (lack of) quality, while still being able to honestly look customers in the eye and tell them your product was Beta tested.  Because, yes, savvy customers ask that. 

(Even savvier customers ask how big the Beta program is, how many customers participated, how long it lasted, and how many issues were uncovered and subsequently fixed.)

Result?  There is no real effort to sincerely, honestly collect feedback.  And any feedback uncovered will probably be ignored – because “it’s too late to fix it now.” Bugs will be filed, and possibly, MAYBE, they’ll be addressed in the next production release.

If your Beta uncovers less than 10 issues or is less than 4 weeks long, congratulations, you had a Paper Beta.

WARNING: Running a Paper Beta will DOOM your efforts to recruit customers for any future Beta program – Paper or not. The few customers that do participate be incensed that they spent time installing, testing, and providing feedback on your software, only to have their issues summarily ignored and potentially never fixed.

3. The “Agile” Beta

Allergic to any form of process, some Agile proponents will claim their awesome methodology eliminates the need for expensive Beta programs.  Why? Because, supposedly, with Agile the product is “Beta every day,” or at least it is at the end of each sprint or iteration.  And part and parcel of the Agile philosophy is getting direct customer feedback throughout the entire development process. Ergo, the claim that no Beta Program is needed.

All this is fine and good, but it still does not obviate the need for a Beta program.  Because without getting actual product into the hands of actual customers, you won’t uncover the problems that can’t be uncovered in internal-only testing.  It is ESSENTIAL that the customer actually attempt to use the software ON THEIR OWN, for things THEY actually want to do. If they don’t and you just provide a demo or screenshots (as is often the case for Agile-style “in process” customer feedback), well TOO BAD it doesn’t count.

How did you get into this sad situation?  Most likely, it’s because you’re letting the Development organization push you around.  Because, after all, if the Beta program is eliminated, their jobs become easier and less work. Plus, they can now push their risky bug fixes to the very last minute – as in minutes before that “final build.”  This is extremely dangerous yet happens all too often. 

4. The Haphazard Beta

The Haphazard Beta is one where you get the product to a particular state, claim it’s Beta, and THEN try to figure out (last minute!) how to actually recruit some customers and get some usable feedback.   There’s no organization, and no directed attempt to collect and quantify feedback. 

It’s a mess. A big loosey-goosey, panicky mess. 

And it’s your fault, Product Manager. Your fault.

If you had been on the ball and actually done some recruiting ahead of time, along with a smidge of planning about how to collect and handle issues, well you might have actually had a REAL Beta. Alas, it’s too late to fix it all now. So hold on tight, pray you don’t lose your job, and promise to do better next time.

5. The Real Beta

This is the Beta program done right.  Real customers and prospects actually use the software and identify issues (at the bug level, workflow level, and higher levels) that you could not have found on your own. 

And THEN… here’s the kicker…. you actually DO something about the issues they find.  That is, YOU ACTUALLY MAKE CHANGES.  You fix the bugs.  You fix the work flows… You learn how to make your product better. 

And it all goes smoothly.

You have recruited enough customers – in both number and variety - to accurately represent your target market.  You have enough time to fix their issues.  You care enough about putting out a quality product that the final product is something that you can be proud of – something that won’t create a PR disaster requiring a zillion-dollar advertising Band-aid, like the well-known disaster below…

{ 22 comments }

The Cranky Product Manager never fails to disappoint, plus a blog you should read

by The Cranky Product Manager on December 4, 2008

in Reviews & Plugs

What a jackass the Cranky Product Manager is.  Before she knew that he would “violently” disagree with her (shame on him!), the Cranky Product manager promised Saeed of the excellent  On Product Management blog that she would post about his blog’s nomination for an uber-prestigious Canadian Blog Award in the category Best Professional/Career Blog.  But alas, the Cranky Product Manager did not act right away. She waited, thinking Thursday would be a good day for said post.

And so Thursday, today, arrives, and just as the CPM was revving up and writing a glorious call-to-action to help the On Product Management crew reap their just rewards, she discovers that “voting round 1″ is now over, and alas Saeed/Alan/Ethan did not advance to round 2.

F$&*.  The Cranky Product Manager feels partially responsible for this utter travesty of justice.  If only she got off her lazy ass and wrote a post earlier. Maybe it would have helped. What a turd she is.

Alas, the Cranky Product Manager flaked and broke her word. There’s no decent way to make up for this, but the CPM is going to try.  Here goes….

If you haven’t checked out On Product Management do so now. Below are some of the Cranky Product Manager’s favorite posts, most of which give their unique take on the reality of Agile product development. Unlike most others writing on Agile, these guys don’t just drone on with the Agile party line. Instead they make though-provoking observations and arguments that you have not read anywhere else. Examples:

  • Annoyed by newly Agile-ized developers who act like they invented the concept of getting customer feedback?  Check out Is Product Management Agile?
  • Why Agile/Scrum is not a panacea, and commentary on the ironic inflexibility of some agile proponents: Agile/Scrum Reality Check.  (Was going to say “rigidity” instead of “inflexibility”, but kept snickering like Butt-head.)
  • Agile/Scrum and Product Management – Parts 1, 2, 3, 3a, and 4. (whew! lots of reading, but worth it).
  • Also, check out the hilarious Uninterruptible Power Supply Saga (don’t forget to read the comments): part 1, part 2, part 3, and part 4.

{ 3 comments }

Why it doesn’t matter where Product Management lives in the organization

by The Cranky Product Manager on December 2, 2008

in The PM Profession

The Cranky Product Manager has read, and listened, and pondered, and debated, and bit her tongue over the years, as others have debated the proper place in the organization for the Product Management function.  Should it be in Engineering? Or in Marketing? Or in its own Products organization that reports directly to the CEO?

Not surprisingly, the answer depends on who you ask.

If you ask the CodeBoyz and CodeGrrlz, they generally think PM should be in Engineering. Because then the PMs could be forced to hang out in the Agile Tomb all day with the engineers. And because some CodeBoyz and CodeGrrlz think the PM should even pitch in and write some code now and then (a generally bad idea – see footnote 1).

If you ask the Marketing Weenies, well, naturally they want Product Management to be part of Marketing. Because then the Product Managers would somehow be more focused on customers and THE MARKET. Because, supposedly, you can’t focus on THE MARKET unless the letters M, A, R, K, E, and T are in your group’s name, in that order.

And if you ask many of illustrious luminaries and pundits that consult and train on the fine art of Product Management… well, they will all tell you that Product Management is such a strategic function that it should report directly to the CEO. Screw Engineering and Marketing!  We need a pipeline to the Big Cheese! And this is all fine and good, especially if you are the VP or Director of PM and want the ego boost of saying you report directly to the CEO. You could then give both the VP of Engineering and the VP of Marketing the finger if you so desire!

Anyway, for a long time the Cranky Product Manager has read these various arguments churning about in the blogo-sphere-iverse, and something about them — no matter what their theory or conclusion — pissed her off.  Just a little. And she couldn’t quite figure out why.

Until now. It’s the assumptions underlying this debate that irritate her.

The assumption is that if we sit in Engineering we’ll be too spineless and too tunnel-visioned to focus on the customer, market problems, issues for the field, the competition, or market positioning.  But if we sit in Marketing that we’ll be so focused on empty soundbites and website color schemes that we won’t be able to give Development detailed enough requirements, that we’ll conjure up product features that can’t possibly be built (a la Warp Drive), and that we’ll stare vacantly into space instead of considering technical extension points (i.e. APIs) for our products.

What a bunch of crap.

On the one hand, all these proselytizing and theorizing folk say that Product Managers need to be these gifted cross-functional leaders and act as CEOs of their products, but then on the other hand they don’t trust these Product Managers to do so, based on nothing more than where the Product Management function sits within the organization.

For the Cranky Product Manager, and for every decent product manager she has ever asked, EVERY SINGLE decision made as a product manager comes down to the following two questions:

1. Is this the right thing for my product?

2. Is this the best thing, out of all the possible “right” things, for my product?

GOOD product managers are obsessed with doing the RIGHT thing for their products – their bosses opinions be damned, and their bosses’ bosses opinions too.  They will fight tooth and nail to make the right things happen, to prioritize the activities that will move the needle the most (i.e. make the most money).  Whatever needs to be done to make the product a success.

This holistic, obsessive, determined, and pig-headed attitude is WHY good product managers are respected throughout their organizations.  It’s why people from different functions listen to them. It’s why they have credibility. It’s why they get stuff done. And, it’s why they are often “challenging” to manage, especially if your agenda includes items other than product success.

If good PMs were able to be easily pushed around by their VP’s latest political maneuverings, well they were probably not good PMs anyway. If this seems to be your challenge, well maybe you need to reconsider how you are evaluating your PMs – are you sure it’s based on their RESULTS and not their docility?

Anyway, possession of this do-it-right-and-do-it-best attitude has very little to do with WHERE the product manager sits in the organization.  It has everything to do with the personality, passion, and focus on results that each product manager brings to the job.

So instead of pondering this infernal, and pointless, organizational design question, perhaps we should focus on hiring the RIGHT types of people of Product Management jobs.

Read what others have said about this topic:

Footnotes:

1. Having product managers code is a dumb, dumb idea – trust the Cranky Product Manager. She’s a
fantabulous product manager but at this point has forgotten more about writing code than she ever learned. Like playing a musical instrument, coding is something you need to do on a regular basis to be anything but a crappy programmer.  Plus, it take the efforts of two mediocre programmers to undo the damage done by one crappy programmer. If a good PM has time to code often enough to not be completely crappy, he/she should probably instead spend that time looking for new market problems or doing competitive analysis.

{ 23 comments }

Gift Ideas for Product Managers

December 1, 2008

Today is “Cyber Monday” and no doubt you are wondering what type of elaborate Christmas present you should buy your favorite product manager. Keeping in mind, of course, that you better give a WICKED AWESOME present, given that product managers never get awards and hardly ever get thanks. You need to make up for years [...]

Read the full article →

Badness All Around

November 18, 2008

Badness abounds.  Like many (most?) software companies, DysfunctoSoft is goin’ through some hard times. Q3 sales sucked and then that whole October-through-now financial meltdown thing happened. So the axe fell. And as it often does, the head-cutting machete hit Product Management extraordinarily and disproportionately hard. (Out of respect for fallen comrades, the Cranky Product Manager [...]

Read the full article →

← Previous Entries