My consulting practice mainly focuses on commercial software product businesses, whether traditionally licensed, mobile, open source or SaaS. Or some combination of all of these. Many software product businesses are originally organized with that specific purpose in mind. But a remarkable number of others started from within another business. Let’s take a look at software services vs products, as well as a few service-oriented scenarios that tend to grow into or spin-off software product businesses:

Software (consulting) services

It’s common for a product to be developed from within a software services company, which can mean a range of services such as consulting or outsourcing. These companies are often asked to design/create software applications of various complexities and usefulness. Software services companies are asked to create applications either for internal use by end-user customers or as actual commercial software products. As a result, these service companies are in a good position to recognize new software product opportunities. Sometimes these products are even created by a customer-funded services contract (if the service company is savvy enough to retain code rights!).

Government contracting

This is a similar situation to the Software Services example above. Only 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 that 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 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. They are frequently asked to extend existing applications that are lacking in some way. VARs also integrate these solutions with other applications, integrate software with hardware, or even write a standalone custom application. These VARs are therefore well-positioned to get an early view of market needs that are lacking in existing commercial software applications. This gives them a sneak peek into potential emerging software categories. Starting with a custom application developed for a specific customer, they may be able to satisfy broader unfilled end-user needs when developed into commercial products. And again, sometimes with a customer-funded head-start in development!

End users

End users often have in-house development capabilities used to develop their custom applications. In this case, the “service” organization is the internal IT department. Again, 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 that aren’t “software product-oriented” end up with a software product business. It can be a great way for a software business to start. But many things 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 nurtured in the various service environments, as discussed above. Depending upon the parent’s business, a cultural mismatch can happen. Usually from a lack of experience and understanding of the software or product aspects of the new business. For example, the management team of an “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, let alone 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 can be 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. That is the lack of proper initial financial capitalization for a product-based business. One of the attractive aspects of the software business is that it requires much less investment capital than a manufactured goods business. But everything is relative; it’s still a product business. Product businesses typically require more capital than services-based 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 in the software services vs product discussion is the lack of complete “productization” of the software application, before launch as a commercial product. The usability, functionality, and reliability required in the commercial product marketplace far exceed the standards required in the custom software application market. When supporting a single company directly with a custom app, you can afford a level of support that can overcome minor application deficiencies in the areas listed above. Once rolled out to a mass market of users in a software product marketplace, these deficiencies can quickly kill a promising new product.

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 many mistakes. Specifically, when evaluating the important differences required for success in software services vs products. One of the elementary mistakes I frequently see is not ensuring that your new product makes a novel “contribution to the market”. Take a software product startup company with the 19^th product to enter an existing market, with no discernible competitive advantage. That’s a great way to lose money. No matter how large the market may seem.

Lack of software product industry experience

Add up all of the potential mistakes listed above, and the good news is that most of them can be mitigated by adding software-product company operating experience. Sadly, in many instances, the parent services company’s senior management is too proud or ignorant to do this. The inability to acknowledge the difference in software services vs. products is an often fatal weakness. Again, they could alleviate this potential weakness by hiring an experienced software product operating executive. Or in the short term, by retaining experienced industry consultants and interim executives. Sadly, they often don’t.

The bottom line is that there are many alternative ways a software product business is born. The conventional approach of creating a traditional investor-funded or founder-bootstrapped software product company is most common. But they can be shrewdly created intentionally from the beginning using a customer 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 some potholes and roadblocks must be avoided to prevent the crib death of embryonic software startups born this way.

So there are some lessons I’ve learned in creating product businesses from service companies. What is your view of software services vs products? Is this something you’ve done, or witnessed others attempts? What were the results? Pitch in with your two cents, and post a comment to expand the discussion.

Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or Subscribe to the Morettini on Management Newsletter hosted by LinkedIn. Contact Phil directly at info@pjmconsult.com