web counter

Posts tagged as:

featured

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.

{ 25 comments }

On Customer Advisory Groups

by The Cranky Product Manager on September 30, 2008

in Customers

Two questions from readers triggered this miraculous post:

“What is your opinion of the effectiveness of Client Advisory Groups, and do you think that PMs (cranky or not) should organize and facilitate them?”

“Follow up to the Client Advisory Groups, assuming you have an existing CAG how do extract useful feedback and integrate it with the development process? A ‘rate this feature’ tool? Something all together better?”

So, let the Cranky Product Manager go on record. She LOVES Client/Customer Advisory Groups, provided they are done right. Customer Advisory Groups can get you WICKED AWESOME unvarnished information about:

  • The actual BUSINESS problems that your customers are facing now and in the future
  • How customers view your products’ approach to those problems
  • The market and technology trends your customers sees and what their effects might be
  • How the market views you versus your competitors

Further, if the CAG goes well, you have an unparalleled opportunity to build real relationships with actual customer decision makers. Play your cards right and make friends (or lovers, if you’re a slutty guy), and you’ll leave with relationships with a handful of customers you can call directly — to get impromptu reaction to your product strategy, product feedback, and even competitive information.

Developing these direct customer relationships is ESSENTIAL for a product manager. Because you need to find out what REALLY turns your customers on. Without your own direct relationships, you have to rely on Sales Droids to setup and supervise all your customer conversations. And that’s like having your dorky Dad chaperon you on your hot dates — no fun, kind of embarrassing, and no one gets what they really want out of the interaction.

Alas, Customer Advisory Groups are often done wrong. They turn into multi-hour bitch-n’-moan sessions where each customer lists all the low-level enhancements (and bugs even) that they already filed with Tech Support. None of the above questions are answered, and none of the right relationships develop — wasting the time of all involved.

So, how do you do a Client Advisory Group RIGHT?

There’s a lot of magic, but the biggest thing is getting the RIGHT people there.

Who are the RIGHT people? Usually a higher level person than a PM might normally get to talk to, and definitely higher up than those Tech Support talks to. The RIGHT people are those who OWN the business problems your product solves; they write the big checks and are responsible for actual business results.

So, for example, assume your customer runs all their call centers using your product. Well, get the customer’s Sr. VP of Customer Service to attend, plus maybe the main tech influencer — often the CIO or CTO.

Who are the WRONG people? The software engineers who don’t like the wording of particular error messages. The system administrators who are primarily concerned with automating things they can do perfectly well via the interface. The content developers. The customer’s QA guy. (See footnote 1).

Um, Problem. I can’t get any of the RIGHT people to attend.

Yes, it is VERY difficult to get the real decision makers to attend your little Customer Advisory Group. They are very busy people and very important to their companies. Even if one agrees to attend, the chance of him/her bailing out at the last minute is > 50%. These folks will be VERY tempted to delegate this to the more technical, lower-level members of their team — the WRONG people. And then all is lost.

So you gotta make attending your Customer Advisory Group a SWEET deal. You gotta make these high level folks want to attend desperately, enough that they’ll actually keep their schedule free.

So repeat after me:

Location is everything: If your typical sale has a multi-million dollar price tag, your decision makers are C-level business-side execs. Better go for Pebble Beach and secure tee times for attendees. If it’s an IT-only sale with typical deals being in the mid-to-high six figures, think a high-end resort in Napa Valley, or something similar for your locale. If your product goes for a few thousand bucks, well the local Marriott will probably do. You get the idea. Whatever you do, don’t cheap out and make them buy their own food/drinks or eat rubber chicken on a stick.

Purchasers of enterprise software LOVE Pebble Beach. Trust the Cranky Product Manager on this.

Purchasers of enterprise software LOVE Pebble Beach. Trust the Cranky Product Manager on this.

Provide a “looks good” excuse to attend: Your target attendee will catch flak for going on a vendor-sponsored boondoggle to Pebble Beach unless you provide a way to justify attending to his/her boss and shareholders. Best Bet: Have a topical presentation by a well-known, “impartial” outsider. Preferably a charismatic author of a best-selling business book that somehow relates to the problems your software solves. Second choice is an “honest broker” presentation by one of those Gardener or Forrest Ranger ho-bags (hahahahaha! The CPM can’t control her laughter about that one, “honest!” hahahaha), or maybe a former exec at a well-known, admired company. Last choice: a professor. Please , let her at least have tenure. Also, you might want to have the outsider stick around to moderate some of the discussion.

