Home About Eric Topics SourceGear

2005-07-12 14:22:16

The Game is Afoot

My biases are obvious.  I am a programmer (or rather, a developer).  I believe the best ISVs are the ones which are started and managed by someone who knows how to use a compiler, not by someone who was trained to run a business.

But I do admit that a big problem happens when a geek becomes the founder of a software product company.  Suddenly the geek must do a whole bunch of stuff they were never trained to do.  Somebody has to keep track of the finances, make the coffee and devise clever ways for management to mistreat the employees. 

Luckily, a lot of this "non computer science stuff" is fairly intuitive.  We've got no training on such matters, but if we can figure out how to write a multithreaded network server, we can probably rent some office space without screwing it up too badly.  But one area consistently confounds us.  In my opinion, nothing in a small ISV is more difficult for a geek than market competition. 

We can understand deep abstractions and object oriented programming.  We have no problem grasping how virtual memory works.  Some of us can even remember the keystrokes to do a search and replace in vi.  But when geeks start talking about the issues of software product strategy in a competitive market, otherwise intelligent people suddenly sound like Paris Hilton.  We just don't get it.  Geeks understand market competition about as well as men understand women.

To some extent, this deficiency arises from the tendency for computer programmers to think of things in "black and white" terms.  We polarize every issue toward one extreme or the other.  The basic element of a computer is a bit, and a bit is either on or off, never in between.  This "binary mentality" infects our perspective at a very basic level, often causing us to be somewhat clumsy when dealing with any topic that is characterized by shades of grey.

But my convictions remain unchanged, so I am always looking for ways to explain this topic in terms that geeks will find intuitive.  Along those lines, this article proceeds from a single observation:  Geeks don't understand marketing, but they do understand games.

#include <You_Need_Competition.h>

Before I get started, I want to remind the reader of something that I have said before:  You cannot avoid competition.

You think you can.  In fact, you think that you must.  You believe that the only way your product idea can succeed is if it doesn't have to actually beat any competitors.

So as you daydream about starting your own company, you search for product ideas, and you discard all of the ones which would already have a known competitor.  Eventually, you find an idea which is completely unique.  Nobody is selling anything like it.  Finally, the path before you is clear!

So you proceed to build your killer app.  Of course, you are terrified that somebody else will discover your amazing idea, so you keep everything a secret.  You setup a small office in the corner of your basement and paint the windows black.  You tell your wife you are downstairs looking at porn so she won't get suspicious about what's really going on.  Not a single human being on earth gets a glimpse of your product until you are finally ready to unveil your 1.0 release.  You emerge from stealth mode and wait for the world to overload your web storefront with traffic.

But the orders don't come in.  Several months go by and eventually you realize the truth:  The reason nobody else was selling this kind of product already is that nobody really needs it.  If any substantial number of people were willing to pay for the solution you created, then somebody else would already be trying to relieve them of their money.

So your company fails.  You decide to take three months off to recover from all the stress.  You sit at home all day, listening to soft music on your iPod, oblivious to the irony:  Apple is the clear market leader in digital music, even though they brought their product to the market very late, after all of its competitors were well established.

You cannot succeed by trying to avoid all competition. 

But you also can't succeed by simply pretending that the competition isn't there.  Your intuition may be horrible, but it isn't actually that bad.  Competition can kill you.  Marching directly into territory occupied by strong competition is usually just as stupid as it sounds.

So neither of these two extremes is very helpful.  We really need to understand the subtleties in between.  In this article, I'm going to surface a few principles of software product competition by drawing comparisons to games.

Ping Pong

The game

Ping Pong is a game of two people using paddles to hit a small plastic ball back and forth across a table with a net in the middle.  For obvious reasons, Ping Pong is also called "table tennis".  The winner is the first person to score 21 points.

The principle

The thing I find most interesting about Ping Pong is that you can often win without doing anything fancy or aggressive.  A lot of players think the way to win is to slam the ball really hard.  The problem with this strategy is that a slam is a high-risk/high-reward shot.  If you do it right, you almost certainly score a point when your opponent fails to return the ball.  If you do it wrong, you give your opponent a point.

