I think that deep down inside the soul of most software developer/entrepreneurs is a desire to build that killer software product that sells millions of copies. This is not surprising. Once the software is written, it doesn’t cost much to deliver it to customers (and in cases like SaaS, it doesn’t have to be delivered at all). Business and finance types would label this as a business model with high gross margins (as the cost that goes into actually reproducing/delivering the product is very, very low). I’m much more simple minded and would call this “Making Money While You Sleep”.
This is one of the essential differences between a software products company and a software services company. Software services can be loosely defined as any activity involving the creation of software that is done for a specific situation with a relatively low level of leverage and reuse. Stated differently, you’re selling a service (once again, I demonstrate my uncanny knack for the obvious). To make software services revenue, there’s generally work involved. Every time. Though you can certainly increase your billing rates or the size of your fixed-bid projects, there are few software service companies where you are making money when you are not working. It generally doesn’t work that way. That’s why I love products companies. They’re much, much riskier – but the upside is much higher. You really can make money while you sleep. (That’s assuming you get much sleep in the first place, but that’s a topic for another article).
This high profitability is also why many companies that start out as service companies decide to try and convert to products companies. But, based on the high rate of failure of these kinds of “conversions”, this seems to be relatively hard to do. Most software service companies have a hard time “productizing” their business and creating software they can resell.
Here are some of the reasons why I think this is so hard:
Why It’s Hard to Switch From Services To Products
- Customers Want To Own The Code: If you’re engaged in a software contracting project, chances are very high that the customer wants to own the resulting intellectual property. Most contracting agreements transfer the rights to the resulting work over to the client that paid for that work. As such, without a special provision, you can’t reuse or resell that code. If customers are unwilling to let you retain all or partial rights, any work done is essentially locked into that customer project. There’s no product for you to (legally) resell.
- Code Is Too Client Specific: When doing software contracting work, the client is often very specific about what they want the software to do. The more specific the end result, the more unlikely it is that you’ll find another customer that can use the same product. It takes careful planning and design to ensure that a resellable product emerges from a custom development project. This almost never happens by accident. Also, it’s much more expensive and difficult to try and take what was a custom development project and then later try and morph into something other customers will pay for. It can be done, but it’s not easy.
- Different Tradeoffs: Software development is often about a series of tradeoffs. When working on a product, the end result is an outcome of a series of choices the development team makes about how the product is implemented. In a software products company, the team is usually good at making the choices that are optimal for creating a packaged product. They do things like keep “custom code” out and implement rules engines and templating mechanisms and domain-specific scripting languages. The idea is that an investment is made in the right areas in the short-run, so that the product can sell better in the long run. On custom programming projects, the team makes a different set of choices that are optimal for getting the project finished on time, within a certain budget and that meets the business requirements. Rarely is there the opportunity to invest “for the long term” nor does it makes sense to make investments so the product can be used at another company. There’s no incentive for the company footing the bill to pay for these features.
- Lower Capitalization: One of the best things about a services company is that there is much less risk involved. Once the engagement is finalized, you can be reasonably sure that you’re going to get paid based on hours spent or milestones reached. There is no large investment required to first build the product and then find customers to pay for it. You’ll often have a customer commitment to pay you before you do any work. Though this is great for services companies, it’s easy to get used to this and hard to break out of the habit. When you try to switch to a products company, the financial needs of the company change dramatically. All of a sudden, you need to work without anyone guaranteeing payment. It’s tough to make that transition.
- Products Are Harder: When writing software for an individual customer, life is pretty good. First, you have a financial commitment (as discussed above). But, you also have requirements. So, you’re not forced to come up with what the product should do – the customer paying you generally has an idea of what they want. In a products business, you don’t have this luxury. You have suspicions of what future customers might want, but it’s never crystal clear. You may even ask potential customers what they want, and they’ll tell you, but the answers are rarely as accurate and thoughtful as when the customer is writing a check up-front. And finally, the underlying code itself is usually much more complicated in a products company. In a custom programming project, you generally know a lot about the environment that the software will run in. If you’re building a software product, you may need to create software that will (gasp!) run on computers other than your own. Unless you’ve ever written code and been forced to get it to run on someone else’s machines (or hundreds of machines) it’s hard to understand how difficult this is.
- Team Selection Is Different: Chances are, if you built up a software services company, you hired people that would be good at doing custom programming jobs. Sure, you’ll hire good programmers (doesn’t everyone?) but often they are different programmers than the one’s you’d hire for a products company. Since the risk is so much higher for a products company, it’s life-threatening to hire programmers that can’t create working software and meet a release date. In the services business, hiring mistakes are painful, but not always fatal.
Summary Of My Point: It would seem that writing software should be a relatively consistent process (hire great people, use workable methods, etc.) regardless of whether you’re building it for a services company or a products company. But, a software services business is very different from a software products business. Different team, different financing, different decisions, and different goals. It shouldn’t be that surprising that few companies can make the transition from services to products.
In a future article, I’ll make an attempt at identifying some ways to increase the chances of success if you’re looking to make this kind of transition. It’s hard, but it’s not impossible.