Nice post Dharmesh,
These things are always hard to decide upon, even harder to generalize, but I'll give it a shot as well :)
If implementing a new 'deep' feature requires you to add complexity to other broader parts of the product, there is a very valid need to reconsider adding the feature. Or in other words, if adding something that's going to make a couple of users really happy constitutes having to make a lot of users just slightly unhappy, you have to weigh serving a bigger crowd versus the quality of the overall user experience. We've encountered and decided upon many such trade-off situations while developing our software.
The right balance between those two (user base / user experience) is determined by the goals you set for your product, there's no single ideal balance.
That's one side of it, the other, as you mentioned above, is the development team not adding features that don't get in the way of the broader part of their user base using the 'less is more' meme as an excuse for the feature not being high enough up on their priority list or in the worst case lazyness..
I do believe that almost anyone who's developed a product that is in use by a whole bunch of people is committed to taking good care of his/her baby (the product that is). You may call it naivité, but I think laziness is rarely the actual reason for something not making the cut, especially in the start-up phase of the developing company and/or the product.
There is a very delicate line between just right and overboard especially with initial offerings. It will always be sensible to balance between the features of the product and its target market. More often, adding new features comes later when early feedback rises just before clamor. Best. alain
I agree that keeping your software/solution simple enough not to thwart users it is equally important to keep alternate ways like keyboard shortcuts to accessing more "deep" features. doing this would keep your UI simple and keep functionality available to a userset that desires it. anyways there can be workarounds wherein a user can define his/her own keyboard shortcuts for certain frequent used functionalities and thus overcome the "complexity factor" generally attributed to a vertically deep software/solution.
With all due respect, I think there is a much more academically-rigorous way to address this question.
Software is a means of making a machine act in a certain way. In this thread, we are talking about software that directs a machine to present a certain user interface. A user manipulates that interface to get the machine to accomplish certain tasks.
The question of "features" is really a question of how well the abstract model of the system and its user interface matches or maps to the real-world tasks the user is trying to accomplish. If you have a good elegant match,we say the system is "intuitive" and it's easy to use. If there is a bad match, the system is difficult and annoying to use.
Think of an automobile. The steering wheel and accelerator are very intuitive interfaces. I lean the way I want to go, and if I want to go faster I push harder. This is much better than the initial interface of a tiller and separate spark-advance and throttle levers.
Modern German cars provide another (bad) example: these manufacturers have consolidated a lot of functions (sound system, navigation, security, climate control, etc.) into a single onboard computer and provided a computer-type menu interface to control it all. This interface is universally panned by auto writers and is so complicated that it has probably contributed to crashes due to driver distraction.
In this case, the question is not "features" (ie, "does the radio have surround-sound?") but the mapping of the model between system and real world.
As another example, Apple products have excelled at matching user interface models to the real world tasks the user is trying to accomplish. That's why non-geeks usually prefer Macs over PCs. They say the Mac is more "intuitive" -- what they mean is that the user interface model of the Mac matches the way they work and think better than the PC does.
I think you will find that many "feature" discussions are really "user interface model" discussions. And for user interfaces, "fatter" is not better. Nearly always, if you do a good job of matching the user interface model to the real world task, you will have a simple, elegant, easy-to-use interface.
(Mind you, it may take a lot of software to implement that interface. But in a successful system that complexity is hidden from the user, much as the complexity of the Toyota Prius hybrid car is hidden from the driver.)
Nice article Dharmesh.
What I've always found interesting is the tendencies of small and large companies to introduce a new feature in its 1.0 form into their app or platform and then abandon further refinement or bug-fixing in order to introduce yet another 1.0 feature somewhere else.
Innovation and adding new features is a great thing, but it's important to analyze your system and ensure that the next great 1.0 feature is a) something your customers really want (v. something an executive in your company really wants) and b) something that will integrate into your current platform with relative ease and be maintainable going forward.
I think it's also important to heed the words of non-developers that are looking at these new features. If you have them on board, a good QA engineer or Business Analyst can be invaluable (and brutally honest) at informing you on whether or not your new, whiz-bang feature is 'usable'.
Nice (and bold) post Dharmesh. These days coincidentally I've been through many articles discussing the feature bloating and then, going through yours discussing this is really like pulling me into the real world.
Just now the idea comes to me of what "KISS" (Keep it Simple) means actually. It is not 'Keep it Simple' in implementation I think (because you cannot keep a large system away from some minimal complexity) but to keep the software interface simpler for user. In that way I think user is gonna love that additional new feature. (or may be an experiment can be done by hiding the new feature from UI, giving it out through some shortcuts to more experimental user base and getting the feedback..)
Seamless integration of the new feature into what is already available as pointed by Drew is again an extremely important aspect to keep in view.
I do agree that the whole "Less is simple" talk is mostly about the UI side. Carl did sum it best with "in a successful system complexity is hidden from the user".
Simple and intuitive interface is what any system needs. As about features, Joel Spolsky has a great post about it: