Posts Tagged ‘products’
With Apple’s recent iPhone SDK release, the local tech scene is planning an event. However, as some of the comments have pointed out, Apple’s licensing arrangement is a tad restrictive. This all sounds vaguely familiar. As it has been told to me, when Apple originally released the Macintosh, the software kit was expensive and exclusive: you could only buy your tools from Apple. This limited the availability of 3rd party Mac software, which in turn limited the adoption of the computer itself.
Fast forward to today with the iPhone kit. While the $99 for a full development license (allowing you to test on your iPhone instead of an emulator) isn’t exorbitant, it’s certainly a hurdle. The biggest offense though is the distribution system. You are required to distribute your application through Apple’s site, have your application blessed by Steve Jobs, and only then do you get to keep 70% of the sales revenue.
Apple is trying to double dip in the upper right hand corner of the software business model map: first by selling the iPhone, then by selling other people’s software products. Perhaps the iFund they’ve arranged will soften the blow. My guess is that iPhone developers will move towards the upper left corner instead so that Apple will have less of a cut of their revenue. Why would an iPhone developer spend large resources on developing a rich iPhone app, only to hand 30% of their revenue to Apple?
Recently I’ve been doing a lot of thinking about the different business models available in the software industry. While software companies sometimes assert that they have a unique model used by nobody else, all of them ultimately boil down to four basic ones: services, product centered services, products, and products distributed as services. All four of these are perfectly valid models with unique opportunities. The best way of showing the relationship between these models is what I call the Software Industry Model Map. Version 1.0 is seen below:(Software Industry Model Map, version 1.0., license)
Here is a brief description of each model, including advantages and disadvantages:
This is the simplest business model and has the fewest barriers to entry. You build custom code for clients to do whatever they need. So long as you know how to code and have basic computer equipment, you can be in business. Many boutique web development firms operate this way.
This model is on cash basis: you do the work, tally the hours, then invoice the client. Barring cash flow issues (and deadbeat clients), you usually get paid a few weeks after sending the bill. While the simplicity of this model is appealing, there are several drawbacks:
- Code reuse tends to be lower than other models.
- You tend to get maintenance work, which may dictate the tools you have to use.
- When clients request unpleasant or time-consuming work, you either have to do it or convince them to accept an alternative.
- Cash flows can be irregular, unless you have retainer agreements in place.
Product centered services
This model is usually the logical successor to services (if it isn’t used from the beginning). While it tends to take more planning and investment than pure services, the revenue streams are greater. You also have a specific product you’re familiar with and can reuse to a degree. You can develop this product in house, or you can learn how to extend an existing product. Code reuse and standards are more easily found here than in pure services.
Although the most obvious implementation of this model is with “enterprise solution” businesses, some boutique firms create products to narrow in on niche markets. This model frequently employs significant numbers of non-programmers because the software itself may not represent the bulk of the value added. Despite high revenues, this model has some pitfalls:
- Expenses tend to be high due to the wider array of expertise needed.
- The complexity of services offered can lead to scope creep and unrealistic expectations.
- Clients can still request unpleasant work.
- Unless you’re developing your own product (which is more expensive), the whims of external software authors may hamper plans. Crucial features may disappear along with support for older versions.
Rather than doing custom work for specific clients, it’s far more profitable to build a product and sell it over and over again. The incremental costs of selling more copies of the product are negligible. Aside from providing support, maintenance costs are also close to nil. This results in an extremely high profit margin. When the product is marketed appropriately, the revenue potential is also great. Microsoft, Adobe, and Intuit are companies that have roots in software products. While financial rewards of this model are obvious, it also presents the highest barriers to entry:
- Startup costs are staggering. Millions of dollars can easily be sunk into building a software product before the first sale is ever made.
- Although you do not answer to the daily wishes of individual clients, the features you offer must be flexible enough for the majority of your users to accomplish their tasks.
- Completing a software product does not guarantee that it will sell.
- Software products are environment dependent: it can be difficult to test software under all of the configurations customers will have.
- Bug fixes are distributed slowly and may not be applied correctly.
Products distributed as services
Developing a product is very expensive, but this can be offset early on if you offer the product as a service. The big advantage to using this method is that your customers receive the benefits of code updates instantly; code reuse and profits are inherently high. This method is also the most efficient at leveraging network effects: when people can easily connect through your service, your software becomes more valuable with little extra effort on your part.
Your customers usually don’t need any special environment to use your service, aside from a live connection to it. You have complete control over the code environment. Services also tend to have simpler interfaces or ones that are user defined. Data storage typically occurs on your end, making it trivial for users to change hardware on their end. Google, 37signals, and many other Internet-based services released over the past 5 to 10 years fit this model. Products distributed as services may appear to be very attractive, but they are not without downsides:
- You must maintain the hardware where the code resides as well as network connections. When any of this fails, customers cannot use your service.
- Your code has little or no access to the client’s hardware. Personal computers can easily handle an advanced calculation or data operation for one user, but the same action on your server multiplied by tens of thousands of users at once is not cost effective.
- Revenue levels are lower than those of a pure software product. In exchange for reduced functionality, customers expect your service to be low-cost or advertising supported.
- Although storing data on your server makes it easy for users to change their hardware, they lose control over the data. This is a problem for businesses in sensitive industries or users with security needs.
- Users cannot keep old versions of your software. If you take away or change a feature they rely on, they must wait for you to either add it back or provide an acceptable alternative.
More analysis and examples to come…