Oh yeah, if your company has a rock star CEO/Guru (i.e. Ellison, Andreesen, …) try to at least get a meet-and-greet.

Other advice

Agenda: Two days with plenty of breaks, a cocktail hour and an awesome dinner. Include the following sessions:

  1. The thought-provoking presentation by the outsider (see above), preferably related to the problems your product solves
  2. A moderated discussion on the general business trends and strategic issues customers see and what it means to them
  3. A product discussion that links the trends/problems to potential product directions.
  4. Plenty of time to facilitate networking among the attendees. Help them break the ice and get to know each other.

Who Attends: 4-5 of your company execs and product management leaders. Have key Engineering directors/VPs and junior PMs attend relevant parts, but they must sit quietly in the back of the room. (NO banging away on laptops).

Salespeople stay away or shut the hell up.

What Product Managers Should Do: Milk this session for all its worth. PREPARE. Big Time. During breaks, socialize with the attendees as often as possible without annoying them. Which is hard if you have a crabby personality like the Cranky Product Manager.

More Specifics on the Product Session

Product Management should design and facilitate the Product Session. And NO, the Cranky PM isn’t going to tell you exactly how to structure the Product session. Deal with it. Your approach should vary anyway, depending on the burning questions you have. The key is to get the customers ENGAGED and learning from each other — Interactivity, BABY! That’s what makes them happy and will get them to come back next year.

OK, a hint. DON’T DO THIS: Each customer gets up, gives a presentation about how they use the product and the enhancements they want to see. This will bore the bahjeezus out of everyone, the RIGHT people will decide then and there not to come next year, and — trust the Cranky Product Manager — Tech Support already has this entire list anyway.

OK, Yet Another Hint. The Cranky Product Manager has had lots of success with workshop-style exercises that involve walking around the room and pasting sticky notes to flip charts — an artifact from her days as a management consultant at one of those big-dealio strategy consulting firms. Read Luke Hohmann’s book, Innovation Games: Creating Breakthrough Products Through Collaborative Play to get some ideas.

(Just remember to send Hohmann royalties for any “games” you use. Haha, just kidding, Luke. OK, not really. Seriously, Luke, the CPM is impressed you that you trademarked these “games”, since most are de reigueur for any product-oriented workshop the Cranky Product Manager has led or attended in the past 15 years. So, well done. The Cranky Product Manager is totally jealous. And though she is sniping at you because she is exceedingly immature, the Cranky PM is genuinely thankful that you collected these workshop exercises in a single 150-page primer. Now she can toss the book to junior PMs instead of having them learn purely by doing — a big help.)

Who Organizes the CAG?

Get an admin assistant or Marketing’s event planning people to handle the logistics. PM should recruit the attendees with the help of Sales — if you leave the invitation list up to another function, more than likely you will end up with the WRONG people in attendance. Also, PM should set the agenda, provide guidance to the outside speaker/moderator, and design the above-described product session.

But WAIT there’s more.

There’s a lot more to say on how to get the most out of Customer Advisory Councils. Lots. The CPM could go on and on, but alas she’s getting Carpal Tunnel. So, here’s a few other links you might find interesting. Note that they don’t agree with the CPM on every point (idiots!), but are still worth reading.

———–

1. These people have valuable feedback, but there should be another venue for that: USER GROUPS and your usual customer meetings and conference calls.

{ 9 comments }

Heresy Against the Church of Agile Software Development

by The Cranky Product Manager on September 23, 2008

in Agile/Scrum

The Cranky Product Manager is a big fan of anything that will get quality, innovative, market-killing products out the door more quickly.

Sincerely. This statement is a paragon of truthiness. Hell, the Cranky Product Manager would even trade in her extensive work wardrobe of Lucky Brand jeans for a pile of poofy skirts if it would improve product quality. She would even stop swearing and referring to her colleagues as “beeyotches” if it would speed up development and reduce the number of half-finished features. No lie.

But alas, the Cranky Product Manager’s cantankerous, tomboyish lifestyle is hardly threatened, despite DysfunctoSoft’s move to Agile (specifically Scrum) two years ago.  Things are slightly better now, but not that much.

