I’ve had a lot of conversations lately with product managers who are wrestling with the appliance question:  Should they create a software-only product, or should they deliver an integrated hardware-plus-software appliance that contains all the underlying hardware and software needed to run the product?

It’s an important question because:

1. It has broad ramifications for the company: Are you fundamentally a hardware + software company (with hardware engineers, warehouses of physical product, etc.) or the more streamlined software-only company?
2. It is very difficult (and probably ill-advised for many companies) to do both.

There’s a lot to say about this topic, and there are no pat answers.   Thus far, customers as a whole have not shown an overwhelming preference for one type of product over another, even though specific customers have strong opinions.  So, no matter whether you sell appliances or software-only, you’ll find you can’t participate in many deals for whom your product would otherwise be a great fit.

Because of this, some hybrid approaches are emerging under the monikers of “software appliances,” “cloud appliances,” etc.  I’ll go into these hybrids in a future post, but for now I’m going to focus on the decision between traditional on-premise installed software and a hardware+software appliance.

Anyway, here are some things for product managers to consider as they go through their decision calculus (in no particular order):

The Pros of Appliances

1. Appliances are sometime easier for business users to buy. If your target buyer is on the business side (not in IT), it might be easier for him/her to just purchase and run an appliance rather than getting IT involved.  Corporate IT can be notorious for squelching purchases for new products, especially if they’ve already aligned themselves with a big vendor like IBM or HP.  I heard of one business-side buyer buying an appliance and hiding it under his desk, all so the IT director next door wouldn’t find out, since the appliance was not on IT’s “Approved” list.
2. Customers perceive simplicity. One purchase to make. One price to negotiate. One vendor to deal with. One “throat to choke” if things go wrong. This perceived simplicity might give you the edge versus competitors.
3. Quicker and less risky deployments, leading to higher success and happier customers. At least that’s the theory.  The customer does not have to integrate, configure, tune, and test a complicated combination of storage devices, processors, device drivers, operating systems, application servers, databases, database drivers, security software, etc.
4. Goes with Geoffrey Moore’s recommendation of offering absolute full solutions to your target market. The appliance does it all. For other markets that are opportunistic and not truly strategic, let them (or partners) piece together their own full solutions.
5. Say goodbye to the enormous Supported Product Matrix, and the huge amount of QA effort needed to test your software on all the possible combinations. As a company, you won’t have to purchase and maintain these pieces of hardware and software either. At one company I know that moved their business model to appliances, they were able to reduce their build-and-test time from 36 hours to 6.  And they were able to reduce their inventory of test platforms from 100+ boxes to 10 or so.  (Of course, reducing the number of computers might also be accomplished via cloud Platform-as-a-Service, but that’s a different article).

The Cons of Appliances

If you are offer an appliance, you’ll have to overcome the following:

1. If you, the vendor, are small, and your customers are big companies, you probably can’t buy the hardware as cheaply as your customers. If you’re an appliance, you will eat the difference between your hardware cost and what your customers could obtain it for.
2. You’re at the whims of hardware suppliers. This can be particularly bad if some of your suppliers might decide to become your competitors.
3. Customers can’t re-use boxes they happen to have lying around for your product, which might have lowered their project costs.
4. Hardware and software buying cycles are often different. Hardware is often bought when the previous boxes “become obsolete” according to the customer’s IT department’s obsolescence plan.  Software can more frequently be bought whenever the business case is compelling, regardless of whether the old hardware in the data center is due for a refresh or not.
5. Customers seem to have a tighter range of price expectations for hardware than software. You might find your appliance being compared to a hardware server, or to other appliances that are not even in the same problem domain. Software, in contrast, has a huge range of prices – ranging from free to several million dollars – that seems to preclude customers from taking a “cost plus” mindset or comparing one piece of software to another based on anything but the benefits that the software will bring.
6. Recognizing revenue takes longer. To recognize revenue, you need to get the entire product in their hands.  For software, that means that at 11:59pm on December 31, the customer can download the software from your website and you can count that revenue in the year-end financial results.  But for an appliance, you have to get the product assembled and on a truck first.  And in some cases, you might not be able to recognize revenue until the appliance is actually delivered to the customer’s site.
7. You’ll need to carry inventory, possibly on several continents. You’ll need to develop relationships with warehouses, drop shippers, and hardware assemblers. Alas, more parties between you and your customers means you collect less revenue and that your relationship with the customer is more distant and less under your control.
8. You need to collect sales/use tax and handle the special accounting and financial rules for physical goods.  In fact, you’ll have to learn how to do this in all the countries/states/providences/counties/cities where your customers live.  In other words, you’ll need to outsource order fulfillment.  And that means you’ll need to carry inventory.
9. You’re on the bad end of “one-throat-to-choke.” YOU are now responsible for, say, the bugs in the IBM DB2 instance.  Or the propensity of these particular EMC disk drives to error out, even though you have no ability to fix these problems, other than call into IBM or EMC support.
10. Your appliance might not fit in with your customer’s data center standards. Although you would think that customers should not concern themselves with the technology inside your appliance’s “black box,”  many of them WILL in fact be concerned and will demand extensive technical details.  And if they don’t like what they hear , expect to be eliminated from consideration. This scenario is more common with larger companies and those that put a high priority on security. They’ll want to make sure that your appliance’s O/S kernel is hardened with the latest patches, that you aren’t running software with known vulnerabilities, etc.  These organizations will often have a “do not deploy” list and if your appliance embeds one of those black-listed components, well, you’re S.O.L.
11. Appliances are counter to data center trends of virtualization and cloud deployments. It’s the pendulum swinging back, to the furthest extreme, in fact.  Virtualization and the cloud are all about separating hardware from software so you can add/remove capacity on the fly and have multiple applications more efficiently share hardware.  In contrast, appliances completely meld the hardware and software together.  If you need more capacity, you need to wait until you can buy another appliance.

