A Simple Matter of Software

Setbacks and Success

“Success is not final, failure is not fatal,
it is the courage to continue that counts.”
                                      - Winston Churchill

There are some typical software venture dysfunctions that come from assuming that success is final and failure is fatal. 

The success delusion tempts you into sticking with what worked last year instead of focusing on what needs to change to succeed this year.  In the famous words of Andy Grove "only the paranoid survive" and success unfortunately drives out paranoia.

Failure tempts you into abandoning a direction that could succeed with an appropriate and active course correction.

Simplify to find the essence

"Our lives are frittered away by detail; simplify, simplify."
                                                              — Henry David Thoreau

Your mission should you choose to accept it

How a great communicator defines a big audacious goal:

We will "put a man on the moon and return him safely by the end of the decade."
                                                                    - John F. Kennedy

How the typical business executive would define the same goal:

"Our mission is to become the international leader in the space industry through maximum team-centered innovation and strategically targeted aerospace initiatives."

Thanks to Made to Stick for creating this example.

Too many software ventures have mission statements that sound like the latter.  Don't try to define your mission so it covers all the bases and supports every contingency.  Instead focus on defining your mission in terms that are simple, concrete, and emotionally compelling.

Traditional Management vs Venture Management

1000ventures.com has an interesting comparison of traditional management vs. venture management.  I don't agree with all their points, but it is worth a look.  Here are some of their main ideas (somewhat modified):

Building Business Around
    TM: Competence-driven idea
    VM: Opportunities: customer-driven idea or a new technology

Market Focus
    TM: Serving established customers
    VM: Entering emerging market that has yet to be recognized and exploited

Results
    TM: Quite predictable
    VM: Quite unpredictable

Time-to-Market
    TM: Willingness to sacrifice speed for thoroughness of analysis
    VM: Speed is critical, get ideas to market to test in real world

Success Measure
    TM: Earnings
    VM: Market capitalization

Market Research
    TM: Analysis, review, methodical consideration of facts.
    VM: "Living the data", agility, experimentation, adaptation, and rapid response

Management Attitude
    TM: Dedicated to delivering an operating plan
    VM: Dedicated to identifying and adapting to unmet, unserved customer needs

Risk Management
    TM: Reason, caution, predictability, avoiding failure at almost any cost
    VM: Experimenting, adapting, failing, and experimenting again

Financial Focus
    TM: Profit
    VM: Cash flow

Robust KISS

My father would remind me to KISS - Keep It Simple Stupid!

This often came up after I did something that wasn't simple but was stupid.

Dilbert's 9 rules for financial planning provide a great example of the KISS principle.

1. Make a will.
2. Pay off your credit cards.
3. Get term life insurance if you have a family to support.
4. Fund your 401(k) to the maximum.
5. Fund your IRA to the maximum.
6. Buy a house if you want to live in a house and you can afford it.
7. Put six months’ expenses in a money market fund.
8. Take whatever money is left over and invest 70% in a stock index fund and 30% in a bond fund through any discount broker and never touch it until retirement.
9. If any of this confuses you, or you have something special going on (retirement, college planning, tax issues) hire a fee-based financial planner, not one who charges a percentage of your portfolio.
   From Dilbert and the Way of the Weasel

These are simple rules that provide excellent guidance in a very complex field.

For 95% of the people in the country following these rules would improve their personal finances and would save in aggregate $100 of billions.   

These rules may be the optimum strategy for only a fraction of us.  I don't claim they are optimal for 95%.  My claim is that for 95% of the population these rules will provide a better outcome compared to what they are actually doing today.

What lessons can we take from Dilbert's financial advice that will apply to growing a software venture?

A-list software ventures tend to be populated with smart driven type-A personalities.  Who are capable of dealing with a  high degree of complexity and who like to demonstrate that ability.  People who often are more skilled at coming up with clever insights than they are at communicating simple actionable ideas.  Many of these folks tend towards a paradoxical combination of perfectionism and a fire-fighting mentality.   Which in turn leads to strategies/policies/plans that are either

    A) truly baroque and complex in an effort to create fine-tuned optimization
    OR
    B) non-existent - replaced instead by reactive ad hoc  behavior

With this context I see 3 key lessons from Dilbert's fine example of KISS in action.

1) Simple is better than none

Most people don't have a financial plan of any kind.  Clearly following Dilbert's simple rules would make them much better off, even if it does not provide the best of all possible worlds.

Similarly, it is incredibly common for fast-growing software ventures to live without clearly stated and widely understood strategies, policies, and plans. 

In some of these cases a few individuals have in their heads sophisticated ideas for how to address these needs.  Ideas that don't translate easily to simple declarative statements that get immediately written down.  The expectation seems to be that through example and osmosis these sophisticated ideas will transfer to the rest of the team.