Shocking, the Cranky Product Manager knows.  Because Agile and Scrum are SO FRAKIN’ FASHIONABLE right now, that speaking of them in anything but the MOST obsequious “Agile-is-the-absolute-shizz-it’s-even-better-than-sex” manner, well, it’s kinda heresy.

You see, Agile is a pseudo-religion. It has a Manifesto and a bunch of zealots and everything. (gack)  In fact, the Cranky PM fully expects a pile of comments and trackbacks along the lines of:

  • “The CPM just doesn’t get it. Agile is indeed the shizz. Plus it’s better than sex. It’s new (well, kinda). It’s iterative. All the cool kids (claim) to do it.”
  • “The CPM is a waterfall-worshiping Luddite, afraid of change, out of touch, and a control freak — so typical of a product manager. Doesn’t she realize that Scrum liberates us developer-artistes to at long last build for intelligent audiences, people just like us?”
  • “The CPM must be doing Agile the wrong way. Not me — I know all the secrets. To learn how to do Agile right, visit my blog, read my book, hire my consulting firm, take my training class… With my help, you too can use Scrum to MAKE MONEY FAST, MELT AWAY THE POUNDS without diet or exercise, and become ABSOLUTELY IRRESISTIBLE to the opposite sex. Agile riches will exceed your wildest dreams!!!!!!!!!!”

Hmmmphhh. Such are the stones a heretic must endure.

Anyway, let the Cranky Product Manager continue and speak directly about the unspeakable:

Sure, Agile makes some things (ok, many things) better.  But it also makes some things — IMPORTANT things — worse.

Yes, Agile can speed up the development and improve the quality of small features.  But it’s too often at the expense of the Big Important Work — the heavy lifting, multi-month market analysis and architectural work that lead to REAL customer value and REAL competitive differentiation.

Yes, Agile can do wonders to improve product usability. But the results are often incremental in nature.  Opportunities to come up with innovative user interaction models that put the user experience on a different plane are not explored. Not enough time.

Yes, Scrum can improve the speed of decision making by requiring a “Product Owner” make on-the-spot decisions. But because it does not allow the Product Owner the customer face time to intimately understand the market, it too often results in products that addresses the verbatim enhancement requests of one or two specific customers (whoever spoke to the Product Owner last) while missing the real market opportunities. (See footnote 1.)

Yes, Agile can reduce the size of the development team. But instead of cutting costs, it moves the resource bottleneck to the product management and project management teams which are usually understaffed for the greater demands Agile places on them.

Yes, Agile is good at holding developers’ feet to the fire and jacking their lines-of-code-per-day rate through the roof.  It helps them fix bugs faster too. But because Agile keeps them in an always-on, semi-panicked state, it also leads to burn-out and prevents developers from doing the deep thinking required to solve the really thorny problems and to truly innovate.

Further, the War Room atmosphere and pair programming practices require a different, more outgoing personality than many developers naturally possess.  Granted, his research might be dated, but Tom DeMarco (author of Peopleware) found productivity was highest when developers had private offices with actual walls, windows, and doors that shut — the very antithesis of today’s War Room. In the War Room, the ideas of the more quiet, introverted, and thoughtful developers are too often drowned out by their louder, more obnoxious, and less gifted brethren.

So, despite the massive amount of hype currently surrounding Agile / Scrum, let the Cranky Product Manager remind you that — in the immortal words of Fred Brooks — There Is No Silver Bullet.

Agile is NOT the end-all-be-all for software product development. It is NOT the second coming. It is an improvement to be sure, but it has some big flaws – just like ALL software development methodologies.  And that is more than just “truthiness.”  It is the actual fraking TRUTH, beeyotches…

————-

1. The Cranky Product Manager knows that many Product Management bloggers believe that this problem is solved if you separate the market / customer-facing Product Manager role from the development-facing Product Owner. However, the Cranky Product Manager remains unconvinced.  How can the Product Owner gain the perspective to make the best product decisions without regular customer contact?  More on this later….

CORRECTION: In the Cranky Product Manager wrongly claimed that Rich Mironov of Enthiosys supported the idea of separating the product manager and product owner roles. Untrue. He says he supports this role split it in a world of infinite resources and perfect communication, but of course that ain’t reality. Read his article all the way through (and wait for part 2) for a more civil and scholarly discussion of the problems the Cranky Product Manager rants about. It is truly a WICKED AWESOME piece, so get over there and READ IT.