There are many other pros and cons to consider in the product decision of offering software-only versus integrated appliances. These are just the ones I thought of off the top of my head, so please feel free to add more in the comments.

A colleague asked me this the other day: If a company is pursuing a “freemium” business model, how should they determine the optimal mix of features to offer in free vs. paid software?

It’s a good question. Freemium – where a product is made available in both a free and paid-for version – is a scenario I’ve encountered quite a few times and one that’s becoming increasingly common.

Today, customers pretty much expect free versions from any kind of online service. Free versions are also becoming common in installed software, even in the case of very high-priced, server-based enterprise software.

The free vs. paid question is worthy of an entire project, but here are some high-level thoughts that may be helpful to your decision calculus.

First, there are three basic kinds of “free” software, though some companies offer a hybrid:

1. Free product is functionality-limited.
2. Free product is simply a limited-time trial of the paid product.
3. Free product is identical to the paid product but includes neither customer support nor indemnification.

I strongly recommend staying away from offering only Option #3. In my experience, most companies that start this way eventually move to option #1 (functionality limited). Option #2 (time limited) is easiest to implement but may not garner the same widespread installed base as Option #1.

If you choose Option #1 (functionality limited), expect that all your customers will try the free version first. If they like it, fewer than 10%—often fewer than 1%—will go for the paid version. (Rarely will anyone to go for the paid version out of the gate.) After anywhere from a week to a few months to evaluate its benefits, the afore-mentioned small percentage of customers will upgrade to the paid product.

With this “typical purchase pattern” in mind, you’ll want to consider the following:

1. Be sure you understand your product’s value proposition and benefits. Extra research to nail that down is worth it at this stage.
2. Make sure the free version is a pleasure to use and delivers real value (see the previous bullet). If the user experience is not very good and if benefits take longer to percolate to the top than expected,then  don’t offer a free version to begin with. You’ll do more harm than good.
3. The free version must lack key functionality that is in the paid version. The paid version should provide a “pain killer” that the free version does not. The paid version shouldn’t merely offer a “vitamin,” it should deliver real pain relief. Otherwise, users will never upgrade. 
4. If possible, encourage customers to integrate the free product into their business processes and IT systems, so that it is hard to remove. Then, when they hit the above-described pain point, they’ll buy the paid version instead of starting a selection process with multiple vendors. For example, you might want to make a free online product easy to integrate with the company’s single sign-on systems and other sercurity protocols, or maybe make it easy to integrate with in-house databases and services.
5. The differences between free and paid versions must apply to a customer who has been using the free product for two to three months. This sounds obvious, but it is amazing how many companies botch this. For example, if you offer any of the following features, tools, and support, then they should be available in the free version and not limited to just the paid version. Remember, the whole point of Freemium is to get as many people as possible using your product. Without the following features, you’ll needlessly limit your audience:
   • Installation and configuration wizards.
   • Access to APIs and tools for developers. A goal is to have your customers’ programmers embed the free product into their business processes if possible (see previous bullet).
   • Documentation on setting up the product and integrate it with business processes / IT systems.
   • Assistance with getting started. For example, don’t limit access to “getting started” user forums to paying customers.
6. Be sure that it is exceedingly easy to upgrade to the paid version, even if the free version has been programmatically embedded into business processes and IT infrastructure. If customers must rewrite code, install new software, or implement a migration process in order to use the paid version, they will likely continue to use the free version—or contact your competitors.

Finally—and this is important—realize that if you make too much available for free, it is very hard to put the genie back in the bottle—unless users understand that you are offering a time-limited free trial from the get-go. People are furious at Ning, for example, for charging formerly free communities. I am not sure the brand or company will survive. In fact, it appears that competitors are already hovering to snap up disgruntled customers.

Clearly, I could write a dissertation on this. Maybe I already have. Let me know if these high-level thoughts are useful to you.