In other cases, everyone is too busy reacting, firefighting, and addressing the 'obvious' urgent needs to bother writing down specific plans or practices.

In other cases, the desire to create a very elaborate and complete plan leads to  a long planning cycle, so that many such cycles are started but none are every completed before they are interrupted. This is one reason why striving for a truly complete specification can be the wrong thing to do a simple spec that is up to date and conveys critical info is better than striving for a 'complete' spec and in effect living with none.

In all cases, it would be better to write down, clearly communicate, and then consistently live by some simple plan than to live without any at all.

2) Communication and execution matter more than cleverness and optimization

When it comes to personal finance many people do too much rather than too little.  People tend to overestimate their ability to optimize their financial results through cleverness and activity.  They tend to underestimate the value of simplicity, consistency, and low-costs.  This is why almost everyone who actively trades stocks does worse than if they just paid credit cards and then invested in a cross section of index funds. 

Similarly at software ventures we tend to use our cleverness to try and get the best possible results through creation of a complicated plan.  We tend to underestimate the value of simplicity.  Simple plans are easier to communicate, easier to execute, and easier to adjust as you get new data. 

These benefits from simplicity apply both in business planning and to software design.  The most elegant technical improvements often come when we innovate via simplification.

One clever person with an intricate vision of how all the pieces fit together, isn't enough to make a team succeed. Coming up with a simple approach that can be effectively communicated to everyone is a mark of true understanding.   

As Pooh pointed out in the Tao of Pooh:

"Rabbit's clever," said Pooh thoughtfully.
"Yes,"said Piglet, "Rabbit's clever."
"And he has Brain."
"Yes," said Piglet, "Rabbit has Brain."
There was a long silence.
"I suppose," said Pooh, "that that's why he never understands anything."

Lots of folks at software ventures are like Rabbit.  They show off their cleverness with intricate plans that they never get everyone to understand and that are impossible for mere mortals to execute.  When what is really required to get an effective common understanding is simplicity.

3) Robustness matters

Of course not all simple plans are created equal.  Simple by itself does not guarantee success. The plan needs to be simple and effective.

One measure of effectiveness is robustness.  Wikipedia has a nice definition:

Robustness is the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance. A system, organism or design may be said to be "robust" if it is capable of coping well with variations (sometimes unpredictable variations) in its operating environment with minimal damage, alteration or loss of functionality.

Dilbert's financial plan seems robust to me and that is a very good thing.

Simplicity often improves robustness, as it is easier for a simple system to adapt to changing circumstances.

However, it is possible to go too far.  As we strive for simplicity in our software designs and business plans, we don't want to make a plan that will only work in our immediate circumstances.  We want to create something that is "as simple as possible but no simpler" and one good measure of that is the likely robustness of that plan in the face of a changing environment.

                                                                               copyright 2007 Kerry Champion

Existentialism, corporate strategy, and the trap of local optimization

Existentialism is one of those words that we all stumbled across at university and never really understood (unless you smoked and read Sartre in the original French).

Even though Existentialism often is an unknowable irrelevant philosophical debate, there are Existential concepts that apply to how  we create strategy in the business world.

For example, a basic Existential concept is that our nature and identity  are defined by the  choices we make.  The same is true for companies and development teams.  We either let things happen to us or we make things happen around us. 

To make things happen you have to make choices.  If you simply make a laundry list of "everything you might want to be, see, and have" then you probably are not creating a strategy that can be executed.   Most likely you are creating what in the short term is an unattainable plan.  This means that instead of making the choices that define who you are, you punt on making those decisions and leave it up to external forces, circumstance, and random chance to define you.  This is an  anti-Existential approach to life.

Sometimes the things that are happening to us are good things (revenues are growing, big customers/partners want our attention and want to influence what we do, etc.).  However, even when good things that are happening to us, we should not let them by default define our strategy, we should make a conscious decision about what our strategy is even if it temporarily takes us away from some of that positive feedback.  Those good things may be leading you to local optimum which is a far less attractive that the global optimum you could reach if you took charge of your own future. 

A New Yorker cartoon did a great job of defining the trap of the local optimum, it depicted two executives in the top floor of an office tower, one saying to the other "During my meteoric rise to the top, I failed to notice I was in the wrong building."

                                                                               copyright 2007 Kerry Champion

Leverage

To quickly generate dramatic growth in usage ventures need to use "leverage" to their advantage.

Marc Andreessen provided a simple definition of leverage, while discussing which businesses fit the "venture-backed startup model":

Startups that have a credible potential to be sold or go public for a 10x gain on invested capital within 4 to 6 years of the date of funding should consider raising venture capital.

Most other startups should not raise venture capital. This includes: ... startups where there's no inherent leverage in the business model that could result in a 10x gain in 4 to 6 years ...

Notably, there are many fine businesses in the world -- many of them highly profitable, and very satisfying to run -- that do not have leverage in their model that makes them suitable for venture capital investment.