Related Posts:

{ 21 comments }

Scrum THIS

by The Cranky Product Manager on September 2, 2008

in Agile/Scrum

Hey You! Mr. Release Manager!

The Cranky Product Manager appreciates that you’re trying to do this Agile Scrum thing by the book. And that it is hard for you. Because before this Agile tsunami came crashing down you mainly just tracked the progression of different release documents (Is the PRD done? Check. Is the Functional Spec done? Check. Is the Design Doc done? Check.)

Ok, that’s not fair of the Cranky Product Manager. You did more than that. You also ran hurried release meetings once a week that tried to bury issues instead of surface them (OK everyone, here’s the status of all the documents. Anyone have any issues? None? OK, let’s adjourn.) You also organized two or three Fantasy Cricket leagues plus your wedding during working hours, and boy it all took a lot of time.

But now, in the Scrum era, things are different.  It’ s not easy. You once had a private office, but you now spend the bulk of your day tethered to a communal table in a stifling hot “War Room,” inhaling the body odor of The Veteran, trying to tune-out the grandstanding arguments between two nimrod Hotshots (“My idea is the most elegant…”, “No it’s not. It’s trivial. You’d have to refactor it immediately.”), and listening to the documentation writer bitch and moan that she can’t write the doc by Friday if the product keeps changing every hour. It’s really hard to organize fantasy leagues or surf the web with so little privacy. Plus the porn shui of the War Room is completely off.

So it sucks to be you, Mr. Release Manager, and the CPM is sorry for you.

But just because you are stuck in that War Room doesn’t mean the Cranky Product Manager should have to join you. You argue that in Scrum the product manager is the same as the Product Owner, and therefore the Cranky Product Manager needs to be constantly available to the team in order to make on-the-spot decisions within minutes of the asking.  Ergo, you demand the Cranky Product Manager sit in that sticky-note-encrusted, windowless tomb with you all damn day.

Uh, no way.  Not gonna happen.

Agile Scrum Development War Room
Why not? Because the Cranky Product Manager needs to be the Voice of the Customer and the Voice of the Market.  How is she to do that without actually VISITING some customers and prospects?  And VISITING means that she actually needs to leave the office, hop on airplanes, and fly far, far away.  She cannot answer questions from the dev team within 5 minutes if she’s on a plane, or in a meeting, or on the phone with a customer.  Not that the CPM wouldn’t LOVE to hear debates about Iron Man or whether that Star Wars cartoon is “canon” or not —  all day, every day, for hours on end. Who wouldn’t?

And your response, Mr. Release Manager?  You argued that perhaps the Cranky Product Manager should not visit so many customers and should spend more time in the War Room.

Anyone else see the irony? The Voice of the Customer should have less interaction with customers?  All so she can make on-the-spot customer-facing decisions more quickly?

TRUST that the Cranky Product Manager will have more to say about this Fatal Flaw of Scrum in an upcoming post… She feels a HUGE rant coming on.

Related Posts: So You Think “Agile” Methodologies Exempt You From Product Management

{ 21 comments }

The 6 Types of Software Engineers: Identification, Care and Feeding

by The Cranky Product Manager on August 23, 2008

in Guest Posts,The 7 Types of Engineers

The Cranky Product Manager is on vacation, but in her stead the CPM found a WICKED AWESOME guest blogger, an extremely talented writer/product manager/mom with the nom de plume "Another PM."  Her post is below, and it is so good and so TRUE... Damn, the Cranky Product Manager wishes she wrote it herself. 

Please give "Another PM" feedback in the comments.  We bloggers live for comments.

Enjoy and see you in a week or two or six.

UPDATE:  

1. Buy "6 Types of Engineers" mugs and shwag from CafePress.

2. Check out a real-life Veteran software engineer - hilarious!  

The Identification, Care and Feeding of Engineers on Your Projects

by Another PM

Ah, Software Engineers. They are the creatures upon whom most of us rely in order for our organizations to continue claiming that we are the World's Most Leading Global Provider of Integrated Buzzword Solution Suites (now, with Go-Green marketing!). To be a successful Product Manager in the software development world, you must understand the dynamics of your project team members, and of course engineers are a critical part of that team. 

Early identification of the various engineering types on your project can save you time and effort down the road. So, grab your safari jacket, your notebook and a pen, and follow me into the jungle of 0's, 1's and bugs of all stinging severities.  This post will help you to recognize some common engineering species, and how best to work (or not work) with them.1

