In The Business of Software
- Do you want to be mainly a products company or a services company?
- Do you want to sell to individuals or enterprises?
- How horizontal (broad) or vertical (specialized) is your product or service?
- Can you generate a recurring revenue stream to endure in good times and bad?
Cusumano’s was one of several frameworks we used in planning Synap Software. In the next few Business Decisions blog entries I’ll share my thought process behind these decisions. Some worked out fine, some not so fine, and some are an ongoing story. Today’s entry is my answer to the first main question: Do you want to be mainly a products company or a services company?
Products or Services?
Services Provide More Chances for Recurring Revenue
Cusumano states that he used to believe it was better to be a products company but as of the writing of the book (2004 – which I know is an eon ago in tech years) he says he “no longer think(s) this is true”. Why?
The key is in recurring revenues. Services companies can sell support and consulting services even during times when customers are not buying software.
Services companies excel at showing that they can provide value (by saving costs, by finding hidden money, etc) even during times when their customers are having a hard time. Professor Cusumano posits that when customers feel that their IT partners understand their needs better than any other service provider, customers will be more likely to continue to do business with them – even in times of downturns.
Service providers seem to be in demand even when on the product side customers decide not to purchase an upgrade during tight times. A customer may no longer be growing so needs no additional seats, or a product may simply become commoditized or fully matured, offering customers no real motivation to make additional purchases.
… yet …
Products Provide Dramatically Improved Profit Margins
The kicker though is the “striking” difference between software companies and service companies: gross profit margin. He cites examples of large software companies that report 99% gross profit margins on their software product business, yet only 61% gross profit margins on services business! Wow! Who wouldn’t want 99% gross profit margins!?
This makes sense and is a basic reason that many of us have the big dream of riches from our software creations: for each additional piece of software that is sold, the incremental gross costs are very little.
The goal for a strictly product company is to create a product or products and then to not perform customizations, consulting, or support services for individual customers. All customers get the same product. When one customer looks and interacts with the company just like every other, Product companies have no incremental costs with each new customer. Steve Pavlina refers to this as ensuring that your income is not tied to your time.
But – before you head all cylinders down the product road seeking those giant profit margins, remember the issues with a product strategy are that 1: product sales can quickly fall short of expectations in down times and 2: just like with authors and artists, it can be difficult to produce that hit single.
How about a hybrid?
Professor Cusumano’s study is, of course, much more detailed and well-spoken than my comments here – but hopefully you get the point up to now and can follow along to the finale. I introduce it here in order to lead up to where Software as a Service fits in. Software as a Service sits right between product and services.
Software as a Service Provides the Software Company with High Margins and Recurring Revenue, and Provides Customers with Assurances of Top-Notch Customer Service
Like a pure product company, Software as a Service vendors have little incremental cost with each new customer (read: high profit margins). Like a pure services company, SaaS companies enjoy recurring revenue.
Sounds good for the software company, but what’s in it for the customer? SaaS provides customers with a constantly updated software product, reduced in-house IT costs, and immediate usability. The SaaS model also provides assurance to customers of a product they will want to keep using because the software company wants to ensure the customer returns month after month. The prospect of recurring revenue from a customer should encourage the software vendor to put out quality products and treat customers well. With the SaaS model, customers are not locked-in and have not invested much up-front, so can leave any time the product does not meet expectations.
Decision: SaaS
To me, Software as a Service is the best of both worlds for vendors and customers.
Result: So Far, So Good
As a final note, here are some additional aspects of the business SaaS customers and vendors need not worry about:
- activation keys, liscensing keys, version management, and installation support
Concerns: the most common concerns with SaaS delivery are support and data protection. We’ve addressed these by, for example, keeping our apps simple and easy to use so that each additional users does not require linearly additional support.
For these and other reasons SaaS is not right for everyone and not right for a lot of apps. For some markets and products it would not work to try to shoehorn into the SaaS model.
We went into this though, having picked the SaaS model first, and then determining what type of applications to offer that would fit.
Notes: This is republished content: I published this content burried in another blog entry back in November. With all Business Decision posts, I am simply sharing what we decided and somewhat of a framework that others could use when faced with similar decisions. I’m not making a recommendation that you should decide the same because I don’t know your situation.
Synap Software, LLC 
Great post Scott!
I was just recently rethinking my decision for how to monetize my web application.
Thanks!
This is a thoughtful post, Scott. I’m definitely going to go buy Cusumano’s book now.
Last year I built, (but didn’t launch), a complete SAAS-type web app. Now I’ve crossed over to to the darkside and am working in WXPython.
The thing that struck with the web app was how many ancillary features you have to add to get off of the ground. (User accounts, CC Processing, etc.)
What’s really interesting is the hybrid model you mentioned. I like the idea of having an option of paying $10 a month for remote backup, etc…
SH – You’re right about the “ancillary features you have to add to get off the ground”. There are several things that do not relate directly to the application itself that need to be done. Yet, once you do them for one application you then have a framework to re-use for other apps (this is true for SaaS and traditionally delivered apps as well).
My recommendations for getting started:
First, apps with no fee to start and monthly payments actually have a month after launch to implement a payment system. Add the free trial time in front of that and apps have six to eight weeks. New applications can go ahead and launch without the payment system in place and then implement it during that six to eight week period.
Secondly, most new apps do not need a complete e-commerce, automated accounting, automated limit-management system on day one. Unless it has had a lot of upfront buzz, few new apps will have hundreds or thousands of new users day one. When we first launched I didn’t even have a systematic way to expire trial-users’ accounts, to ensure each user in an account is paid for, etc. (Thanks to using LeadsOnRails ourself, we did have a systematic way to send email updates and reminders to trial users throughout their trial period. e.g. “Thanks!”, “One week remains”, “One day remaining…”, etc. <-Excuse the blatant plug).
Alex – Thanks. Just like in any business, there is of course a lot more to consider when it comes to figuring a target market, if that market will pay for an application and how they will hear about the app. I’ll share where I ended up on the other Cusumano questions in future posts. Pricing and marketing decisions that go into monitizing an app are each topics that could fill books themselves.