By leverage in this context, I mean: the ability to make something once (a piece of software, a chip design, a web site) and sell it (directly or indirectly) to a lot of people (1,000 business customers or 10 million consumers) -- which leads to the classic "hockey stick" revenue projection.

While the above is acknowledged as true in the abstract, in practice actual startups often lose sight of this point and create patterns where there is not enough leverage.

Here is one typical software venture scenario:

• Start-up with no revenue and no market presence feels intense pressure to land some key large customers to establish their credibility and prove the value of their business proposition.
     
• Those initial large customers are hesitant to work with a small unproven company.  The start-up responds by saying "we may be small, but that is an advantage as we can be nimble and quickly deliver to you a product/service that exactly matches your specific individual requirements"
     
• This pitch succeeds and lands some important initial customers.  Because they see something working (after a long period of struggling) the sales team repeats the same pitch to other potential customers.
     
• Under pressure to move quickly the software team does not build a configurable platform but rather does customer-specific source modifications to the core product to deliver on what each customer expects.  Which leads to multiple source branches, high maintenance cost.  low ability to deploy new features across all customers, high incremental costs per each new customer, etc.

The above scenario is common and can lead directly to falling into a low leverage trap.

There are absolutely times when doing a low leverage special feature for a specific launch customer is the right thing to do.  The question is, do you want this to be a rare exception or is it a pattern you want to replicate?

Here are two models:

1. .“On-demand individualized customer service" model focused on directly  responding to unique needs of large customers, through a negotiated delivery plan.  “Professional services” companies such as IBM Global Services and Infosys fit this model.  As does a large part of the Defense industry: companies such as SAIC.
      
   
   B.
2. "Market service" model focused on executing roadmap that delivers high leverage: creating a single unified service/product that meets the needs of the broad market. Examples here include: eBay, Amazon, Google, Adobe, and Microsoft.

Successful businesses can be built using either model.  However, the "market service" model has higher leverage, higher valuations, and greater probability of leading to fundamental changes to how we work and live. 

If you have the opportunity to pursue this "market service" model you should clearly do so, even if it means extra effort and extra risk.

If your business does not lend itself to pursuing the "market service" model that is ok too, you can build a good business creating custom solutions for large customers.  However, that approach will mean slower growth than a successfull "market service" model and you need to make sure your team and investors understand that.

The one thing that absolutely does not work is to be mis-aligned:  you claim you are aimed at one of the models and some of your activities reflect that, but a large part of your actual behavior fits the other model the one you are not targeting.  This is a recipe for painful failure.

Committing to building a high leverage model takes real discipline: the engineering team has to avoid taking tempting (but non-scalable) shortcuts, the sales team will sometimes need to pass on a customer which goes against all instincts.  However, if you can recognize the difference between urgent and important, and instill that self-discipline you will be well rewarded.

                                                                               copyright 2007 Kerry Champion

Innovation: once is not enough

Here is an striking quote from the New Yorker ("The Typing Life" April 9, 2007):

... historians estimate that the typewriter was invented at least fifty-two times, as one tinkerer after another groped toward a usable design 

Highlighting one of the key usability issues the author, Joan Acocella, goes on to note:

... Until about the eighteen-thirties, all typewriters lacked a keyboard, and when they got one it was usually modeled on that of the piano.

Acocella points out that the first widely used model did not come onto the market till 1873.

Given that it was 1450 when Gutenberg got the whole movable type thing going in Europe, 1873 seems like a long time to wait to get a usable typewriter.

Three things came to mind as I read this article:

1) First is that usability matters.  It was not the case that the first fifty-one typewriters did not work, from the inventors point of view they "worked per the spec" and did what was intended.  Obviously working as designed is not enough, you must make your invention more inviting and usable in the context of the users existing experiences and expectations.

2) It is hard to predict how long innovation will take, but we can consciously become more effective innovators.  In 1878 if you had asked "so Mr Edison how long is it going to take you to invent the light bulb?"  what kind of answer do you think you would have gotten? 

It was not an unreasonable question, Edison was not doing some fundamental basic research.  The first incandescent light was invented 70 years earlier (using platinum filaments which were unfortunately not very cost effective.)  A lot of useful work had happened since then.  Edison himself had bought the patent rights to a carbon filament bulb as a starting point for his own work.  So given that he was doing an incremental improvement to a 70 year old body of research, you might think he could give you a schedule, wouldn't you? 

Of course in reality he could not give you an exact schedule.  What he could and did do, was use efficient techniques (good metrics and measurements, multiple simultaneous research paths, efficient organization of multiple researchers, good tracking of results) to make the innovation process better than it had been the past: faster, more focused on a practical result, more alternatives and fall-back options, with better reporting as he went.  Using these techniques his lab produced a usable result in less than two years, rather than spending another 70 on it.

