The main focus of my consulting practice is on commercial software product businesses, whether traditionally licensed, mobile, open source, SaaS–or some combination of all of these. 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 software services vs products as well as 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 often being asked to design/create software applications of various complexities and usefulness, 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 new software product opportunities; sometimes these products are even 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 also create hardware or provide other services as their government customers dictate. In this respect they greatly resemble their commercial “Integrator” cousins (see below). 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 “intentional” methodology. The fact is that even in hardware companies these days, much 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 & Integrators

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, integrate software with hardware, or even write a standalone custom application. They are therefore well-positioned to get an early view of (and again, sometimes a customer-funded head-start in development) emerging software categories that can satisfy broader unfilled end users needs when developed into commercial products.

End users

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 or license these internal applications as commercial software products.

So that’s a look at how service-oriented 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:

Software Services vs Products: Issues that Prevent Success

Company 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 an “end-user” company that has developed a product may not be sufficiently software or product-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 services 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 the low overall capitalization of the parent company leads to the most common problem of these software product spin-offs: lack of proper initial capitalization for a product-based business. 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 from a capitalization perspective in this discussion of software services vs products the takeaway is this:  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 properly–at least until you’re cash-flow positive–failure is quite likely.

Not properly productized

Maybe the most common problem of all in the software services vs product discussion is the lack of complete “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 application deficiencies in the areas listed. Once rolled out to a mass market of users in a software product marketplace, these deficiencies can kill a promising new product very quickly.

Me-too software 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 product-specific marketing expertise can lead to a number of mistakes when evaluating the important differences required for success in software services vs products. One of the elementary mistakes that I see surprisingly often is not ensuring that your new product is making a novel “contribution to the market”. A software product startup with the 19^th product to enter an existing market, with no discernible competitive advantage, is a great way to lose money no matter how large the market may seem.

Lack of software product industry experience

If you add up all of the potential mistakes listed above, the good news is that 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 the difference in software services vs. products and this corresponding weakness. This potential weakness can be alleviated by hiring an experienced software product operating executive, or in the short term by retaining experienced industry consultants and interim executives.

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 shrewdly created intentionally from the beginning as a funding mechanism or as a “happy accident”, companies started this way can provide the advantage of significantly reduced capital-requirement-to-profitability compared to traditional startup methods. But as detailed above, 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. What is your view of software services vs products? Is this something you’ve done or witnessed others attempt?–what were the 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 [email protected]

If you liked this post please share it with you colleagues using the “share” buttons below: