web counter

From the category archives:

Development

Watch as your unique selling proposition is ground into gruel, indistinguishable from everyone else's gruel.

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)

telephone game girls

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.

Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email

{ 58 comments }

No Excuses Product Management (Part 1)

by The Cranky Product Manager on May 28, 2010

in Development,The PM Profession

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.

Also in No Excuses Product Management

  1. No Excuses Product Management (Part 1)
  2. No Excuses Product Management (Part 2)- Stop Whining About Training
Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email

{ 25 comments }

The Cranky PM on “Been There, Done That”

by The Cranky Product Manager on March 5, 2010

in Development

The following cartoon has been shamelessly republished from Shreyas Doshi's excellent "How to Get that Next PM Job" presentation to the Silicon Valley Product Management Association.  Many years ago, during her first month at DysfunctoSoft, the Cranky Product Manager had this EXACT argument with the Engineering Manager for DysfunctoCrank:
Shreyas Doshi on Product Management

by Shreyas Doshi

It was years ago, but to this day the Cranky PM does not understand how that a-hole could take so LITTLE PRIDE  in his work that he would insist on shipping a product with the name misspelled. At the time, the Cranky PM was shocked. But after years in the product management game, nothing surprises her anymore. Rest assured, the Cranky PM won this battle.  The product was NOT renamed DysfucktoCrunk. A little link love for Shreyas Doshi, for making the Cranky Product Manager chuckle just a little bit, through the tears of frustration:
Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email

{ Comments on this entry are closed }

Guest Post: The Cranky Engineer Responds to a PRD

by The Cranky Product Manager on April 1, 2009

in Development,Guest Posts

Today we have a super-duper-uber-fantastic guest post from the Cranky Engineer, aka DGentry of codingrelic.geekhold.com. Check out his blog.  It's WICKED AWESOME. Also, you might recall that DGenery was the BIG WINNER of the Cranky Product Manager's caption contest for the "7 Types of Engineers." He won a fancy pants coffee mug.  AND HE LOVES IT.  Maybe YOU should buy a coffee mug too.... ---------------------------- From: Cranky Engineer #4 To: Product Manager #4 Date: Apr 1, 2009 Subject: Twitter reliability enhancement functional spec Got your PRD about the 3G connectivity issues at the SXSW conference and the resulting drop in twitter volume, thanks. We couldn't help but notice the lack of any actual requirements in the requirements document, but the main point seemed to be to "make it mo' betta." As mobile tower placement is subject to considerable regulation, we presume that the PRD is not calling for a build-out of a new national 3G network, but rather to eliminate dependencies on external factors beyond our control. Thus:
  • 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
I think we've come up with a proposal which meets these requirements. The only remaining dependency is literacy. As we do not control the educational system in this country, this dependency may also need to be eliminated in a future version of this document. Abstract of Proposal

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.

1. Encoding

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).

2. Ordered Delivery

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.

4. Operational Issues

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.

5. Direction of Future Work

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.

6. Security Considerations

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.

7. References

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

Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email

{ Comments on this entry are closed }

New Cranky Mug Design

by The Cranky Product Manager on February 16, 2009

in Blog Business,The 7 Types of Engineers

Hey!  Look!  It's a new Cranky Product Manager mug! It declares to the world "I AM A CRANKY PRODUCT MANAGER." Cranky Product Manager coffee tumbler from CafePressYou should get yourself one.  It's WICKED AWESOME. PM leaders, just think of it. Finally, the perfect present for your team of put-upon product managers--those hard-working, in-the-trenches professionals that get no love, no appreciation, no free trips to the Bahamas, and no credit.  And, given this economy, they probably get no bonuses or no pay raises this year either. You gotta do something for them, right? Something to stave off  their burnout for at least another year... Here's an Elegant Solution(TM):  GIVE THEM MUGS! Just imagine how spiffy you will all look at team meetings, each clutching your very own cranky mug. The first 50 mugs sold get special pricing of $12.99 for the small, and $14.99 for the large.  After that, the prices will go up by $1.50 each. You can also get a WICKED AWESOME travel mug too.  That's what the real-life CPM is getting. So BUY NOW.  Who says you can't buy for next Christmas now? Oh, and if you also want to buy some 7 Types of Engineer mugs, you'll find them here. Thanks, and ENJOY.
Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email

{ Comments on this entry are closed }

The Veteran Software Engineer: Hard Proof At Last

by The Cranky Product Manager on February 9, 2009

in The 7 Types of Engineers

7:00 am. The Cranky Product Manager awakes.  Grabs the Blackberry Curve off the bedside table. Starts deleting spam. Opens the following email from a reader and starts laughing hysterically. Darling Husband is startled awake and is like "what the???"
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
And here the photo, along with Mike's disclaimers:
  • 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.
You will notice that Mike The Veteran Software Engineer is holding a Veteran Software Engineer mug.  The Cranky Product Manager is always a sucker for a good recursion gag.  It reminds her of her lamda calculus-filled  freshman year at a random institute of technology. Note that you readers should all take this as a hint to BUY MUGS and give them to engineers. Thanks Mike and Maggie, for giving the Cranky Product Manager a good chuckle!
Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email

{ Comments on this entry are closed }