Modesty aside, I consider myself a "pretty good" Ping Pong player.  I can slam the ball when necessary, but I hardly ever do.  I can beat most other players by simply returning every shot with a little backspin.  Hitting the ball hard simply isn't necessary.  All I need to do is wait for the other player to make 21 mistakes.

How software is similar

You can beat a lot of competitors by simply not beating yourself.  Most companies go out of business because of their own stupid mistakes, not because of the brilliance or strength of their competitor.  Stay conservative, and stay in business.  Watch the years go by, and you'll be surprised how many of your competitors come and go.

This lesson is hard to learn.  Slamming the ball is fun.  It's so satisfying when we score a point that way.  But when our slam misses the table by 3 feet, we often avoid learning the lesson.  We tend to want to blame failures on external factors instead of asking ourselves if the risks we took were reasonable.  After the company fails and the Aeron chairs have been auctioned off to pay creditors 20 cents on the dollar, management blames everyone but themselves.  "It's the VC's fault!  We only needed maybe 12 more months and we would be taking revenue, but that @*&#$%# refused to give us our seventh round of financing!"

The lesson is actually quite simple:  If you regularly take big risks, you will eventually get burned.

Example

Oh my.  I need an example of a company that killed itself by taking too much risk.  There are thousands upon thousands of such firms.  Who should I choose?

I guess I'll stay close to home and briefly summarize the story of Argus Systems Group, a security software company here in Champaign, Illinois.  If you visit their website today, you'll find a company which is alive and well, but that's not the whole story.  What you see now is the new Argus.  The original Argus filed for bankruptcy in May 2003.  The company's assets were sold in July 2003 for a little over $1.5 million to new management who have resurrected the failed venture. 

What went wrong?  Clearly the company had value.  A company selling advanced security software in the post 9/11 world should certainly be able to find customers, right?

The problem with Argus was not in finding customers, but in finding enough customers to pay the enormous financial obligations to its investors and creditors.  Argus was founded in 1993.  They took money from outside investors in 1994, but I don't know if it was debt or equity or a mixture of both.  More outside money came in 1996.  And again in 1998.  And a bunch more in 1999.  And then another chunk in 2000.

In 2001, they were working on getting another 35M in financing, but the deal fell through, and the death spiral began.  In March 2003 the local newspaper was writing about Argus missing payroll.  One of the company execs said, "We're still carrying a lot of debt."

Argus had real products with real customers, but the company was crushed by all of the financial risks it had taken over the years.

Don't take this too far

Conservative or bold?  Which one?  This issue is not a checkbox, it's a slider.  You have to take some risks if you want to be in business.  The trick is to figure out what kind of risks to take.  Learn how to take smaller risks, and then take as many of them as you can.

Sorry!

The game

Sorry! is a family board game produced by Parker Brothers.  Each player has four "pawns".  The goal is to move all four of your pawns from a starting point to the finish.  Each turn, you draw a card and move one pawn the number of spaces indicated on the card.  (Sorry! is a registered trademark of Parker Brothers.) 

The principle

In order to move a pawn into the finishing area, you have to draw the exact number you need.  If you are 3 spaces away and you draw a 5, then you can't move.  The effect of this rule is that every game of Sorry! ends up being close.  A player can get way ahead, but they almost always slow down at the end as it takes them several turns to draw the card they need to win.

How software is similar

In software product competition, things are often set up favorably for the other players to catch up to the leader.  By nature, the leader usually has more things slowing them down.

The small ISV working on version 1.0 doesn't have all this baggage to carry around.

In fact, I think I'll just over-generalize and say it like this:  The older your product is, the slower your development is.

Example

The most obvious example of this phenomenon is Microsoft Windows.  How many times has Cairo/Longhorn been delayed?

Remember, this is not a criticism -- it is merely a natural part of the aging process for software products.  Each release of Windows takes a long time, and I bet that a big percentage of the effort is spent on backwards compatibility and regression testing.  A huge number of applications rely on the Windows platform, and Microsoft needs to be sure that old apps work with its new releases.  In other words, they are trying to improve Windows without changing it.  That needs to be done with a lot of care.

Don't take this too far

