A Simple Matter of Software

Clinton, Machiavelli and the challenge of change

"It must be considered that there is nothing more difficult to carry out ... than to initiate a new order of things.  For the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who could profit by the new order, this lukewarmness arriving partly from fear of their adversaries ... and partly from the incredulity of mankind, who do not truly believe in anything new until they have had an actual experience of it."
                                                                     - Machiavelli writing in "The Prince"

A favorite quote of former President Clinton. 

 

Fractal Geometry and Market Analysis

This post on "What is Marketing" got me started thinking about markets and common mistakes by entrepreneur's.

In a software venture it is very common to talk about "the market".  As in:

• No point entering such a well established market
• This is an early stage market
• We can have first-mover advantage in that market
• That market is not big enough for us
• This market is growing at 20% a year
• 40% of the customers in this market are actively looking for alternative solutions
• We are the clear leader in our market
• etc. etc. etc.

These statements are treated as absolute truths, when in reality their truth or falsehood is completely dependent on how you define the boundaries of "the market".

Often in these discussions my mind drifts to comparing fractal geometry and market analysis.  They are pretty different disciplines, but they do have one important trait in common.

A definition of fractals including some gorgeous pictures can be found here.  In brief, a fractal is a geometric shape.  Such as this one:

One of defining characteristics of a fractal is self-similarity.  Meaning that as you zoom-in and zoom-out you can see the same pattern repeated at different levels of granularity.

Fractals occur in nature as well.  For example the coastline of a continent has various bays, points, deltas, inlets, etc.  Then if you look at the coastline of one of those bays, you will see more bays, points, deltas, inlets, etc. just at a smaller scale.  And so on.

Markets do not normally form fractal patterns.  As you look at a product's market at different levels of granularity you may see very different patterns with each analysis. 

However, markets and fractals are similar in one important way.  In both cases doing your analysis once from one point of view is not enough!  In thinking about the market for your software venture you must look at the market patterns from many different points of view.  Until you do this you won't know what you have got.

For example, lets say you have a great idea for a massively multi-player (MMP) real-time strategy (RTS) game that is set in Europe in WWII.  Well what is the market that you should analyze when making your business plan and when deciding who is your target user?

1. market for European Theater WWII RTS MMPs
2. market for WWII RTS MMPS
3. market for RTS MMPs
4. market for combat MMPs (including both RTS and first person shooter)
5. market for all MMPs
6. market for all computer games

It is easy to see that your business and usability analysis will be drastically different depending which of these target markets you chose as the basis for your analysis. 

The above is an example of different ways to slice the market based on changing scale (as you would in looking at a fractal).  However, there are plenty of other ways to slice and dice markets beyond fractal-style scale changes.  The key lesson from fractals is not that scale rules all. Rather the lesson is that doing your analysis just once with one set of assumptions is not enough to answer your questions and tell you what you are looking at.

However, it is important that you don't get bogged down in analysis paralysis by trying to analyze every possible market definition. You should do more than one, but you should not do them all.

A good quick way to find what market definitions are most interesting is to do the following:

• Pick 3 to 5 comparable products
  Make these products as diverse from one another as possible, while still having at least one key trait in common with your product.  So in our example above you might pick: a non-MMP WWII RTS game; an MMP first-person combat game; and an MMP non-combat game as you comps.
     
• Find customers
  Find a half-dozen to a dozen people who have recently bought examples of each product
        
• Identify alternatives
  Ask each of those purchasers "when you were buying this product, what alternatives did you consider?  In other words if you had not spent the money to buy XXX what would you have spent that money on instead?"  In some cases you will get an answer like "I would have spent more money on my Mom's birthday present." which is not too useful.  But in other cases you will get very useful answers such as "I gave up my Everquest subscription so I could spend the money on World of Warcraft"  or "Well if I wasn't paying for World of Warcraft every month I would probably get the latest expansion pack for Age of Empires."

The point here is that what really makes the "interesting" market definitions is the customers' opinion about spending trade-offs.   If the customer has a certain amount of money set aside for monthly MMP fees, then the market is for MMPs.  If the customer has a certain amount to spend on all computer games, than that is the interesting market definition as they are making trade-offs among those choices.  If the customer is really making an impulse purchase without considering trade-offs than that is also interesting data, at minimum it will impact your pricing , advertising and distribution schemes.

The above mechanism for picking a market definition is not the right one for all circumstances.  So if you have a better approach use it.   The key thing is to use some kind of analytical approach that will encourage you to be open-minded to new data and new conclusions.  Too often market analysis is an exercise in reaffirming your existing opinions through careful selection of target market and relevant data.  Try your best to avoid this sort of wish-based planning.

