Derivative Products by Jack Krupansky Leveraging Your Efforts Whether your product is a success or a failure, sooner or later you need follow it up with another product. Maybe a competitor moves in or maybe the market moves on. Somebody changes the rules of the game and now you need to respond. You can start from scratch on a new product or you can revamp your existing product. It's fun and exciting to "start over", but you might be much better off salvaging and leveraging your past efforts. A technologist will prefer to start with a clean slate, but an entrepreneur wants a head start. Some of the more successful companies got there by taking a product and enhancing it to get a "new" product. This new product is called a "derivative" product since it is derived from an existing product. The derivative product might be radically different or it might be an incremental improvement. A slow but steady stream of incremental derivative products is a less risky route to success than to dream of a string of back-to-back home runs. With significantly less effort invested in a derivative product, a failure can more easily be recovered from. You can also use a derivative product to experiment and test the waters for a new market. Your existing customers can be beta testers. Take the opportunity to slightly change your focus and maybe you can identify a larger or more accessible market. I decided to write this article after I successfully released a new product, C-odeScript, which was based on my current product, Liana. It is a callable, C- like, object-oriented programming language interpreter for C/C++ Windows programmers. The bulk of the product is a subset of Liana, but with a few key features and packaging that make it more appealing to a broader market. Definition From an intellectual property point of view we get the concept of a "derivative work." This is a work (or product) that is produced by modifying an existing work. Those modifications might involve adding new elements, removing existing elements, or transforming existing elements. An example of the latter would be a foreign language version of a product. At a trivial level, most products can be considered "derivative" because we almost always use some pre- existing, off-the-shelf components to which we add our own components and know-how. For example, C programmers utilize functions from the vender's runtime library or add-on libraries. Although the product is indeed derived from those components, it is the large amount of know-how that makes your product something more than just a raw collection of parts. In much the sense that a book is much more than being "derived" from a collection of words. If your product can in turn be used as a component of larger products, those products have their own "primary value". Your product may be the important "tail" of the dog, but the customer designed the dog itself. Some good examples of derivative products are Adobe's Display PostScript derived from PostScript, Microsoft's Windows for Workgroups derived from Windows, Borland's Delphi derived from ObjectPascal which was in turn derived from TurboPascal, and Microsoft's Visual Basic derived from their BASIC efforts and an acquired GUI development environment. In each case, not only was the development time reduced, but the venders were able to capitalize on the market success of the original products. I would not classify Microsoft Windows as being derived from MS-DOS since Windows merely "uses" DOS in much the same way as an application "uses" DOS or Windows. Similarly, Windows NT is not derived from Windows since it was a from-scratch effort (although emulation of the Windows API and DOS are included) and the primary value is far more than the emulation of the older systems. Strategies A product is the sum of its strengths and weaknesses. The price and market acceptance of a product will reflect the balance of those strengths and weaknesses. Remove some weaknesses or add some strengths and you may be able to boost the price. Or maybe you can strip out some of the strengths and sell at a lower price to a larger market. Decide what you really want to get yourself into. Do you really want to deal with all the logistical hassles of higher volume? Might you prefer to deal with an even smaller customer base if they are more sophisticated and willing to pay a higher price for a more sophisticated product? Do you enjoy customer support and interaction with sophisticated users? Maybe you'd rather just do a small utility and take a small royalty in return for somebody else doing all the marketing and support. You might consider developing a product that is almost "self-supporting". Actually, identify a market whose customers support each other. With the various on-line services this is now possible. Your full-blown product may require extensive support, but a stripped-down version (less room for the user to screw up) might be more profitable. Technology vs. Product The product is what the customer sees. The technology is the raw material used to build the product. The more technology you have to play with, the wider your derivative options. If your product consists of mostly off the shelf components, you may not have too many derivative options and end up needing to start over to get your next product. But with a much higher proportion of malleable, proprietary technology you may have enough flexibility to generate all sorts of new products without starting over. Use your technology to give yourself more control over your destiny. New Release Although it is really a trivial example of a derivative product, a new release of your product with minor changes still qualifies as a derivative product. Maybe a few features makes your product more appealing or more competitive. Microsoft Windows 3.0 was just a new version of Windows 2.1, but with enough new features that the market instantly began paying attention to what had been a real dog of a product. Lite Version A stripped down version of a complex product can frequently be more popular for cost-conscious and less sophisticated customers. Example are Novell "Lite" and PowerSoft's Desktop version of PowerBuilder. New Platform Your product may run on DOS. It can be moved to Windows, Windows NT, OS/2, UNIX, the Macintosh, NeXTStep, etc. If the new platform is less capable or a wider market you might drop the price. Or if the platform is more capable or a more limited audience you might add some custom features and raise the price. Bells and Whistles Sometimes you can succeed by adding tons of bells and whistles to your product, but that approach frequently backfires. The product might become harder to use. Or customers resent paying extra for stuff they don't need. Or the product is slowed down. It gets bigger. It needs more disk space and takes longer to install. It takes more time and money to test it, not to mention to develop it. But even with all these possible downsides, sometimes it works. Windows 3.0 is a good example. Suites and Bundles By packaging several products together you can reinforce in the customer's mind the benefits of how the products work together. Maybe they hadn't thought very much about the synergism before the products were combined for them. Maybe they had worried that there might be interface problems with your product. Or maybe a price discount on the bundle makes all the difference in the world. Or maybe they wouldn't have bothered to buy your product by itself, but since it came with the other products they'll give it a try. A lot of suites and bundles are just promotional with no real, substantial technical link between the products. I wouldn't consider them to be derivative products. But if your product is integrated with another product the customer may finally perceive a whole that is greater than the sum of its parts. Use Someone Else's Base Product You don't even have to have a product to create a derivative product. You can license someone else's technology and use that as a base. Why would they let you and why wouldn't they do it themselves? Sometimes they don't have the resources or the niche for the derived product doesn't interest them. Or maybe they recognize your special skills and would be more than happy to take a cut of your pie without having to expend resources. The bottom line: it allows them to leverage their assets. Let Someone Else Use Your Base Product On the other side of the fence, maybe you have a successful product or technology that could be used by someone else to derive a new product that wouldn't directly compete with you but would allow you to enhance your income with minimal expenditure of resources. And let someone else take the market risk. But think twice about how you provide access to your technology. A good partner can allow you to leverage your energy and assets. Don't let the grand and glorious promises of endless riches delude you into giving away the store. But don't cling to your property so tight that you miss your big opportunity. Shareware Version I personally have been toying with the idea of releasing shareware versions of my products after they have been commercially released. My goal in doing that would be to reduce my presales overhead, especially requests for demo disks that I don't have. Let them try it out rather than listen to me tell them how good it's going to be. My biggest concern is that I'll not have as many leads and may end up needing to provide support for non-paying users. I'm currently more comfortable using a $129 price to filter out all the low-lifes who are more interested in collecting demo disks and playing around than serious business. The shareware version should be somewhere between a really stripped down demo/working model and the full- featured product. It shouldn't be too badly "crippled" and should allow the developer to realistically evaluate the product. Give them enough of a taste to whet their appetite. This approach may get renewed interest courtesy of the Internet. A web page "storefront" with a detailed list of frequently asked questions plus a downloadable evaluation kit might work out. I think you could also add a script to the web page to collect information for leads. Consulting I decided to add this section when I got yet another "are you available to customize" call from a prospective C-odeScript customer. They're really interested in the product, but have a few oddball (but important to them) feature requests. In the end, they may decide they really don't need the special features, but my readiness to meet their needs seems to leave them with a favorable impression. This consulting service could end up bringing in as much money as the product itself. CAD to Liana Way back in 1989 when I finally gave up on an attempt to get financing to develop an architectural CAD product, I was fishing around for a simpler product that I could develop on my own without external funding. Windows was starting to attract a lot of interest and SDK programming was notoriously difficult. My CAD product was going to include an OOP macro language (analogous to AutoLISP in AutoCAD.) The idea was that the entire user interface and upper levels of the CAD product could be done with a lightweight, easy to program, low- performance, macro language while the underlying high-performance CAD engine would be in C/C++. It didn't take me too long to realize that the macro language would make a good product on its own. Although the CAD product was never developed, the structure and key concepts of the stand-alone macro language, called Liana, were certainly derived from the CAD product. So I was able to salvage a lot of my "wasted" design effort. Windows NT Port The similarity of the Windows NT Win32 API to the Windows 3.1 Win16 API made it fairly easy to offer a version of Liana for Windows NT. Although NT still hasn't really taken off yet, this has provided an opportunity for free product promotion. Macintosh Port A Macintosh compiler vender has expressed interest in marketing a port of Liana for the Mac. This hasn't happened yet, but is another example of leveraging efforts to produce a new revenue stream. Enter C-odeScript Although Liana had very limited success, I recently released a new product, C-odeScript, which is a C- like, object-oriented programming language interpreter which can be called from C/C++ applications. This module was derived from Liana. A lot of developers liked the Liana language, but felt an "obligation" to go with C++ or Visual Basic or Smalltalk. Although C-odeScript is essentially the same language, it is now much more palatable, because the developer does most of their "real" development work in C++ with their favorite development tools and C- odeScript is merely an "add-on library." Liana was always able to call DLLs so that the developer could use Liana for the GUI and package their C code as a dynamic link library (DLL.) That approach met resistance since turning normal application code into a DLL has a number of technical and management problems. With C-odeScript, the situation is reversed. I provide a DLL which is callable from a C/C++ application. It also has the ability to call back to the application's code. This is a much more palatable and less risky approach for C programmers and their managers. A modest increment of effort turned one failing product into a more promising product. The market for Liana was limited to developers willing to consider an alternative to C++. In other words it excluded the C++ market. The market for C-odeScript includes the C++ market. A small difference in technology but a big difference in potential market size. What Did I Do? The underlying language and class library is identical to Liana, with only a few exceptions. Unlike Liana, the GUI features in the class library are a minor, nice plus rather than the key feature. I considered stripping out all the GUI features, but decided that having a compatible library was worth the increased size of the library. The biggest difference is that C-odeScript doesn't include the interactive development environment or the ability to generate executable files. The other major difference is a documented application programming interface (API) which is how the C/C++ programmer talks to C-odeScript. Adding the ability to call application functions from C-odeScript was an important addition, but was not a lot of code. Another small effort producing a big benefit. The result is a product which shares a lot of technology but has a dramatically different appearance to the market. I had considered incorporating "Liana" or at least "L" in the name to draw attention to the commonality, but decided that I cared less about people who knew about Liana than about those who wanted a callable scripting language interpreter. Stripped-down C-odeScript One early C-odeScript customer is very interested in having it available under UNIX, DOS, and even PDAs. Another is interested reading binary scripts that the user downloads from an Internet web site. More potential markets. IDE Toolkit I have been working with a small Macintosh compiler vender who has a bare compiler but no GUI development environment. They were intrigued by Liana and the idea of a small, easily customized IDE. We signed an agreement and I got some money, but no product has shipped yet. This project was based on work I did for Liana, but now it may take on a life of its own. GUI for Traditional Tools That same Mac compiler vender is looking to broaden their product line and likes my idea of a simple IDE that can quickly be attached to an existing non-GUI development tool. We are currently discussing such an effort for a FORTRAN source code manipulation tool. They need to enter lots of parameters and view before and after versions of code side by side. This is not a performance intensive app, so the ease of programming and flexible OOP features of Liana are a real plus. Since it isn't a lot of code (probably no more than a few thousand lines), they aren't worried about being able to hire an army of C/C++ (or VB) grunts to "work the code". In fact, the minimal development effort and rapid time to market are the key issues. But probably most important is the fact that they can easily start with my existing IDE instead of beginning an extensive design effort to do their own. Identifying Derivative Products One place to look for suggestions about derivative products is your existing customer base. Your product may have had limited success that could be expanded if you corrected limitations that your customers can identify. Another place to look is those people who never bought your product to begin with. They had some concerns and raised some issues. That might be your blueprint for a new product. There's no harm making a few cold calls to venders who might benefit from integrating their products with yours. Serendipity is sometimes your greatest ally. Conclusion You've invested a lot of time and money creating your intellectual property, so make them work for you. It's a good idea to have an enduring piece of technology that can survive each time Microsoft comes out with a new release and consumes a larger chunk of the Windows add-on market. Derivative products are great for serious technology developers who wish to focus on developing innovative technology and leave some of the marketing to others. They're also great for someone who really knows an application niche but doesn't have the time, patience, or expertise to develop the core technology themselves. ----------------------------------------------------- Jack Krupansky runs a one person software business, Base Technology, which develops and markets the Liana object-oriented programming language and C-odeScript callable scripting language interpreter and offers Windows software development consulting. He may be reached at 800-786-9505, e-mail at jack@basetechnology.com, or on the web at http://www.basetechnology.com.