Every time the Cranky Product Manager reads about a new B2B startup or product, she gets a sense of déjà vu.

Alas, it's not a glitch in the Matrix. It's because pretty much every single product pitch sounds exactly the same.  Watered down, generic, and 100% free of taste. 

A grinder is at work at almost every B2B software company.  A soul-crushing process that pulverizes the unique, complex, and interesting, into gruel-like messaging that the industry's lowest common denominator (and by LCD, the Cranky PM means the PR people) find acceptable and almost understandable. (see footnote 2)

Observe as the Unique Selling Proposition of DysfunctoCrank is ground into pasty mush.  (Anyone remember that game "Telephone"???)

What Development Says to Product Management: 

DysfunctoCrank's architecture uses an MPP-architecture, patent-pending modified vulcan compression techniques, Eventual Iron(TM) technology, predictive klingon data cloning,  dynamic resource kirk-ification, blah, blah, and blah.  We tested DysfunctoCrank on clusters to 64 CPUs, and it did pretty well.  We haven't tested on anything bigger.  

Remember, DysfunctoCrank uses a proprietary clustering. We're going to have to rearchitect the entire thing from the ground up if you want to support cloud deployments, and that will take the entire Engineering team at least a year or two.

What Product Management Says to Product Marketing -  For 80% of the use cases, DysfunctoCrank is about 35% faster than anything else out there and can handle double the workload of anything else.  It can scale out and scale up near-linearly, across any number of CPUs or machines, and has best-in-class features for high availability.

DysfunctoCrank can currently be deployed on-premise, but in our next release we are aiming for cloud deployments (although we still have significant technical challenges to overcome).

What Product Marketing Says to Corporate Marketing -  DysfunctoCrank delivers cloud-based reliability, performance, and scalability that no other Crank system today can match. It is the industry's most efficient, cost-effective way to achieve your business goals.

• All the benefits of the Cloud: Pay only for what you need - start small, add cloud capacity only as needed. 
• Infinite linearly scalable, supercharged predictable performance, and no wasted capacity
• Self-healing, managed reliability

What Corporate Marketing Says to the Press and to the Analysts - DysfunctoCloud is a cloud-based solution platform designed to increase your revenue, lower your TCO, and synergize with your efforts to engage users in a virtualized, Social Media Web 2.0, cloud-based world.  Plus it's in the cloud. DysfunctoCloud is CLOUD-TASTIC!!!!

What the Press Says to the World - DysfunctoCloud is just like the cloud-based offerings from vendor X, vendor Y, and vendor Z.  

What the Analysts Say to the World- In our TragicQuadrangle, we're moving DysfunctoCloud a smidge to the right on the "vision" axis, because their cloud stuff sounds kinda seksi. But we're moving them down on the "ability to execute" axis until they buy more of our consluting (see footnote 2) services.

Footnote 1:  Allow the Cranky Product Manager to continue digging at MBA programs: Business school is a similar grinder. At top B-schools, the newest crop of MBA students arrive on campus as a highly diverse group, from all professions and walks of life. Then, just two years later, 80% of the students depart as one of only two varieties: banker or management consultant. 

Footnote 2: Not a typo.

As the Esteemed Crankerati already know, the Cranky Product Manager has been creeping around the software product management universe for quite some time.  Long enough that perhaps she should replace her blog's masthead photo with a less youthful and more saggy derriere.

In that extended time, the Cranky Product Manager has encountered LOTS of product managers.  Hundreds. And thus she's heard about every lame product management excuse that ever existed.

So she's here to ask -- no, BEG -- PLEASE, STOP IT!  Please stop making EXCUSES for not doing your freakin' job.

If you can't do the Product Management job, if you don't have what it takes, if you don't have the passion and the drive, if you don't have the scrappiness to figure out how to Get Shit Done (TM), well, PLEASE leave the profession. The Cranky Product Manager begs you. 

In this economy, there are plenty of GOOD, resourceful, and influential product managers who will gladly step up and take your place. The world will be better for it.  No doubt you will be happier too.

