A Simple Matter of Software

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

Make New Mistakes

There are some bits of wisdom that are so often repeated that we become desensitized to the need to take action based on that truth.

For example, we have all heard and agreed with some version of:

"Insanity is doing the same thing, over and over again, but expecting different results." - Rita Mae Brown

“Progress ... depends on retentiveness. Those who cannot remember the past are condemned to repeat it.” - George Santayana

"Always make new mistakes" - Esther Dyson

Yet it is common for software ventures to repeat the same mistakes made in the past.  Why is that?

I don't claim to know the full answer, but here are some contributing factors:

1) Reactive vs. Proactive mind-set

If you manage by waiting for bad things to happen and then reacting to them you are more likely to fall in the same bad patterns again and again.

If you manage by proactively defining and driving an agenda for change you are more likely to avoid old mistakes and discover new ones.

2) Deferred Gratification and Impulse Control

Organizations with poor impulse control tend to repeat the same mistakes again and again.  Software ventures that master the art of deferred gratification will have better long term results.

3) Wish-based Planning

You often see old mistakes repeated anew, when organizations make plans based on how they "wish" things were rather than based on a more realistic assessment.

Lots of examples of this sort of behavior in:

• assessing feedback from customers
• dealing with unpleasant truths
• assessing how feature commitments will impact your ability to innovate
• defining your market
• deciding how to throttle your spending plan
• etc. etc.
  

4) Urgent vs. Important

Organizations that only react to the urgent and never focus on the important, tend let avoidable mistakes occur and than run a fire-drill to respond to them. They then repeat the process again and again.

It is critical that you know how to distinguish urgent from important and why that matters.

5) Low Investment in Lessons Learned Exercises

One important activity that is often pushed aside in favor of more urgent ones, is the "lesson learned exercise."  This goes by different names in different organizations:  "after action report", "debriefing", and "postmortem" (my least favorite term).  In all cases it involves a conscious systematic process to look at what as been going well, what has been going badly, and how the team can learn and improve.

Investing in a "lessons learned" process will decrease the chance of repeating old mistakes.

6) Split Incentives

If different parts of the organization have different incentives and priorities you can easily create situations where specific individuals are motivated to lead the team into making the same mistake again and again.

If you build an engineering team that is motivated by a desire to "build frameworks" and you don't clearly communicate the organizational imperatives that might motivate them to "buy the framework and build a solution on top" than you will repeatedly err on the side of investing too much in building frameworks and not enough in building solutions.

If you have a sales team where there cash compensation is based 100% on "signing new contracts" and 0% on "keeping customers happy through deployment and use", than you will consistently make mistakes around over-committing and under-executing.

In both the above examples the motivations of parts of the team are out of alignment with the organization as a whole.

   

                                                                                 copyright 2007 Kerry Champion

Groupthink and Software Design

"Groupthink may cause groups to make hasty, irrational decisions, where individual doubts are set aside, for fear of upsetting the group'€™s balance. The term is usually used as a derogatory term after the results of a bad decision."   - Wikipedia

Irving Janis created the original definition of groupthink.

More than once I've seen a team working extremely hard on a year long effort to implement a software design, where the software design was fundamentally flawed, with no one on the team actively questioning the assumptions in the design.  I believe that groupthink is often a root cause of this type of failure.

Here are common behaviors I have observed that lead into the groupthink trap:

1. Individuals high in the hierarchy (formal or informal) express an opinion when the task is first assigned to a group.  This creates a prepackaged answer before you even start. 
2. Rationalization is tolerated in the culture.  Team members assume that it's invariant human nature, and don't bother correcting it when they see it.
3. Don't consult with trusted experts from outside of the group.  Avoid technical and customer advisory boards.
4. Never request that knowledgeable insiders act as "devil's advocate"
5. The common attitude is "we don't have time to think about it lets just do it."
6. There is no distinction made between critical defining decisions and trivial decisions, both are given the same level of scrutiny.  This leads to minimal scrutiny for all decisions.
7. Fall in love with your own ideas.  Don't bother building into the culture a distrust of NIH.
8. Don't bother keeping a lookout for "early latching."  When searching for an answer humans tend to latch on to the first reasonable answer (using a low barrier of acceptance) and then use a much higher standard when considering other possible answers in comparison to this initial answer.  Don't bother looking for this pattern.
9. Focus your energy driving local optimization based on unquestioned assumptions.

