|
I love to play cards. I've spent many hours sitting around a kitchen table
playing pinochle, euchre or spades.
But I think my favorite card game is bridge. More specifically, the variant
of bridge which fascinates me is called "duplicate". The basic idea of duplicate
bridge is that your score is a function of how well you play your cards as
compared to how the other teams played the exact same cards.
Just to be clear, let me repeat: In duplicate bridge, you are playing the
same cards as your opponents. The luck of the deal is basically eliminated.
You have 13 cards in your hand, so there are 13 "tricks" available to win. If
you are dealt excellent cards, there is no particular reason to get excited.
Yes, your cards will take lots of tricks, but that's not the point. The issue is
whether you take as many tricks as the other people who play those exact same
cards. If you take nine tricks but somebody else finds a way to take ten, you
lose.
Duplicate bridge is a brutal game. Every small mistake can be very
costly. I do like to go to the local bridge club sometimes, but
I usually end up in last place. At the end of the evening, I review each
hand and figure out what went wrong. Even though I am terribly bad at this
game, I still enjoy it because every game is such a learning experience.
I often wonder what other pursuits would be like if they had to operate under
the same rules: Resources and context do not change -- the only variable
is the ability of the person managing those resources.
These questions become particularly interesting to me when asked in the field
of software product management. For a given piece of technology or code, what
would happen if somebody else were managing it?
If I were managing the Delphi
product instead of Borland, could I do a better job?
If Joel Spolsky were managing
Vault instead of me, would the product have more users?
If Sun were to hand the management of Java over to a committee of monkeys, would it be
more successful? 
Alas, these hypothetical fantasies are not going to happen. That's
unfortunate. If ISVs had to play duplicate, we would all quickly learn a lot.
First, the sheer volume of our stupid mistakes would be exposed, and we would
quickly learn how very bad we all are at product management. And after that, we
would start learning the fine points. Instead of just chalking up every
failure to the fault of "bad marketing", we would review each decision and
figure out exactly where and when we played the wrong card.
We can't play duplicate with our shrinkwrap products, but we can learn the
fine points of marketing. Marketing is not some vague and fuzzy realm where only
luck matters. There are principles which can be learned and applied.
Al Ries and Jack Trout refer to these principles as "laws". Their
book, entitled "The 22
Immutable Laws of Marketing" is one of my favorites. And I couldn't help but
notice that there are exactly 22 weekdays in the month of June. So...
During the month of June, I plan to post a brief blurb each
weekday. For each of the 22 laws, I will summarize the main point and draw
a connection to the software industry. My entries will not be complete
discussions of the topic. Interested readers should read the
book and follow along.
For those who prefer to read this series of postings in printed form, a PDF version is
available.
|
