Bloatware Argument for Customer Selection

Over the last few years, there have been a number of product upgrades that actually subtract features, especially from Apple. You see this the most in products that are offered for free; its hard to argue against radical change when you aren’t actually paying for it.

Not paying for something though doesn’t mean there isn’t a cost; any time you have value, you have cost.

As a user, it costs you an investment of time. Getting you to invest as much time as possible is a key strategy for any developer. Even though no money changes hands, you’ve made a personal investment of time. That’s something which is completely personal, yet can make all the difference in a future sale. The more you invest and are pleased with that investment, the less likely you are going to delete the product.

In the case of Apple though, its something quite special when they remove a feature, especially in a paid for product.

  • Removing features can be a simple matter that whatever it is, it isn’t quite supported yet in the development framework.  The vendor doesn’t want to wait around until it is available, so they ship the product without the feature. Maybe it will be added later, maybe not.
  • Removing a feature can be a matter of a future shakeup of a product line.  A feature that you’ve been using for years in a free version of iMovie, for example, may make its way into an update to Final Cut Pro. The same feature could find a future in an online service.
  • Removing a feature can also be a matter of dumping a certain type of customer for certain products. Stripping out power user features can alienate a customer, especially if they are extremely dependent on the the feature. One reason to do this is to push that user to another, more expensive solution. Another could be to reduce the cost of handling that type of customer at that level of product. Does that sound crazy to you? Its not so crazy.

Consider a mobile application used by power users.  A certain problem pops up dependent on conditions set by power users. For example, one application I handled a long time ago was a contact synchronizer mobile product that would generate database errors with really large databases. A tech support request in this case eliminated the profit on 50 sales of the product. If the condition itself wasn’t easily addressable, then the only solution was to have a hard limit on database size (the product was eventually killed, solving that problem).

Leave a Reply