Shortcuts: 1. The Veteran  2. The Hotshot,  3. The Great One, 4. The Teflon-gineer, 5. "Offshore", 6. The Maverick

The Veteran

He's been here for five years, and he'll be here for five more.    

Distinguishing Characteristics

  • Cranky.
  • For some reason, he's permitted to use profanity in meetings and otherwise behave in ways that would make his mother cringe and your company's attorneys start job hunting.
  • Casual Friday dress is too formal.  Facial hair is common.
  • You're never in on his private jokes.
  • He's eaten 5 Product Managers before you, and he will chew through 5 more after you're gone.
  • His manager is afraid of him. He's eaten through 5 managers before this one, and he'll chew through ... etc.
  • Yes, he is always a "he".

Do you need this engineer?

Yes. He has the best only knowledge of your product's undocumented, spaghetti code and he knows it, which is why he will never support projects aimed at documenting it. Also, if left ungoverned he can negatively impact the other engineers (except for any offshore team members, which he does not really consider to be part of his team.)

Project Pitfalls:
He can smell fear and ignorance, so don't defer to him too quickly and don't ask dumb questions. You're toast the second you utter your first corporate buzzword in his presence. If he gives you a nickname such as "MBA," you're screwed.

Achilles Heel:
He wants to tell his project war stories, like how f-d up the project before this one was, and which "business people" on the project couldn't handle the stress. He's happiest when reminiscing about Assembler, or about launch 1.x of the product (which is now in V8.3)

Best Bet:
Bring food. Listen to his stories. Defer to his expertise on architecture, even if you think it's wrong, because he's probably right. Do this publicly, so he wins. But the architecture battle is your pawn: don't compromise on anything user-facing, because if he discovers that can scope-cut one critical user-facing feature, this will set the pattern of your relationship.

The Hotshot3

Smart and knows it, often quite young. Has great ideas and hacks crap together at midnight, then... is done.

Distinguishing Characteristics:

  • Unfortunately has little appreciation for what it takes to actually ship software and thus never really finishes his features and his stuff is often fragile or just broken. Can't be bothered with making sure his stuff is internationalized, thread-safe or designed to scale.
  • Can't be troubled to fix what he built because he's on to the next thing. 
  • Detests "process" and all the process hangers-ons like QA, PM, Training, and Project/Program Managers.
  • Doesn't read the documentation OR reads the documentation and codes something "better."
  • Says things that annoy his fellow engineers and managers like, "If it takes Ed more than 2 days to do this feature, then he is seriously stupid." But of course, Young Hot Shot never actually added a real feature in just 2 days either.
  • Rarely seen without headphones or earbuds. Plays World of Warcraft and Halo.
  • Drinks Red Bull and stacks empty cans up in his cube as some sort of offering to the God of Unmaintainable Software.
  • All shirts purchased from threadless.com. Appears to either skate or snowboard. Green IM status 24/7.
  • Natural habitat is start up environments.     

Do you need this engineer?
Depends on whether you're building something that a person will eventually need to use.

Project Pitfalls:
None, really, because you are not even on his radar.

Achilles Heel:
Cannot build evolvable, sustainable software.

Best Bet:
Convince him he's a genius who really belongs in your company's "Innovation" or R&D group.

The Great One

Where did this engineer come from, and can you have five more of him?    

Distinguishing Characteristics:

  • Always delivers on schedule, even when unforeseen code bottlenecks require more time that initially estimated.
  • If unforeseen bottlenecks arise, you don't hear about it from this engineer. Instead, you hear about how this engineer worked all weekend from one of his peers.
  • Respected by engineering peers. Professional in meetings.
  • Honest with estimates.
  • May have a Star Trek accent or a superhero fetish. Loves watching "How It's Made".
  • Solid code, sometimes delivers more than what was requested.
  • After the feature is launched, asks whether it met the users' needs.
  • Keeps up with his bug queue.

Do you need this engineer?
Um, duh.

Project Pitfalls:
Try not to hug this engineer in public. He gets embarrassed and human contact is sometimes confusing.

Achilles Heel:
This engineer is so dependable that his manager tends to put him on every project. He sometimes has trouble saying "no", so can become overstretched. Also he tends to be optimistic in his estimates.    