Previous posts talked about the dangers of picking the wrong market, what gets in the way of listening to the customer, and how to deal with an unpleasant truth when you discover it.

                                                                                 copyright 2007 Kerry Champion

When to fire a customer

The Welch Way column in Business Week tackled the interesting question of when should you fire a customer.  One of their three scenarios is particularly relevant to the software venture:

".. when a customer demands a one-off product that sends your R&D group in the wrong direction, away from your own strategy and financial goals.  Again, this is a case where your salespeople might be hollering for support but where the long-term diversion of resources is a killer.  Unless it is an exceedingly profitable customer, you have to just say no."

New software ventures must be flexible and listen carefully to their prospective users.  They also must have a clear model of what they are trying to build, how they will earn a profit and who are their target customers.   You most recognize that not every prospective customer fits within the model.  You need to proactively decide which customers will help drive you to where you want to be, and which will take you into a cul-de-sac.

The Welch's make an exception for "exceedingly profitable" customers.  Those are good exceptions to make, as real profits can feed your ability to build to your ultimate goal.  But it is important to make the distinction between "high revenue/commission" vs. "high profits".  When all expenses are truly taken to account, high revenue may not be high profit.  In general we tend to underestimate the cost of doing customer specific enhancements, so we need to be careful to get those estimates right.  From a short term revenue growth perspective it may feel good to do these high revenue no profit deals (especially if the revenue is front-loaded and the cost is back-loaded), but in the long run it is actually destructive to have a big chunk of revenue that drives an equally big chunk of expense that is spent on building something that is not your target product and does not have  repeatable sales model.

Just as important as the income statement costs, we need to understand the "opportunity cost".  If we are spending management and technical team time on something customer specific, that is time spent not pursuing your central value proposition.

Paying this opportunity cost can kill your ability to innovate and build real differentiation.  In economics there is the concept of "disposable income" meaning the income you have left over after the basics (taxes, rent, food) are paid, where you actually have a lot of latitude on how you spend that money.  You can imagine a similar concept in time management of "assignable time", meaning the time you have left over after doing all the "must do" tasks.  The mgmt/tech team at a software venture typically has very limited "assignable time", spending that time on customer specific distractions means you not spending it driving forward the differentiating innovation that will be the real basis of your long term success.

It is hard to strike the right balance: being flexible and really listening is critical; chasing every opportunity you see is destructive.  I have seen errors in both directions.  If you believe that the opinions around the conference table are more valuable then the opinions of your target customers, than you are almost certainly making the first sort of mistake.  If you never make the hard decision to walk away from a high revenue but distracting deal, than you are almost certainly making the second sort of mistake.

Previous posts have touched on related topics:  Lilliput vs Innovation, Local Optimization, and Finding The Defining Questions.

                                                                                 copyright 2007 Kerry Champion

Local optimization and global failure.

local optimum  definition:
1) A solution to a problem that is better than all other solutions that are slightly different, but worse than the global optimum.
2) We absolutely perfected what we were doing, only to discover that we should have been doing something different.

A recent New Yorker cartoon depicted two executives in the penthouse office of a business district tower, one said to the other "During my meteoric rise to the top, I failed to notice I was in the wrong building." This is a great example of the trap laid by local optimization.

Two common failure modes for mission critical software projects:

• Locally optimized to produce a solution that does not achieve our big audacious goal and does not provide the right answer to our defining questions.  But did cause us to feel good that we were "executing well".
• Go on a quest (unbounded by time or money) for the absolute global optimum among all the various local optimums.  Makes us feel good about our "commitment to excellence" but causes us to not actually deliver anything.

How to avoid these failures:

• Have a clear sense of what your audacious goal is and what defining questions need to be answered to get to that goal.
• Pick the first locally optimal solution that achieves the goal and answers the questions.  Once you find such a local optimum point don't continue searching for an alternative local optimum point that might be even better.

Finding the best path to delivering a software project is similar to picking a spouse:

• Once you find a significant other who you can find a lifetime of happiness with, marry them immediately.  Don't tell them "Well I love you, but would it be OK if I dated a couple of others before we marry just in case I can find someone even better?"
• Similarly if your current significant other doesn't fire your jets, then don't marry them no matter what, even if you have been looking for a while.

Translating that to the software world:

• Once you have a clear path to drive down to get your project to its audacious goals.  Then start pushing it down that path, don't look for an even better one.
• However, if good execution on the current path won't achieve your audacious goals, then you must step back and make fundamental changes.  Don't just reactively go through the process of local optimization, when that local optimization is not going to achieve what is required.

                                                                                 copyright 2007 Kerry Champion