By Michael Woloszynowicz

By Michael Woloszynowicz

Sunday, June 19, 2011

It's Not A Redesign If You Don't Cut Features

Recently my team and I have been undergoing a major top to bottom redesign and re-implemetation of our product. Not only are we making drastic cosmetic changes, we're also redeveloping the application into a purely REST centric application that sits atop an AJAX front-end. Given the extent of the redesign, we naturally want to achieve maximum impact with minimal effort, and so the easiest way to redesign a feature is to drop it completely. While this is simple in principle, it's not always easy to accomplish in real life.

Before we begin taking a chainsaw to our application, it's good to always reflect on what you're trying to accomplish and the route you took to get to this point. The purpose of the redesign was manyfold, not only do we want to provide a smoother and more interactive experience, we also want to improve the applications usability and applicability to our target market. If you look back at the evolution of your product and your reason for adding a certain feature, you'll often discover that you added it based on certain assumptions about your market and what they may need. The earlier into your business that these assumptions were made, the more likely they are to be wrong. This is precisely the sort of reflection I did, and with that I built a high level list of features that I felt were superfluous or ill fitting with the product's strategy. Armed with this list  you can then proceed to validate whether these features are as useless as you expected. This turns out to be quite simple, as you can do 3 things to immediately test the value that a feature brings to your user base:
  1. Go through your database and query tables that relate to specifically to data generated or needed by the feature in question. Too often I found cases where a feature was used once or twice within a multi-year span. Google analytics is also helpful for this as you can simply measure the number of click-throughs a page receives.
  2. Ask and watch your clients use your product, this is a must before any re-design.
  3. You have a product already, so just remove the feature now, if anyone needs it, they'll call you. 