3) Version 1.0 failing does not prove that you are pursuing the wrong opportunity.  The old saw about Microsoft is that for each product they finally got it right on version 3.0.  For the typewriter it was version 53.0 that finally got some real use. 

Someone else capturing the opportunity is a good reason to quit pursuing a particular innovation.   Another good reason to quit, would be gathering new evidence about  your users' needs that convinces you that you are building the wrong offering.   However, having your 1.0 version fail to fulfill your vision, is a bad reason whipsaw your team and fundamentally change your target.  Rather it is a good opportunity to learn from some real-world feedback and accelerate your efforts.

                                                                               copyright 2007 Kerry Champion

Don't leave the trail and fling off your clothes

Software ventures are by definition high-risk operations that will often experience set-backs and failures.  How you react will determine whether you enter a death spiral or power past failure to find real success.

I was reminded of this while reading Bill Bryson's "A Walk in the Woods", in particular his description of hikers struggling with hypothermia had a real resonance.  In his examples the death spiral involved actual not figurative deaths.

Popular impressions to the contrary, relatively few victims of hypothermia die in extreme conditions, stumbling through blizzards or fighting the bite of arctic winds ... [most] die in a much more dopey kind of way, in temperate seasons and with the air temperature nowhere near freezing.  Typically they are caught be an unforeseen change of conditions [for which they are unprepared] ... Nearly always, they compound the problem by doing something foolhardy - leaving a well-marked path in search of a shortcut ... fording streams that get them only wetter and colder.

Hypothermia is a gradual and insidious sort of trauma.  It overtakes you literally by degrees as  ... your natural responses grow sluggish and disordered ... [It leads to] desperate and irrational decisions ...

A person suffering hypothermia experiences several progressive stages ... profound weariness, heaviness of movement, a distorted sense of time and distance, and increasingly helpless confusion resulting in a tendency to make imprudent or illogical decisions and a failure to observe the obvious.  Gradually the sufferer grows thoroughly disoriented and subject to ... decidedly cruel misconceptions .. Many victims tear off clothing, fling away their gloves, or crawl out of their sleeping bags. 

Software ventures that experience some serious difficulty can fall into a similar pattern:

• Conditions prove to be different than you had assumed.  The scope of the problem is bigger, or the number of competitors is greater, or the receptiveness of the market is slower than you had hoped.
• You could use this information to make a one-time fundamental revision to your methods and goals.  However, you are so latched on to your current assumptions and commitments, that you can't bring yourself to make an fresh objective evaluation.
• You refuse to recognize that there is any fundamental barrier to achieving your existing plan.  You steadily warp how you define and report your metrics to support this position.  You develop  "a distorted sense of time and distance" and "a failure to observe the obvious".
• You assume that if everyone just works harder than anything is possible.  Ignoring how the resulting "profound weariness" effects everyone's judgment and perspective.
• Often that hard work is spent pushing down the wrong path.  You don't recognize that superhuman effort is no replacement for good judgment and correct direction.
• As "your natural responses grow sluggish and disordered" you make increasingly "desperate and irrational decisions".
• Finally your "misconceptions" lead to making "foolhardy" decisions and attempting muddleheaded "shortcuts" that actually take you further from your fundamental goal.  In effect you leave the trail and fling off your clothes.

The best way to handle changing conditions is an approach of:

1. proactively prepare for potential potholes
2. clear-headed measurement of current progress
3. decisive corrective action when needed

However, you don't want environmental changes to be used as an excuse to cover poor performance or a lack of commitment to deliver results.  Part of your role as a leader is to make sure that changes to a committed plan honestly are optimizations in the face of new information and not cover ups for sloppy work.

                                                                                 copyright 2007 Kerry Champion

At the start, what is more important than a business plan?

Rob Schultz has an excellent post on what are the key issues an early stage venture needs to focus on.

It is a common mistake to get so wrapped up in the mechanics of a business plan that you lose sight of more fundamental priorities (talk to users, make prototypes, envision specifics of how you will make money, etc.)   

Obviously you will need a formal business plan as you grow, but it can be a mistake to get too wrapped around the axle about it right at the start.

My take-away from Rob's post is that it is a good example of a more fundamental issue: "you need an attitude and practices that steer you away from wish-based planning and steer your towards practical reality checks".

Guy Kawasaki has a post on "Top Ten Lies of Entrepreneurs" that is done in a supportive way (he actually loves entrepreneurs) and highlights a different set of ways that new ventures can kid themselves (and their investors) with wish-based planning.

By the way, one comment in Rob's post that might be surprising but is certainly true is:

"I can't tell you how many plans or pitches I see where the entrepreneur has never spoken to the market they are trying to address.  What?!"

This post gives some more color on the particular issue of what gets in the way of hearing your customer.

                                                                                 copyright 2007 Kerry Champion