The focus of my consulting practice is on commercial software product businesses, whether traditionally licensed, mobile, open source, SaaS–or some combination of all. While many software product businesses are originally organized with that purpose in mind, a remarkably large number of others started in another business. Let’s take a look at a few service-oriented scenarios which tend to grow into or spin off software product businesses:

Software (consulting) services

It’s very common for a product to be developed out of a software services company, which can mean a range of services such as consulting or outsourcing. These companies are being asked to design/create full applications, either for internal use by end user customers or as actual commercial software products. As a result, these service companies are in good position to recognize software product opportunities; sometimes these products are created by a funded service contract (if the service company is savvy enough to retain code rights!).

Government contracting

This is a very similar situation to the Software Services example above, with a couple of important differences. Government contractors are often not pure software development organizations; they may create hardware or provide other services as their government customers dictate. So they may not have a culture which emphasizes software development. Even more importantly, it can be tricky to retain rights to code developed with government funding–contracting expertise and an upfront emphasis on rights retention are critical in these circumstances.

Hardware/Systems

Another common scenario is software developed within a hardware or systems-oriented company. While not strictly fitting into the service category, I’ve included this example because it’s another common way software product companies are started that doesn’t fit the traditional methodology. The fact is that even in hardware companies these days, most of the innovation and IP is software-based. So it’s not at all unusual to see software developed as part of a systems approach that is later seen as having a market as a standalone application, apart from the hardware. Many successful software companies have started as spin-offs from hardware or systems-oriented companies.

VARs

Here’s another slightly different flavor of the Software Consulting Services example we began with. VARs are solutions providers for end user customers and are frequently asked to extend existing applications which are lacking in some way, integrate these solutions with other applications, or even write a standalone custom application. They are therefore well-positioned to get an early view of (and sometimes a customer-funded head-start developing) products needed to satisfy unfilled end users needs.

End user

End users often have in-house development capabilities and develop their own applications. In this case, the “service” organization is the internal IT department. These applications are often developed because of a “hole” in the existing commercial product offerings available in the marketplace. Forward thinking organizations may further develop and then spin-off these internal applications into commercial products.

So that’s a look at how organizations which aren’t-software product-oriented end up with a software product business. It can be a really great way for a software business to start–but there are many things that can prevent the successful transition into a going concern software product business. Here’s a list of a few:

Issues Which Can Prevent Success:

Culture

This is a frequent culprit in the failure of product businesses which are developed in the various service environments as discussed above. Depending upon the parent’s business, a mismatch in culture can come from a lack of understanding of either the software or product aspects of the resulting new business. For example, the management team of and “end-user” company that has developed a product may not be sufficiently software-savvy to make the right decisions to put the new business on a solid footing. A business executive in a software services company may not understand what it takes to develop a product to commercial product standards, or successfully market it. One of the biggest mismatches in culture often occurs within a government contractor. The “common business sense” required to be successful in the contracting business is shockingly different than that of a commercial software product business. The cultures are nearly polar opposites–It’s like English vs. French.

Capitalization

Often the cultural differences listed above or low overall capitalization of the parent company leads to the most common problem of these software product spin-offs: lack of proper initial capitalization. One of the attractive aspects of the software business is that it requires much less investment capital that a manufactured goods business–but it’s still a product business. Product businesses require more capital than service businesses. So even if you’ve created a great mousetrap, if you don’t have the money required to continue to develop it as well as market it–at least until you’re cash-flow positive–failure is quite likely.

Not productized

Maybe the most common problem of all is the lack of “productization” of the software application prior to launch as a commercial product. The level of usability, functionality and reliability required in the commercial product marketplace far exceeds the standards of the custom software application market. When you are supporting a single company directly with a custom app, you can afford a level of support which can overcome minor deficiencies in the areas listed. Once rolled out to a mass market of users in the software product marketplace, these deficiencies can kill a promising new product very quickly.

Me-too Products

One of the areas of expertise lacking in a service-oriented company (almost by definition) is Product Marketing/Management/Planning. The lack of this functional expertise can lead to a number of mistakes. One of the elementary mistakes that I see surprisingly often is not ensuring that you are making a novel “contribution to the market”. A software product startup with the 19^th product to enter an existing market, with no discernable competitive advantage, is a great way to lose money.

Lack of software product industry experience

If you add up the potential mistakes listed above, most of them can be mitigated by the addition of software-product company operating experience. Sadly, in many instances the parent service company senior management is too proud or simply ignorant and unable to acknowledge this weakness. This potential weakness can be alleviated by hiring an experienced operating executive, or retaining a software product industry management consultant such as PJM Consulting.

The bottom line to all of this is that there are alternatives to the more conventional approaches of creating a traditional investor-funded or founder-bootstrapped software product company. Whether created intentionally from the beginning or a “happy accident”, companies started this way can provide an advantage of significantly reduced capital-requirement-to-profitability compared to traditional startup methods. But there are potholes and roadblocks that must be avoided to prevent crib death of embryonic software startups born this way.

So that’s some of the lessons I’ve learned with regards to creating product businesses from service companies. Is this something you’ve done or witnessed others attempt?–what were your results? Pitch in with your two cents — post a comment to expand the discussion.

Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or the PJM Consulting Quarterly Newsletter. Contact Phil directly at info@pjmconsult.com

Tweet