There are two ways to mount a successful software initiative. The first is to identify a costly problem and solve it with an easily deployed tool that users will quickly recognize and value.
The second is to identify and solve the problems that are shared by people who are trying to succeed the first way. In the process, theres one key mistake to avoid: Never let any one vendors IT platform define your approach.
Those points were at the foundation of my keynote remarks this month at an annual session on entrepreneurial opportunities in software, conducted by the Caltech/MIT Enterprise Forum and sponsored by the Software Council of Southern California.
We met at the California Institute of Technology in Pasadena, where its likely that well revisit the topic in mid-June of next year (if you want to mark your calendar now).
Within the enterprise, I observed during the session, the “find a problem” strategy is the one thats most likely to find a business unit as its champion and patron; the independent developer, though, can also pursue this route, with many finding enterprise partners who become both early adopters and almost co-creators.
Those enterprise alpha users dont seem to mind giving their competitors a chance to use, eventually, the same technology. I suspect that there are two reasons for this. First, the early adopters get a head start on optimizing business processes around the new tool, and having a competitor in a reactive, catch-up mode is better than having a competitor that leapfrogs you with its own independent initiatives.
The second reason is a form of Metcalfes Law: In many cases, a technology becomes more valuable as more people use it. A supply chain integration tool, for example, will find more partners adopting compatible interfaces when there are more user organizations.
Another successful approach to software is the same one that works in a gold rush. Regardless of whether theres actually gold out there, you can always sell eggs, shovels and blue jeans to the people who think there is.
When everyone from the bookseller to the pharmaceutical researcher is deploying Web services, both the producers and the consumers of those services will be seeking service management tools. When everyone wants to do business securely on the Web, everyone needs security technologies.
The shovel-selling approach might seem vulnerable to commoditization or to winner-take-all dynamics in which the first perceived leader becomes the preferred provider and everyone else is marginalized.
To guard against either of those failure modes, one has to be a service provider first and a software provider second.
If you not only package expertise in the form of software but also tailor the product to the customers site and support the customer in adopting and using the product, youre no more a commodity than a lawyer or a doctor or an accountant. Any such professional can theoretically be replaced by another who applies the same shared body of expertise, but each represents a “sticky” investment in building familiarity and trust.
I warned against letting any IT platform provider draw your road map. Depending on Apple to build PowerPC machines or on Microsoft to deliver an all-.Net operating system are recent examples of how to make such a mistake.
Within these general guidelines, there are specific trends. Applications that address the needs of an aging population or that integrate online and personal-presence technologies are clearly targets of opportunity.
But the best way to fail as a software entrepreneur is to read market research and target your efforts at an area thats supposed to be hot, even if you have no particular expertise in that area. Plenty of other uninspired teams will be aiming at the same target for the same bad reason.
Thats a route to “me-too” software that wont be any fun to write. Who needs that?
Peter Coffee can be reached at email@example.com.