lynnfredricks.com

This article is under construction. Versions will appear on the regular blog until the article is finalized.

Letting your focus drift is as problematic a cause as it is an effect. It is easy to see the relationship between focus drift and delayed releases. As a Software CEO and vendor, your first priority is to ship product.

Focus Drift Vs Shipping Buggy Product

Don’t be quick to dismiss focus-drift as an argument for shipping buggy product. If you’ve done your homework you know exactly how your customer is going to use your software. If you have a critical bug (fails at the wrong time, corrupts data, makes the system fragile, etc) that directly impacts your target customer, you have a legitimate reason to delay. Delay to protect your key customer group from critical bugs is not drift, its survival. Here is a wonderful story from the trenches

A software company that built the first third party synchronization product for the PalmPilot (a calendar and address book application) for the Macintosh decided to save time and expense by accepting a crude port of synchronization libraries from the then owner of the PalmPilot. Now the typical customer had thousands of records in their calendar and addressbook database. This lousy port was so slow that the hardware would often time out before the database could finish synchronizing between the Pilot and the computer. Result? Massive record duplication or total database corruption in databases with more than 2,000 records. Each unit sold for USSRP $29, but each support call cost the company $25. A disaster that could have been averted if executives had been thinking about the key customer group!

Focus Drift - Who Does It

Lets look at three different types of CEOs and how they let their focus drift.

Lost in the Fun House - Engineer CEO

It is very easy to consciously or unconsciously place technological perfection on a pedestal, especially early on in a project when the bank account is still full.

The problem of perfection is that you can never really achieve it. Once you fix the bugs that directly impact the purchase and repurchase of your product, allocate a very specific, additional amount of time to eliminate workarounds and inconsistencies. Then let your marketing team pick a market meaningful release number or title and release. For example, do not release Beta 1 Build 1254 as your fifth actual beta release - release it as Beta 5. With the former, the press will only pick up that you are still on Beta 1 and shouldn’t take your product seriously.

Press Think: Clearly, its only on beta 1 - how far along can it be?

Another case of being lost in the fun house is enriching your application with a broader set of non-essential features for the release as a result of leveraging a high coolness factor API. Apple enriches their Cocoa API with each product release and update of Mac OS X, the operating system of the Macintosh computer. Some Mac OS based products are successful because they provide basic functionality but utilize as many Mac OS X features as possible - if that’s a part of the spec from the very beginning, then you haven’t let your focus drift.

Lost in the Funhouse Features can introduce new and unpredictable issues because you’ve often implemented features on top of new and unseasoned APIs. These features can also raise or modify basic system requirements for your application, which in turn can completely eliminate portions of your customer base.

We Have the Technology - Sales CEO

After developing one or more core products, you find yourself in possession of some mature technology libraries that can be repurposed. These product libraries could be repurposed to create brand new products for entirely new customer types. Or, you could try to develop new products based on the same source code. This is where doing good can go very wrong.

Imagine you develop a powerful CRM solution using the .net framework. In the process of developing your own libraries, you come to the conclusion that the libraries are good enough to license to third parties, so you set about to market them. Where are the human and financial resources going to come from to support an additional developer tool business? Not surprisingly, third party .net library vending and CRM solution sales have extremely different requirements in terms of pre-sales, target customer expectations, sales channels and post sales support. So either you’ve doubled the number of hats your staff has to wear in order to do even a mediocre job of promoting both product lines, or, you’ve had to double the drain on your warchest of resources - money and staff.

Most successful companies do their best to leverage a common code base in developing new products or optimizing old products; they also sell these products at multiple price points to specifically targeted customer groups so that one product line doesn’t cannibalize the others.

A We Have the Technology CEO inverts that. Instead, new products are derived from the common code base, not because of customer demand but because of high availability of technology or assets and the ease at which development is attained. This makes it more likely that a new product will cannibalize an existing product or create market confusion for all products based on the same code base.

This article is under construction. Versions will appear on the regular blog until the article is finalized.