(Note that the Cranky Product Manager knows that you, as a wicked awesome and elite reader of this blog, would NEVER be so lame. But if you could please inform all the other PMs out there, she would be grateful).

So, let's list some of the most common Product Management Complaints, and the Cranky Product Manager will explain why each is a freakin' cop-out. 

And SURE,some of these cop-outs have some validity. Some organizations are truly screwed up (trust the Cranky Product Manager, she KNOWS), and some people are real dysfunctionals.  But just as you should NEVER call your former boss an idiot in a job interview because it makes YOU look bad -- not your former boss -- don't say these things either.  Especially in the Cranky Product Manager's presence, and you never know, she might be your boss or your co-worker.  So STFU.  And Suck it Up, Buttercup.

EXCUSE #1: "The developers just do whatever they want because Product Management has no authority over Development."

Barf. And So WHAT.  Probably only 1% of product managers in the world have ever had official authority over Development.  Yet, somehow, every single day, product managers the world over manage to convince developers to take their direction.  It's called leadership. You do it by respecting people, gaining their respect back, and convincing them that your vision of the future is a compelling one.

And sorry to tell you, even if you had the power to fire every last developer tomorrow, well they still wouldn't do what you wanted unless they bought into your vision. People with brains are like that. (OK, to keep their jobs, maybe they'd do 10% of what you want.  But that's it.  They'd claim the rest was "technically impossible.")

If you want to whine that "all the responsibility and no authority" blahblah yet AGAIN, instead why not put a neon sign above your head that proclaims "I am a bottom 20% product manager, with no ability to lead or influence" instead?  It would be less annoying to the rest of us.

NO EXCUSES!

SHAMELESS PLUG! Buy a "No Excuses Product Management" mug or t-shirt!