The day after I publish this article, some yoyo is going to send me email flaming me for saying that it's bad to be the market leader.  Please don't bother.  I'm not really saying that.  Given a choice between being two years ahead of a competitor or two years behind, we all know which choice to make.

I'm just saying that not every factor favors the leader.  If you are out in front, be aware of the natural reasons why your development is slowing down.  If you are trailing, don't despair.  Realize that there are certain issues working in your favor.

The 100 meter dash

The game

Wait at the starting line.  When the gun fires, run toward the finish line, 100 meters away.

The principle

Strictly speaking, only one person actually wins this race.  However, second and third place are honored with medals as well.  The silver and bronze medalists are obviously among the fastest human beings on earth.  They didn't "win" the race, and yet, they achieved something amazing.

How software is similar

There is usually more than one winner.  In fact, I'd say that most market segments work out to be very much like the Olympics:  The top three players are all considered successful.  The game of running an ISV is not a two-player affair with a winner and a loser.  You can be quite successful without being the market leader.

Example

Lots of successful products are not #1 in their market:

Don't take this too far

Every rule has exceptions.  The number three player in desktop operating systems is probably not considered very successful, whoever they are.

Golf:  The Putting Green

The game

Golf is played with a club and a ball.  The object is to get the ball into a hole by hitting it as few times as possible.

In the final step of playing a golf hole, we roll the ball along a surface of very short grass into the cup.  This surface is called the "putting green".  It is rarely flat or level.

The principle

The tricky thing about putting is studying the green to figure out how the ball will roll.  When putting across a slope, how much will the grade cause the path of the ball to curve?  When putting down a slope, how hard should you strike the ball to avoid rolling too far if you miss?  Using nothing more than visual inspection, it can be really tough to figure this stuff out.  Professionals have spent countless hours learning how to "read the green".

Making a putt is far simpler if you can watch somebody else attempt it first.  This is completely legal within the rules of golf.  The person whose ball is further away from the cup must attempt the putt first.  The other player has the right to watch the ball roll.  Putting second can be a big advantage.  You can learn a great deal by watching your competitor go first.

How software is similar

Using nothing more than visual inspection (market research), it can be really tough to figure out just how a product is going to roll.  Very few products get it right the first time. 

Hindsight makes all this stuff obvious.  Releasing your product second can be a big advantage.  You can learn a great deal by watching your competitor go first.  We call this effect the "second mover advantage".

Example

C# is probably the most perfect example of second mover advantage that I have ever seen.  Microsoft is always very careful when they talk about C#.  They don't want people thinking of C# as a clone of Java.  But the truth is obvious:  C# is Java done right.

Don't take this too far

The reason we call this "second mover advantage" is because presenting it in contrast with the more commonly discussed "first mover advantage", which is very real.  Being first has plenty of benefits too.  It's just that the benefits of being first are different from the benefits of being second.

Bridge

The game

Bridge is a card game played by four players with a traditional 52-card deck.  In each deal there are 13 tricks.  The goal is take lots of them. 

The principle

The basic rules of bridge are very simple, but competitive bridge is extremely complex.  Bridge players use a "system", a methodology which provides strategy and tactics for play.  The system is not part of the basic rules of the game.  There are quite a few different methodologies for bridge, all of which are designed to help a player and his partner win.

A friend of mine taught me to play bridge.  Let's call him Bob (because that's his name).  Bob is a very good bridge player.  One might think that because I was taught by such a strong player that I might be rather good at the game.  Nothing could be further from the truth.  I am a terrible bridge player.  There are many things about bridge which are not easily taught.  You either "get it" or you don't.

Bob gets it.  He sees things at the bridge table that I just can't see.  He always seems to know where the cards are.  He and I will sit down for an evening and play 27 hands of bridge.  After it's all done, he draws my attention to the 5th hand.  I barely recall playing it, but he remembers all 13 of the cards I was holding and tells me exactly where I screwed up.

There is one fact about the remainder of my lifetime that is extremely clear:  I will never beat Bob at a game of bridge.  I simply don't have the talent.  Bob's mind can do things mine cannot.

