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.