Best Bet:

  • Give lots of public credit to this engineer, even if he doesn't care about that -- because his peers might. 
  • Send nice notes to his management.
  • Don't ask him to attend time-waster meetings, but if he must, publicly change the agenda to accommodate his part first so he can leave quickly.
  • Add time to his initial estimates to buy him some wiggle room.
  • Play Halo with him Bring him food.
  • Ask how you can help him, and ask often.
  • Encourage this engineer to breed.

The Teflon-gineer

Will do anything to reduce his work. If you've asked for a sports car, this engineer will try his/her damnedest to meet your requirements with a Model T Ford. Deflects all bug assignments with his/her Teflon Work Deflector (in size J for Jerk).

Distinguishing Characteristics:

  • Says things like, "Are you sure the users really want that?" and "Is XYZ functionality really that important? How many users did you talk to? Can I see your notes?"
  • Reassigns his bugs back to you with updates like, "Please provide more clarity", even when you've already referenced the spec page and section which spells out the original requirements with blinding clarity. When you reassign the bug back to him, you get his Out Of Office response.
  • Attempts to lock you into a legal contract specifying everything down to the last minimalist kilobyte of code that will be written.
  • During spec reviews or Scrum, says things like "Oh, you want the page to validate the user's password entry? Well that will cost you an extra 2 days of work...plus another day if you want that alpha tested."
  • Attempts to break your will to live with never-ending requests for excruciatingly documented detail to the point where it would be faster to code it yourself (inclusive of the time it would take you to learn Python).
  • When he delivers, his code is solidly mediocre. He never surprises, never innovates, and never has ideas.
  • Even his peers think he's kind of a jerk.
  • Likes to watch When Animals Attack.

Project Pitfalls:
Serving your sentence for justifiable homicide will impede the project schedule. 

Do you need this engineer?
Did you need your sibling to hold his finger one inch from your nose and say I'm not touching you. I'm not touching you. I'm not touching you...4

Achilles Heel:
His manager thinks he's a jerk, too. 

Best Bet:
Get this engineer off your project. Confront him/her, document as much of this crap as you can, then confront his manager. No good can come of this. 

"Offshore"

Where are these guys, anyway, and what time is it there? Who knows; you always have to count the time difference on your fingers.

But anyway, they seem very nice, and they do try to read the documentation. They just don't always understand it and it's not their fault that they were home sleeping when those critical changes were decided last week.

Distinguishing Characteristics:

  • Located in Malaysia, China, or a former Eastern Bloc country.  (Ukraine is the new India).
  • Their proper English is downright charming.
  • Sometimes they say they understand when you know they don't.
  • They make a lot more work for you, including having to attend 9PM meetings. On the upside, it is nice to have a glass of wine in your PJs while discussing the desired behavior of wildly far-flung corner cases for no other benefit than that of QA.
  • Will often do the needful.
  • Sometimes their code isn't great. But, as I have mentioned, they are generally quite polite.
  • ARE ULTIMATELY NOT CHEAPER. But we'll let CPM cover that topic separately.

Project Pitfalls:
Too many to count on your hands.     

Achilles heel:
Communications.

Best Bet:

  • Document the hell out of your requirements and functional specs.
  • Provide completed mock sets,including exception scenarios.
  • Keep up with change requests.
  • Meet with them often, and for God's sake speak slowly (but not louder, because duh) and speak clearly
  • Stop the meeting conversation often to see if they have any questions.
  • Also, I know you don't want to hear this, but for best results, you really should just go there for a week or so.

The Maverick

He'll do your feature IF he can do it in Ruby on Rails. Or Haskell. Or Python. Or <other hot new language that his peers don't know and therefore can't evolve or maintain.>

Distinguishing Characteristics:

  • Smart. Creative.
  • Doesn't want to build on or maintain the existing codebase (because it's a spaghetti nightmare AND because it's written in Java, which is sooo passe), so he'll roll his own. This will include the creation of an exotic protocol and adapter layer so that the old code can call his code.
  • Dependable -- if you let him do it his way.
  • Magically finds his way off the project if he is not permitted to build in his preferred language.

Project Pitfalls:
Oh, you'll get your feature all right, and you'll get it on time and it'll probably be done well and it may even delight you and your users, but once that guy leaves someone is going to have to refactor it in order to evolve it. And we all know there are few words a PM likes less than "refactor".