More to the point, there is no system or methodology which would allow me to beat Bob.  I only know how to play one bridge system (it's called Standard American).  Bob plays several different systems, depending on who his partner is.  He usually wins, regardless of what system he is playing.  In bridge, there is no methodology which is a substitute for talent.

How software is similar

I used to work with a guy who was in love with the notion of a really good methodology.  He was always talking about how great it is to have a system which is not dependent on the abilities of the people on the team.  He liked to explain the concept using a sausage grinder as a metaphor.  No matter how smart or dumb the developers are, you always get sausage as the result.

Methodology of software development is a popular topic, but count me as a skeptic.  In software, there is no methodology which is a substitute for talent.

Choosing the right development methodology is not going to help you beat your competitors.  None of your competitors are going to beat you just because of the methodology they chose.

Example

I can't find an example to give here, except to offer the following observations as weak evidence of my claims:  I've spoken with folks at lots and lots of ISVs.  I tend to see smart people following excellent development practices.  But I don't know of a single shrinkwrap software company which follows one of the strict development methodologies, much less one that gains competitive advantage by doing so.

Don't take this too far

I'm not saying that methodology is a completely uninteresting topic.  I'm saying is that talent will beat methodology every time, but methodology and talent don't have to be mutually exclusive.  Some methodologies seem to be specifically designed to let smart people be smart.

Gymnastics

The game

Gymnastics is a sport in which athletes demonstrate strength, agility and balance in several different events using several different kinds of equipment.

The principle

Most people watch gymnastics every four years when the Olympics come on TV.  Both women and men participate in the sport (separately), but the women's competition seems to be generally more popular.

Women's gymnastics involves four different events:

Participants must compete in all four stages of the competition, and each stage is very different from the others.  A gymnast might be truly gifted on the balance beam, but that doesn't mean she's any good on the uneven bars -- the two events require entirely different sets of skills.  Each of the four events requires a different approach and different training.

How software is similar

Marketing teaches us that the life cycle of a product has four stages, each of which corresponds to one group of people in the market:

Each stage is very different from the others.  Your ISV might be very successful selling products to Early Adopters, but that doesn't mean you will have any success at all selling stuff to the Pragmatists.  These are two entirely different groups of customers and reaching them requires entirely different skills.

Example

Linux is perhaps the most obvious example today of a product which is very popular with certain Early Adopters and almost completely irrelevant to the Pragmatists.  That is not to say that Linux is a failure.  I like Linux very much and I use it regularly.  But the fact remains:  Linux doesn't have much market penetration in the mainstrain markets like the corporate desktop or the home PC.  Those buyers are Pragmatists, or Conservatives or even Laggards.  Being successful with the Early Adopters is one thing.  Selling products to the later stages is a completely different problem.

Don't take this too far

Unlike gymnastics, an ISV is not absolutely required to participate in all four stages.  Some companies cater exclusively to Early Adopters, never bothering to even try and sell stuff to the Pragmatists.  An even more common strategy is to only sell stuff to the Pragmatists and Conservatives, sparing yourself from exposure to the bizarre buying patterns of the Early Adopters.

Football

The game

Here in the United States, the sport we call "football" is played on a grass field 100 yards long.  Each team has 11 people.  At any given moment, one team is trying to move the ball to the end of the field while the other team is trying to stop them.  A complex set of rules attempts to regulate the amount of violence and keep it at just the right level.

The principle

Football is a game of strategy.  You can't just grab the ball and throw it down the field.  Each team develops "plays" where every player on the field is given very specific instructions.  During the week, they practice these plays over and over until the team knows how to do it right.

Then the weekend comes, and it's time to actually play the game.  In every football game, there is a play where the coach chose the right strategy but the players just didn't get it done.  Somebody was supposed to run to the left and instead they ran to the right.  This is the moment where the TV cameras zoom in on the coach as he throws up his hands in frustration and screams a word I won't repeat but which can be roughly translated to say: "That is NOT how we practiced that play!!!"

Football is a game of strategy, but even more, it is a game of execution.  The best strategy won't help you a bit if you can't execute it well.

How software is similar

The challenge of building and selling a software product is a game of strategy, but even more, it is a game of execution.

Most people get this balance exactly backwards.  They believe the essence of success is to come up with a really great business plan built on a really great product idea.

Those things are important, but a great idea and a great plan won't help a bit if you can't execute it well.  Experienced people know that execution is more important than idea.  In fact, the more jaded and cynical folks in our industry would say that software product ideas are worthless.  Without a doubt, great execution on a good idea is far better than poor execution on a great idea.

If you want to beat your competitors in the market, focus on being a team that can get things done.

Example

Back in 1997, folks were anticipating the upcoming release of the Motorola MAP phone, a "smart phone" which incorporated web browsing and a graphical user interface.  By today's standards, I suppose the MAP phone would be rather ordinary, but it was a cool idea for its time.

Or rather, it would have been a cool idea if they had ever delivered it.  Some Motorola exec killed the project, in early 1999 if I recall correctly.  The phone was years late, and its feature set was no longer worth delivering.  Competitors already had products on the market with the same or greater functionality. 

What went wrong?  In a nutshell, there was a lot of questionable execution, including some major changes to the architecture and feature set, very late in the game.

My company was one of the subcontractors building apps for the phone.  Our billings to Motorola were a significant amount of money, so I can only imagine the total sunk cost in this disastrous project was at least an 8-figure number.  Too bad.  It was a great idea. 

Don't take this too far

Here's a football play I've never seen:  Give the ball to one player and have the other ten stand around and watch as he slowly walks down the field. 

Perfect execution on a terrible idea will get you exactly the results you should expect.

The Oscars

The game

The Academy Awards (aka the "Oscars") are generally considered to be the most prestigious honor in filmmaking.

The principle

Every year, immediately after the Oscar winners are announced, people begin the debate:  Who should have won?

The Academy Awards aren't like horse racing or chess where the winner is usually quite clear and undisputed.  The decisions about Oscar winners are entirely subjective.  Reasonable people disagree.  With all due respect to Ben Kingsley and his performance in Gandhi, I still wish Dustin Hoffman had won.

But that's just the way the Oscars work.  The Academy voters hold the only opinion that matters.  The rest of us can argue over which movie or performance we think was the "best", but our opinions don't make a bit of difference in who actually wins. 

How software is similar

The "best" product doesn't always win.  That's a pithy way to express the point, so let me try to be a bit more precise.

There are two groups of people who have opinions about which software product is the "best":

Here's the lesson that developers must learn:  The customers hold the only opinion that matters.  Sometimes their choices don't seem to make any sense.  They prefer one product when we know the other one has better technology.

In the end, we can fuss all day about why the market is making "the wrong choice", but it doesn't matter.  Our job is not to make the product that we think is best.  Our job is to make the product that they think is best.  If you can't accept that, you should consider the possibility that you and your career choice are not as well suited as you thought.

Example

Strictly from a technology perspective, it wasn't terribly difficult to figure who had the best personal computer operating system in 1985.  Most people would probably have said that the Amiga operating system was clearly superior to Windows 1.0. 

Twenty years later, the score of this game looks roughly like this:

The "best" product doesn't always win.

Don't take this too far

Your notion of what is the "best" product may not completely match the opinion of the marketplace, but it's probably not 100% wrong.  I don't think I have ever seen the Academy give an Oscar to a performance which  was also nominated for the Razzies.

Rugby

The game

Most people in the United States are not terribly familiar with rugby.  It could be compared to football, but it is a sport all its own.  Like football, it involves lots of players running into each other.  Unlike football, the players aren't wearing pads.

The principle

Traditional Rugby is played with 15 people on each team.  At the time of this writing, the top three international rugby teams are New Zealand, Australia and South Africa.  My rugby fanatic coworker tells me that this configuration is typical.

Noticeably absent from this list is Fiji, a small island nation in the south Pacific.  Fiji is about the size of New Jersey but has about one tenth the population.  Rugby is the most popular sport in Fiji, but this tiny country simply doesn't have the resources to compete with the big boys.  The Fijan rugby team competes, but don't look for them to be in the top three anytime soon.

However, there is a variant of rugby which is played with 7 people instead of 15.  The game is called "Rugby Sevens".  It's not as big as traditional rugby, but its popularity is growing.  Guess who won the Rugby Sevens World Cub this year?  Fiji.

Rugby is segmented into two different categories.  Fiji puts most of its resources into competing where it has the best chance to win.

How software is similar

Segmentation is perhaps the most important concept in marketing, and the world of software products is no exception.  Very often, the way to win is not to be better, but to be different.  Look at your market and identify the different segments or categories.  For each category, ask yourself lots of questions:

Choose a category where you can win.

Example

I think the best example here is the Apple Macintosh.  Steve Jobs is very smart.  He could have killed the company by trying to beat Microsoft in the broader market.  Instead, the Macintosh seems to have found serenity by dominating a small niche of rabid fans.

Don't take this too far

Choosing a category where you can win is not the same thing as a creating a whole new category.  Which of the following tasks sounds easier?

Sound absurd?  At this very moment, somewhere in the world, there is a person writing a business plan which is just as silly.  If by chance you are that person, please stop now.  Creating a new market category is very, very hard.  It is much easier to sell people a product which solves a problem they already know about.

Golf:  The Tee Shot

The game

Earlier I mentioned golf in the context of the putting green.  But that's the end of the story.  Long before the ball lands on the green, each hole starts out with the ball sitting on a tee.

The principle

The fourth hole at my local course is reasonably typical.  When I begin to play this hole, my ball is 561 yards away from the cup where it is supposed to end up.  The par for this hole would suggest that I should be able to get the ball into that cup by hitting it only 5 times.  My last two shots will be far more precise, so what I need from this first shot is distance.  It would be great if I could get the ball around halfway there on the first shot.

This should be easy.  It's not like the ball is moving.  It's just sitting there waiting for me to smack it.  All I have to do is swing my club and hit the darn ball straight.

Unfortunately, it turns out that this task is incredibly difficult to do with any accuracy.  The slightest error will be magnified, usually causing my ball to veer off to the right where it will be reunited with dozens of its friends which are now resting comfortably at the bottom of the lake.

The tee shot in golf is all about concentration.  This is a mental challenge, not a physical one.  There are plenty of teenage girls and 75-year-old men who can hit the ball 300 yards.  Muscles don't matter.  What you need is 100% focus and absolute concentration on the task.

The easiest and most common way to dilute your concentration is to think about your competitor.  During your shot, that guy just doesn't matter.  It's not like he's playing defense.  The best thing to do is to just ignore him completely.  If you think about him, then you're not thinking about your shot, and you're probably going to screw it up.  It's just you, the club and the ball.  Everything else is a distraction.

How software is similar

I'm ending the article with this illustration because I believe that managing an ISV is more like the golf tee shot than it is like any other game.  It's just you, the product, and the customer.  Everything else is a distraction.

Software companies routinely spend far too much of their attention on their competitors.  Our customers wish we would spend all that effort on providing solutions to their problems.

Example

I'm citing Fog Creek as my example here.  I suspect that I could find a hundred different bug-tracking products which appeared on the scene before FogBugz, but Joel ignored all that and kept spouting his mantra:  "Listen to your customers, not your competitors!"  He has built himself a very fine company, and along the way, the rest of us have learned an awful lot of good stuff from his writings.

Don't take this too far

It is theoretically possible to take this principle too far, but I've never seen anyone do it.  Ignoring our competitors takes discipline.  Human nature virtually guarantees that we will err in the other direction.

If you have achieved this particular flaw, spending so much time focusing on your customers that your business is actually harmed because of your ignorance of the competition, please accept my congratulations.  Most of my readers wish their problems were as easy to fix as yours.

The 19th Hole

This article ended up a lot longer than I thought it would be.  If you got tired while reading it, just be thankful that I deleted the whole section about how seeing into the future is like trying to look down a dark hallway in Doom 3.  Be happy that I never wrote the whole bit about how Lotus 1-2-3 ignored Wayne Gretzsky's sage advice about skating to where the puck will be.  And most of all, be grateful that I deleted the long rant about offshore outsourcing, the New York Yankees and the Chicago Cubs.  :-)

Copyright 2001-2023 Eric Sink. All Rights Reserved

If you are in need of contract software development services, I would appreciate your consideration of SourceGear.