Sloppy professional habits and a normal desire for group harmony are common drivers of these behaviors.  However another common driver in software ventures is the natural desire to deliver quicker and deliver more. 

Delivering the wrong thing fast isn't what creates a success.  Having a team that lives in perfect harmony in their comfort zone isn't what creates a success.  Success comes from building a culture that rejects both groupthink and analysis paralysis.  


                                                                                copyright 2007 Kerry Champion

 

Cover-up and crime

In Washington there's a bit of conventional wisdom that says "it's the cover-up and not the crime that causes the most damage."  If our Attorney General is forced to resign he will be the most recent example of this maxim.  It was not firing a couple US Attorneys that caused the most controversy it was the subsequent misleading of Congress that really got him into hot water.  Watergate and the Clinton impeachment were other examples of this pattern in action.

The same rule applies when managing a software venture.  Everyone makes mistakes and  encounters setbacks.  The trick is to acknowledge those errors, take responsibility for them and learn from them.  Having done that you can move on. 

What really causes long-term damage is when you try to convince yourself and others that there was no error.  In this case there is no basis to justify needed corrective action.  There is no lesson learned to avoid similar mistakes in the future.  And as the eventual results of the original error become visible your credibility is steadily undermined.

                                                                                 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

Rationalizing Creatures

Good post by Justine Davies titled Talk To Me In Numbers on data driven management.  One comment that struck me was "A person can provide any number of reasons, incredibly well argued, as to why their sales performance is off."  It is true people are rationalizing creatures by their nature. 

Here is an interesting paper that touches on the neuroscience behind why we take so naturally to rationalization.

"many times we give 'rational' explanations to our "irrational behaviors', even knowing that we are betraying ourselves"

"In a well-known experiment, a group of women have to chose some nylon tights.  Once they were asked about their elections, they gave detailed, careful, and sensible explanations related to the differences in color, texture, or the quality of the material, without taking into account that the tights were identical.  The reasons for choosing them in fact were rationalized explanations built to explain an emotional behavior, that has no rational explanation"

The paper discuss that this tendency to rationalize may be driven by the division of labor between the two hemispheres of the brain.  The logical half of the brain gets in the habit of unconsciously building verbal explanations to explain the impulsive, reactive, emotional behavior of the other half.  That sounds plausible to me.  But as a practical matter how to effectively deal with this behavior is more important than the biological basis for it.

My experience is that from day-one you need to build a culture and set of practices that is data-driven and that is prepared to deal with harsh truths when the become apparent. 

Justin's post seemed aimed more at sales results, but of course this tendency to rationalize away what you are seeing comes up in other customer interactions as well, and gets in the way of really hearing the customer.

                                                                                 copyright 2007 Kerry Champion

Gates to spending

Another great post from Scott Maxwell, this time on common ways that startups burn money without creating value.  All his points are right on the mark.

Beyond Scott's points, I strongly recommend using crisply defined "gates" as a way to pace your burn.

Ventures typically define their spending based on the calendar:

• hire the CMO in June
• have first 4 support engineers in place by September
• execute marketing launch and advertising campaign in October
• hire first sales rep for Atlanta office by August
• etc. etc.

I have found it works a lot better to schedule you spending not based on a date but based on an observable event, preferably an externally measurable event.

• hire 1st support engineer after we have XXX customers installed, hire 2nd after YYY customers installed, hire 3rd after ZZZ customers installed
• execute marketing launch after you have 3 reference users in place who are willing to talk publicly about their experience
• hire the VP of Marketing after your Dir of PM and Dir of Corp Mktg, are clearly maxed out and no longer able to get the near term job done on their own
• hire first sales rep for Atlanta office after at least 2 of your 3 existing reps have hit their full quotas for at least one quarter

Obviously the definition of the right gates will vary tremendously depending on the nature of your business, but the basic idea of using gates is applicable across all software ventures.

Taking this approach can seem like the harder path: 

• You have to think hard about what are the right metrics to justify taking each step in your business plan.
  
• You have to be constantly tracking your metrics to know when you should pull the trigger on each next step.
  
• If progress is not tracking to plan you can not hide behind a veneer of bustling activity and feel good reports.
  
• Sometimes you will find yourself beyond the curve on your hiring which  puts stress on the existing  team.

However while it may sometimes feel like the harder path, it is clearly the healthier path:

• You don't waste money (and dilute equity) by spending too early in the cycle
• Measuring metrics becomes are more integral part of how you manage the business
  
• You are encouraged to have a more open honest conversation with your employees and your board.  Which builds credibility with both.
  