On Engineering Meetings (redux)

by The Cranky Product Manager on January 15, 2009

in Development

The Cranky PM is finally getting up the energy to respond to comments on her older blog posts.  In particular, those from a certain reader who keeps inflicting violent disagreement on her. What THE???  Who does he think he IS?  How DARE HE disagree with the Cranky Product Manager?  When is he (along with the Cranky Product Manager's husband) going to at LAST learn that THE CRANKY PRODUCT MANAGER IS ALWAYS RIGHT. This is a fundamental LAW of the universe.  Truly. Anyway, here is one of the violent comments that has the Cranky Product Manager's knickers in a twist.  It is on the Divine Rules of Product Management #1: Prepping for Engineering Meetings post. sushidudexsmall-300x198 Bribing Software Developers with SushiYou know, the post where the Cranky Product Manager said (in a much more long-winded fashion), "If you're going to meet with the Engineering Team and you suspect the meeting is going to be contentious because some/all will be surprised or disagree with your recommendations, then make your case with each team member individually ahead of time so that the meeting goes smoothly." To be perfectly clear, the Cranky Product Manager was NOT suggesting the following:
  • 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.)
Anyway, who could have guessed anyone would disagree with the idea of meeting with engineers individually before contentious meetings?  Not the Cranky Product Manager. During the Cranky Product Manager's days as a hoity-toity management consultant in the McBainCG Group, this practice was called "the meetings before the meeting" and was regarded as fundamental.  The goal of Big Meetings was to get the client team officially on-board and start them moving forward with the McBainCG Group's recommendations.  Without the "meetings before the meeting," getting this "Let's Go" decision was very unlikely. Why not? Well, first, many people -- especially engineers -- pride themselves on being these paragons of rational thinking (this is called self-delusion). These folks CANNOT say "let's do it" without trying to poke holes in your arguments for a while -- sometimes a LONG while, as in hours. Second, without "meetings before the meetings," you are leaving an awful lot -- too much -- to chance.  The meeting and your entire project could go to hell because someone has an objection you hadn't anticipated and you say something stupid.  Or this common situation: an engineer is surprised by your findings and has a visceral emotional reaction against the "surprise" aspect, but instead of complaining about the surprise, s/he shoots down your findings, in public. Then, the meeting ends before you can make a proper rebuttal.  Great. Now you'll have to work five times as hard to convert this person to your course of action.  And if this person is respected or influential, well you gotta work on other people too. Now, as far as Saeed's assertion that in a "rational" engineering organization, the developers will fall in line and do what PM recommends, the Cranky Product Manager says:
  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.
Paul Young commented that these "meetings before the meetings" take a lot of time and are really only worthwhile with the lead developer/architect (not the junior developers).  Well, again, the Cranky Product Manager respectfully disagrees.  In her experience, junior developers that are not "sold" on the PM's recommendations are often very disruptive to the actual project (even if they are quiet in the meeting) and spread all kinds of negativity.  This varies of course, but many young developers (especially those hailing from elite "Institutes of Technology") are Hotshot types who think they are smarter than everyone else -- ESPECIALLY product managers. Solomon commented "I bet Cranky Product Manager is Asian."  Well, maybe, but maybe not. Is this comment because the CPM's tactics provide ways for engineers and product managers alike to avoid losing face in a public forum?  Or is it because she clearly likes sushi?  Explain? Paco commented that the "meetings before the meetings" were important for engineers, but maybe not for other types of business professionals.  Well, the Cranky Product Manager only partially agrees.  Engineers are special because they like to think they are super-rational and analytical and love poking holes in arguments, and thus need to be given plenty of time to do this.  Further, their unique role makes it easier for them to obfuscate what they are really doing. However, "meetings before the meetings" and getting buy-in are important for ANY meeting you think will be contentious.  NEVER surprise ANYONE - - no matter their role - at a Big Meeting where you're seeking "Let's Do It" approval.  Yes, this means the CEO. Find a way to give him/her a preview of what you'll say ahead of time. Anyway, this whole thing reminds the Cranky Product Manager of a post she wrote two years ago entitled "That All the Responsibility But No Authority" Saying.  Check it out.
Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email

{ Comments on this entry are closed }

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
Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email

{ Comments on this entry are closed }

Caption Contest Winners: 7 Types of Software Engineers

December 24, 2008

At long last, the Cranky Product Manager is posting the winning captions for the “7 Types of Software Engineers” cartoons!!!! Whoo hoo. Sorry about the delay.  It’s just a big frakin hassle to put captions on cartoons and create a Cafe Press store — all so the Cranky Product Manager can order some mugs with pictures [...]

Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email
Read the full article →

Wicked Fun Game Highlighting the Never-Ending Battle Between Product Management and Development

December 22, 2008

The Cranky Product Manager has a Christmas present for you.   No, it’s not something from her recommended “Wicked Awesome Presents for Product Managers” list, alas. (Buy your favorite PM a present now! Last day for shipping). Nay, it’s a fantastic board game – a classic, with a new twist. It will give you hours [...]

Share and Enjoy:
  • Twitter
  • Facebook
  • LinkedIn
  • del.icio.us
  • Print
  • email
Read the full article →