With the list of candidates in hand, talk to your team to get their input on what should and shouldn't be dropped. Your support and sales teams should have particularly good insight on this, but you are likely to run into big a problem; people are reluctant to remove features. The sales and management teams always like to have a lengthy feature sheet that shows just how comprehensive your product is. "Why would we take something out that's already done?", and "How can we launch a new version with less features?", are some of the things you're likely to hear. From a non-technical perspective it's easy to think this way, nobody wants to think they wasted money coding all these features that will now be removed. At this point it's your job to convince them of the following:
  • There is a real carrying cost for any feature. It has to be maintained, it increases the complexity of your application, it has to be documented, it reduces the agility you have to make changes, and in the case of a redesign, it has to be redesigned. This is the way small firms compete with larger rivals, agility is their greatest asset. 
  • Even with proof that a feature is not being used, opponents will argue that it may be needed in the future. Let's however remember that a feature is a piece of your application that adds value, and if it doesn't add value to your current customers, what makes you think it will to future ones? Is your current user base not representative of your future users? Also remember that it's this sort of thinking that made you create the feature in the first place, except now you have proof that it's useless. 
  • You can't infinitely keep adding features, at some point your menus will grow long and the number of options become overwhelming. Your users can't find the value adding features they are looking for, and your product dissolves into an unfocused mess. The user experience will suffer and useful features get lost amongst the clutter. 
  • Sell what your product does so well, not how much it does. Lots of companies have been successful doing this (think 37signals, Dropbox, 
Although it may take some time, armed with the above arguments and a good set of metrics, you should be able convince even the most steadfast opponents. The one word of caution that I have, is that you should always ask yourself whether a feature is not used because it's useless, or because it was impossible to find or discover what it does. It's best to flush this out through qualitative testing such as customer interviews.

Finally, what do you do if a few people actually do use the feature? In this case you need to figure out how often, and how important it really is to them? If it's critical to them, they use it constantly, and they represent your target market well, then you should keep it and promote it. Most importantly you need to find out why others don't use it. This is usually a sign that people can't find it, or there is a better way of doing something that you or they don't know about. If it's only somewhat useful to the users that use it, then I suggest trying to remove it and gauge the reaction. We've done this on several occasions, and while there can be an initial backlash people tend to forget about it in a weeks time. If you have a product that satisfies 80-90% of their requirements better than anything else out there, they'll live without the feature. Remember that if you try to design for everyone, you end up designing for no one. 

Once you've hammered home the need for feature pruning, take the opportunity to make this part of the companies fabric. Rather than doing this every couple of years, make feature review an ongoing process and trim out the garbage as soon as it proves to be a dud. 

Better still, take a more proactive approach and integrate the principles of the lean startup, not just to new products, but to new features as well. Regardless of the maturity of your application, make a point to create a minimum viable feature for anything that requires more than a few days work. To give you an example, several years ago, our sales team was screaming for integrated fax capability in addition to email sending from our application. A good portion of users were asking for the feature so we decided to bow to their request and add fax notifications. We went spent good deal of time deciding whether to setup our own faxing server or use a third party service, and fortunately we opted for the latter. Since the faxing provider charged us a rate of few cents per fax, we decided that we would simply pass on the cost and not mark it up. After a few weeks of development and integration, the feature was launched. Three years later we've sent out only a handful of faxes and it's one of the features on my chopping block. If only we'd put a link on your settings page to enable faxing, saying "faxes will be billed at a rate of X cents per fax, proceed?" and then forwarded them to a page that say's the feature is coming soon, we'd have saved ourselves a great deal of time. Sure people wanted it, but it didn't have enough value for them to pay for it. The handful of faxes they sent every week they just sent through their fax machine. 

If you find yourself getting lots of requests for a feature, ask users how they are accomplishing that task now. Is it something brand new, or do they just want something integrated more tightly into your application? If it's the latter than consider integrating with leading providers of that service via API's rather than starting from scratch. If someone is doing it way better, why fight them, especially if that's not your businesses core competence?

Once you can get past the psychological barriers for cutting features, you'll find it extremely liberating, and it can be the fastest way to improve the quality of your product. If you've redesigned your product and you haven't cut any features, you did it wrong.

If you liked this post, please Tweet it, upvote it on Hacker News, or follow me on Twitter for more.

Saturday, June 11, 2011

Apple’s Commoditization of Cloud Storage

While Apple unleashed a host of cool features for both iOS5 and OS X this week, the most important and game changing announcement was that of iCloud. The reason this is so momentous, is that by offering 5 GB of storage for free, they have effectively commoditized cloud storage for a large chunk of the consumer market. For most, 5GB is all that is needed to store the majority of content that you need protected or made available across multiple devices, particularly when combined with services like iTunes in the cloud and iTunes match. There is also no doubt that this storage limit will grow over time, or that Apple will offer expanded storage for a nominal fee. 
While many argue that the proprietary nature of iCloud make it no threat to other providers such as Dropbox, we have to be mindful of the technology race between Apple and Google. In an effort to match iOS’s value proposition, Google will no doubt release a similar service in the near future, particularly since it would just be an extension of their Google Docs, Music, Gmail, and Apps services. Given the huge combined market share of iOS and Android, this will provide cloud storage to the majority of technophiles; the very same clients that Dropbox caters to. By releasing a host of API’s to their storage services, Apple has opened the flood gates to a whole new breed of applications that previously may not have wanted to host the storage themselves. For example, services like Evernote can be created simply as a set of applications, without the hassle of worrying about most of the server infrastructure that backs them. Even though most cloud storage services provide API’s, the lure of the established Apple and Android user bases, as well as the distribution model of their respective app stores, will prove much more enticing for developers. More and more we’ll see the value of cloud storage reduced to the services built on top of them, and it is the provider that offers the best set of these services that reigns supreme. It is the very advantage that Apple has gained from their App store, and the hundreds of thousands of applications that occupy it. Three years later, many of their competitors have failed to catch up, and with iCloud, Apple is hoping to repeat this success. 
This is not to say that consumer cloud storage providers like Dropbox are doomed, there is still a large market that may not want to be bound to either Apple or Google, but it does reduce the size of the potential market they can target. What Dropbox needs to do is become more of an open platform for building applications and services on top of, rather than just a provider of cloud storage. Dropbox itself has a huge user base that they can leverage as a distribution channel for third party services, albeit without the millions of credit cards that Apple has in their possession.
Even if you’re not an Apple customer, or even an Apple hater, you should rejoice in the release of iCloud as it is merely the start of a new wave of storage providers, and the services built on top of them. 

If you liked this post, please Tweet it or follow me on Twitter for more.