• You avoid the stress that comes from over-staffing.  People want to contribute to the effort, if they are hired too early and there is not a productive way for them to contribute than they will rationalize themselves into doing "something" that makes them look useful.  That "something" is often counter-productive.

                                                                                 copyright 2007 Kerry Champion

What you want to see and what you need to see.

Scott Maxwell does an excellent job explaining the 10 best ways to lie with metrics.

Seth Godin recently posted on the disconnect between common metrics and what really matters.

Our previous post on how market definitions can be used to reaffirm existing biases is getting to a similar point.

Behind these cautionary tales the real issue is selectively using data to reinforce what you want to see.  Instead of using data to discover what you need to see.

Sometimes what you want to see is a specific conclusion, such as "yes it makes sense to inject another $10m into our current product focus, no changes needed there".

Sometimes what you want to see is a high degree of action and precision regardless of the conclusion:  "Look at all the metrics, look at the precise numbers, this is one organization that is really on top of things ... well no, we are not sure yet what action plan makes sense given these numbers ...".

In both cases you are missing the real goal: having a open minded data-driven process that sometimes leads you to surprising conclusions, but always leads you to decisive action.

                                                                                 copyright 2007 Kerry Champion

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

Not Seeing The Gorilla - User Requirements (part 1)

You might think that entrepreneurial software ventures are pretty much guaranteed to do a good job of listening to the customer.

You would be wrong.

Whether they are in a start-up or doing an innovative new project within a big company, folks working on software ventures are just as prone as anyone else to:

• Fall in love with their own ideas
  Something that welled up from the mists of their frontal lobe, is always more appealing than an idea that was tediously sifted from lots of conservations with strangers
   
  
• Fall in love with the early ideas
  When searching for an answer humans tend to latch on to the first reasonable answer (using a low barrier of acceptance) and then use a much higher standard when considering other possible answers in comparison to this initial answer.  Fondly known as "early latching syndrome", this may be a good thing in breast feeding, but not such a good thing in problem solving.
     
• See themselves as experts and users as uninformed.
  Folks in a software venture are way smarter than average and spend 100% of their time thinking about the issues around their target offering.  Users are average smarts and typically spend a tiny fraction of their attention around the issues associated with this offering. It is easy to assume the developer is right and the user is wrong.
     
• Assume that bad solutions mean an irrelevant problem
  What really matters is the users' (not the developers) definition of what is the real problem and what trade-offs are worth making.  However, users often (not always but often) are bad at proposing specific solutions (functionality, UI, architecture, etc.) to address those problems and implement those trade-offs.   Unfortunately once a developer hears a bad solution suggestion they often stop listening and don't bother to dig for the underlying problem the user is trying to address.  Finding the problem the developer might suggest an alternative solution that the user would love.
     
• Act as rationalizing machines
  What distinguishes humans from animals is not speech or tools, but our extraordinary ability to rationalize.  We are amazingly good at providing a rationale sounding analysis of a given set of observations, an analysis that just happens to support our pre-existing biases and assumptions.
     
• Suffer from situational blindness
  When stressed and really focused on a particular goal we can be blind to obvious facts present in front of us.  There is an fascinating experiment with two basketball teams and a gorilla, that illustrates this.  More relevantly I am sure we have all seen a more subtle form of this in software projects as well.
  

All of this gets in the way of really hearing the key messages from the prospective users.

I suspect we have all seen software ventures that have:

• Made it more complex than the customer wants and undervalued the power of simplicity
• Failed to tie technical innovations to customer valued differentiations
• Targeted the wrong customer for their offering
• Made bad assumptions on the rate of adoption
• Spent time and money on development efforts that were irrelevant to the user
• Suffered from NIH syndrome, when user preferences would have driven them to leverage existing technologies

All of these issues (and more) can be alleviated through a real commitment to understanding the user and finding the key messages.

Most of the time I believe the needed data is readily available through some basic legwork.  The real issue is overcoming our biases and wishful thinking. 

As in the situational blindness experiment, that gorilla is right there in front of us.  We just have to break out of our stress induced tunnel vision and apply the needed judgment and perspective.  Then we will see it.

Later posts will further explore how to capture user requirements.

Previous posts talked about when not to listen to the customer (here and here), how to deal with an unpleasant truth when you discover it, and the dangers of doing the right things (such as careful user analysis) to solve the wrong problem.

 

                                                                                 copyright 2007 Kerry Champion