Achilles Heel:
Back in my hometown, we used to say "That dog won't hunt" when referring to someone who simply and inexplicably will not do the obvious, such as build on the tech stack into which he was hired. 

Do you need this engineer?
Maybe you could aim this smart engineer at a custom one-off or a stand alone widget that doesn't need to be evolved or maintained.  No.

Best Bet:
Be prepared to make your perfectly reasonable case for building the feature in the existing language in a public forum. Make said case without emotion, and in front of his peers & manager because, trust me, they don't want to support his alien creation any more than you want to. 

1. Caveat: I have only done eng-thropological field work in limited sections of North America,so please comment with your own archetype additions and corrections. Perhaps together we can create a collective academic body of work for Steve Johnson's Pragmatic Marketing Product Management courses.

2. I apologize for the heavy use of the male gender in this post. I tried hard to make these descriptions work using gender neutral pronouns, but it sounded awkward. In the end, the truth of my experiences won over: almost all of the engineers with whom I have worked over the years are men, but duh of course we all know that women are engineers, too.

3. The Hotshot is CPM's entry.

4. Shout out to Suburban Bliss for reminding me about this game.

{ 87 comments }

Product Management Haiku

by The Cranky Product Manager on November 21, 2007

in The PM Profession

Inspired by the fine, upstanding folks at Pivotal Product Management, here are some enthralling and inspirational haiku the Cranky PM whipped together.

Join in the fun!  Submit your own haiku in the comments.

Gartner, Forrester,
How the CPM hates you.
Damn Magic Quadrant.

Product Marketing:
They tell product lies all day
But they don’t know it.

Only Bad PMs
Don’t install or even use
The products they own.

Their bogus excuse:
"Technically impossible,"
Code Boyz and Girlz claim.

Darling Customer.
We shipped you crap. I’m sorry.
Please abuse me now.

Top-down, bottom-up…
How to do product planning?
We always debate.

Supported products.
An integration nightmare.
Zillions of versions.

Upgrade now or else
We’ll de-support the release
Your business uses.

Sales Droid always blames
Lost deals on missing features.
Wins are due to him.

Short beta programs:
For publicity only,
Not for finding bugs.

Trade shows are useless
Tools for generating leads.
They just want free pens.

{ 22 comments }

Getting Demonstrative at Trade Shows

by The Cranky Product Manager on August 28, 2007

in Marketing

The fine, upstanding, big-brained individuals at Pragmatic Marketing posed the question as part of their ginormous BlogFest:

Why demo at trade shows?

So the Cranky Product Manager answers, in her usual, long-winded fashion…

The main reason B2B software companies demo at trade shows is simple: TRADITION. The practice has been around for eons. In fact, the following image depicts the world’s first trade show booth, with a smartly dressed product manager showing off the latest product features to a huge crowd of — wow!– three passersby (pretty typical for a trade show).

Trade Show

Notice that the audience appears to be quite enthralled by the demo of the latest version of the HMS 4.2 (Hieroglyphic Management System). But, alas, only one of the three viewers (meaning the dude with the big hat) has even the slightest ability to influence software purchases. Also, it is not clear why the audience is so very attentive and excited. Perhaps it is the product’s awesome features. Perhaps. But more than likely it is either the demonstrator’s seductive attire or the lusciousness of the nearby Booth Babes handing out swag engraved with AncientSoft’s logo.

Swag

Enough of the history lesson. Back to the question: Why demo at trade shows?

The Cranky Product Manager proclaims: The time has come to rethink the ancient, decrepit tradition of demo-ing at trade shows, or even hosting a booth. It is rarely worth the expense in time or dollars.

The CPM knows what she’s talking about. At two former employers, the Cranky Product Manager did analyses of return-on-trade-show investment. And guess what? Trade shows came out as huge drains on company resources with scant benefit.

Want more detail?

First, the leads generated were always crap. Hardly any of these folks ended up spending a dime on software. They were people without budget or influence. People without real problems to solve, who were just trying to "keep up with the industry." People more interested in the crappy swag than the product. People looking for a job. People who worked for competitors. People who wanted to hit on the super-hot Cranky Product Manager or the not-quite-as-hot-and-definitely-not-as-smart Booth Babes. People who were so overwhelmed by the trade show’s hyped-up atmosphere, or so hung over from the previous night’s drunkfest, that they could not even attempt to understand what the company did: Please just drop your literature into my tote bag so I can sort through it back at my office.

