Deadly Sins: Letting Your Focus Drift
Letting your focus drift can up-end your business at any time: before you release your first product or after you have had a success or two.
As a software vendor, your first priority is to ship product. If you are an Engineer CEO or a technology researcher, it is very easy to consciously or unconsciously place technological perfection above all else or get caught up in the total functionality of the technology you work with. A fairly horizontal example of this is getting caught up in the richness of operating system APIs, such as Apple’s MacOS Cocoa. With each update of the operating system, Apple adds a lot of systemwide features that become acessible through Apple’s own developer tools. Some of these features are extremely attractive but, how important is it to support these features given the purpose of your product? Have you taken the time to see how the added weeks to develop AND test the new features will impact your cashflow? Another example is in game development on the PC, where not only is DirectX regularly enriched by new features, but graphics board manufacturers ATI and Nvidia regularly add new hardware enhanced acceleration features.
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 example of this.
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 US Robotics (who owned Palm at the time). 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!
Another type of typical but deadly drift is jumping off into new product development just because its easy, given your current toolset. After developing one or more core products, you find yourself in possession of some mature technology libraries that can be repurposed. This is love of technology in yet another form, turning success into undoing. For example, 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 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). Either way, you lose. Having two completely divergent product groups also complicates your exit strategy. How many large vendors want to acquire BOTH a CRM and developer tool vendor?
This article is now a part of Technology Tribe.