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 19th 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 info@pjmconsult.com
If you liked this post please share it with you colleagues using the “share” buttons below:
Great post. I have had the opportunity to be in consulting for funded startup software ‘ideas’ for several years. As such, our prospects were in all the buckets you described above but the best client, by all means, was an organization (and sometimes individuals) who were subject matter experts (again with funding :)) but had limited/or no technical resources to develop software.
These organizations (and or sub-organizations) where the hardest to find (i.e. no SIC code) but it was worth it. There are several challenges though (not understanding development cycles, not core business mainly, etc…
Interesting article.
I also found the article interesting. I wonder how many of the “software product” companies later decide to try to create a revenue stream from “services”. Several of my employers were in this category. It was always a difficult transition from “give away services to get the licenses order” to “increase the value of the contract by charging for services”
Most software product companies try to create revenue from services, whether early on or later. Different type of services though; usually built strictly around their product. Generally a much smaller market but much easier sale.
Thanks, Phil for the interesting post.
I’ve helped many [major] software vendors in my career, serving them, their early adopter customers and their troubled accounts; and they all struggled immensely at providing services (hence where I and my consultancy came in). The DNA just simply wasn’t there. At Crossvale, we’ve followed your first category, packaging what we’ve been doing with process improvement, BPM, and integration and wrapping it in a box. It’s a big difference than just doing the services, I’ve certainly learned a ton! But what our service acumen has ingrained in us is delivering for the customer–and this hasn’t changed with introducing product. Hopefully this validates we’ve got some very capable DNA 🙂
Just my 2c,
Jason
Nice comments which add to the discussion, Jason.
Have written a blog on similar topic. Though we started as a Product company and continue to do so, but to keep the lights on we started taking Service work which helped us fund our product development and build our team.
To Service or not to Service … that is the question
http://blogs.shephertz.com
I went through this exercise a number of years ago and the Productizing was a huge issue. They were accustomed to building software solutions for one company with a well defined user profile, but when I helped them change to a software product, we went through great pains to understand the importance of productization.
The other issue I saw was changing their mindset in terms of sales & marketing. Our product was a high dollar business solution and required much more marketing and a different approach to sales then what they had previously done for services.