(This post is getting way too long, so it's been broken into 4 parts.  Tune in NEXT WEEK for Lame Ass Excuses #2 ("I didn't get training").  Plus at least two more.

by Shreyas Doshi

• Shreyas Doshi on Twitter:  http://www.twitter.com/shreyas
• Shreyas Doshi's Blog:  http://shreyasdoshi.typepad.com/

• No dependency on mobile network capacity
• No impact from density of surrounding buildings or obstacles
• No necessity for the presence or absence of electricity.
• No requirement for the user to own or know how to operate a computer

Twitter usage is growing robustly, but is hampered by insufficient network capacity at heavily attended tech events such as SXSW and anywhere Steve Jobs gets up on a stage. Tweet volume from such events is lower than would be expected due to the connectivity issues.

It is proposed that designated drop zones be established at major tech events, where conference attendees can send and receive tweets. To avoid any dependency on telco infrastructure, tweets will be delivered to these TweetDrops by a robust and innovative mechanism.

Each 140 character tweet is printed on a 5 mm wide paper strip, which is laminated and wrapped about the leg of a single carrier pigeon. The tweet is printed using a standard UPC barcode for ease of decoding at the remote end. The lamination is not necessary in theory, but in practice the messages often need to be wiped clean before processing (these are pigeons, after all).

Conversations become difficult to follow if tweets are delivered out of order, but ordering is not guaranteed by the underlying network topology in this case. Therefore an 8 bit sequence number will be prepended to the barcode, which will be used to re-order pigeons arriving at the destination.

With 8 bits for sequencing information, only 256 pigeons can be launched at a time. The next wave of pigeons cannot be launched until it is certain that all members of the previous wave have left the system. To achieve acceptable throughput the natural lifespan of the pigeons cannot be used for this purpose. Therefore, a small explosive device is fitted before launch to place a strong upper bound on the Time To Live (TTL) for that tweet. The next wave of tweets can be launched when the TTL for the previous wave has expired. 3. Loss detection

Due to the TTL mechanism employed for robust ordering it is possible that tweets will be dropped (or, more properly, exploded) in transit. To allow for retransmission an additional 8 bit acknowledgment field will be prepended to the barcode, and used to implement a sliding window protocol. (XXX Hang on, are we reinventing TCP here? Let's have a sit-down about this before you forward it to PM, or we'll end up rat-holing on this topic.)

Though lost tweets are expected to be a serious burden during initial deployment of this technology, it is believed that natural selection will result in a more reliable infrastructure as the less dependable population of pigeons is removed from the breeding stock by the TTL mechanism.

The operations cost of this infrastructure is expected to be high, due to the need for replacement of pigeons whose TTL expired in transit. It is proposed that a breeding program be established in order to replenish capacity at minimal cost. This also nicely solves the problem of providing something for the pigeons to do between major tech events.

The necessity of printing each tweet on a strip of paper and scanning the paper at the destination is a serious bottleneck in the communications path. A more efficient mechanism would be to download the tweets directly into the carrier pigeon via an existing Twitter API. Unfortunately the pigeons have strongly resisted attempts to implement any such mechanism.

The TTL mechanism can reasonably be expected to elicit a negative response from both animal rights activists and civil defense authorities, and should be considered only a temporary measure to reduce the time to market. A subsequent update to the infrastructure should investigate use of electromagnets to confuse the carrier's natural homing instinct and send them somewhere where the tweet payload they carry will be harmless.

No thorough analysis of the security of the carrier pigeon transport has been conducted. Because each pigeon will follow a different route to the destination owing to differences in wind currents, temperature gradients, and mood, it is unlikely that an attacker would be able to capture an entire conversation. Additionally the TTL mechanism discourages interception of the pigeons in flight.

Encryption of the tweet payload is acceptable only if the pigeons can be guaranteed not to cross from within the United States to another sovereign nation, as such would violate US export and munitions laws.

[1] D. Waitzman, "A Standard for the Transmission of IP Datagrams on Avian Carriers," RFC 1149, 1 April 1990.

Dear Cranky Product Manager, I have attached a picture of the real Veteran Engineer that works with me. I saw your post, the description of Mike, and bought the mug for him. He, in turn, sent me the proof that corroborates what you have posted beyond the shadow of a doubt. Please feel free to post on the site. All the best, Maggie Sr. Product Manager

• No (party) animals were endangered during the filming of this picture.
• No additional clothing was needed to be purchased by the photo subject in order to take this picture.

• That you BRIBE engineers using free food. Her point was that you discuss the issues with individual engineers in an INFORMAL setting. If you can do this by playing some (free) Nintendo Wii with them, then fine, do that.  (Note that the Cranky PM usually does not pay when she lunches with engineers; everyone pays for him/herself.  Of course, this only works if you mostly ask developers to agenda-free lunches. Otherwise they'll be suspicious every time you ask them to lunch.)
• That you meet with individual engineers prior to EVERY meeting with Engineering.  It's only mandatory before the meetings you expect will be contentious.  (Note, though, that if you frequently meet and socialize with individual developers, you can expect less and less contentious meetings over time.)

1. The "rational" engineering organization does not exist because it is made of people, and people are inherently irrational.
2. The so-called rational Development Team might do what you recommend even if they disagree with you. But if you want them to do a GOOD or possibly even GREAT job, if you want to keep them motivated, and if you want FUTURE projects with them to go well, then you will spend the time to convince them your recommendations are the right ones.
3. It's much easier to be a PM if you have the loyalty and respect of the Development Team. You get that respect by giving it - by listening to others' opinions and learning about them as people.   And don't only talk to your developers when you want something from them.  Seriously, that makes you a user and abuser.
4. If you know the Development Team is going to fall in line with your recommendations because they are "rational" or will buy into your recommendations, the meeting won't be contentious will it?  So, maybe this Divine Rule doesn't apply.

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

The Big Winner - Offshore

The Veteran

The Great One

The Teflon-gineer

The Hotshot

The Maverick

The Clockwork Mouse

And check out the related "Things to Say When You're Losing a Technical Argument" list  - an oldie but a goodie.

More official rules for Bingo and Buzzword Bingo are here.

Related Posts:

• The 7 Types of Software Engineers
• Three Things the Cranky Product Manager Doesn't Want to Hear