Second, the cost of running a booth is ridiculous. The opportunity costs of drawing people away from other tasks for two to four days is huge. Then add the costs of paying $500 to rent each power cord, $800 for a table, $1000 for a carpet, $2000 for a carpet pad, etc… Unreal. But that’s not all! You have to hire union laborers to carry your laptops into the building, at a rate of $100 per laptop. And then hire union electricians to plug them into your $500 power cords at the rate of $200 per power adapter fondled- – because everyone knows the act of even touching an electric cord is fraught with so much risk that a licensed professional must assist.

So again, back to the original question: Why demo at trade shows?

And at last, the Cranky Product Manager’s answer:

Don’t, if you can help it.

In fact, don’t display at the trade show at all. Just attend and do some competitive research. Attend the sessions, which are often worthwhile. But don’t waste your money running a booth in attempt to generate leads.

But the Cranky Product Manager is a realist. She knows that the Trade Show Tradition is tough to mess with. Your company is going to display at BigFatSoftwareConference-X no matter what you say.

So in that case, you, the Product Manager, might as well make the case that 1) a demo is essential, 2) no mere sales engineer has the necessary brainpower to demo your product effectively, and 3) you must personally attend to demo the product yourself.

And why would you argue this?

1) So that you, as a Product Manager, can secure passage to exotic trade show locations like Paris, London, Vegas, or Hawaii.

Booth babes helping demo at an enterprise software conference 2) So that you, as a Product Manager, can have an excuse to hang out with the Booth Babes. Who knows, maybe one of those washed-up-at-age-28 former models will actually speak to you. Maybe your demo of your product’s awesomitude will wow her to pieces. Maybe she’ll say "Wow, Mr. Product Manager. I am so impressed by your software’s advanced monitoring and alerting features. And you say it’s I18N compliant to boot? *SWOON* Do you want to buy me a drink later?"

And for the CPM’s fellow PM sistahs, we can only wait for the day (far off, no doubt) where either there will be male booth babes or where this annoying and kinda offensive industry custom ends. (But that’s a post for another day.)

3) So that you, as a Product Manager, can network with the hiring managers at your competitors and maybe snag yourself a better job. But keep in mind that VPs and Directors of PM are usually speakers or panelists and not slated for demo-duty in the booth. You better secure an All Conference pass to identify and discretely approach them.

Another enterprise software conference, stocked with booth babes. Have fun demo-ing at your trade show. Know that even though you are wasting company resources and your own time, at least you are upholding and respecting the centuries-old traditions of the venerable Product Management People. Not only that, you are helping ensure the gainful employ of Booth Babes the world over. So sleep well, young Demo Dolly / Demo Dude, sleep well.

{ 4 comments }

The Value of an MBA in Product Management

by The Cranky Product Manager on May 29, 2007

in The PM Profession

A question from a reader:

Q: Is an MBA necessary to advance in Product Management to the Senior level, Director level, or beyond? Or can one compensate for the lack of a Masters with strong analytics and high-level strategy and presentation skills?

A: The Cranky Product Manager specializes in cynicism. Thus, her answer: it depends. It depends on whether your boss and boss's boss have MBAs.

If yes, then advancing your career will likely require this illustrious degree. If the big cheeses thought an underling could do an adequate job without forking over $100,000+ for the MBA designation, then you might force them to regret their own education investment. And we can't have that!  No sireee.

If your higher-ups don't have the degree, then they probably pride themselves on their own awesomitude: their innate, genetic business prowess – the kind of natural aptitude and raw talent that would only be hampered by book learning. This kind of uneducated boss regards the MBA as a huge waste of money and time, and MBA holders as ungifted, inexperienced, intuition-challenged, unimaginative  drones.

So, the Cranky Product Manager's advice to you: if you think the LEARNING will be worthwhile for you and will help you become a better product manager, then go for it. Because the piece of paper itself, etched with that marvelous "M.B.A." designation, does not yield any automatic benefits in software product management.  In management consulting and investment banking it does, but not in software.

Yours as a fountain of useful career guidance,

The Cranky Product Manager

{ 19 comments }

So You Think “Agile” Methodologies Exempt You From Product Management

April 19, 2007

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. [...]

Read the full article →

A Day in the Life of the Cranky Product Manager

January 28, 2007
Read the full article →

← Previous Entries