Just a few days ago, Steven Sinofsky of a16z addressed some of the great points in this article. All the more relevant since he was in charge of some major MS products early on.[1]<p>Here's the part I most enjoyed:
"The bottom line is a decision has to be made. A decision means to not do something, and to achieve clarity in your design. The classic way this used to come up (and still does) is the inevitable “make it an option”. You can’t decide should a new mouse wheel scroll or zoom? Should there be conversation view or inbox view? Should you AutoCorrect or not? Go ahead and add it to Preferences or Options. But really the only correct path is to decide to have the feature or not. Putting in an option to enable it means it doesn’t exist. Putting in an option to disable means you are forever supporting two (then four, then eight) ways of doing something. Over time (or right away) your product has a muddled point of view, and then worse, people come to expect that everything new can also be turned off, changed, or otherwise ignored. While you can always make mistakes and/or change something later, you have to live with combinatorics or a combinatoric mindset forever. This is the really hard stuff about being a PM but the most critical thing, you bring a point of view to a product—if a product were a person you would want that person to have a clear, focused world-view."<p>[1]<a href="http://blog.learningbyshipping.com/2014/04/17/shipping-is-a-feature-some-guiding-principles-for-people-that-build-things/" rel="nofollow">http://blog.learningbyshipping.com/2014/04/17/shipping-is-a-...</a>
This is important advice for consumer-ish software. But in other areas, it works differently. A product "grows up" as its original user cohort grows up, and that's OK.<p>I saw this in the music creation software space. Products start simple out of necessity. They are a good fit for a cohort of users with simple needs. But as the user cohort advances, they need and want more powerful features. Typically companies add the features to create a "more professional" product, rather than see their existing users jump to a competitor.<p>Of course after (say) 5 years of this, the product is no longer such a great fit for "beginners". So it creates space for a new product to step in, and with a fresh approach. Of course that <i>new</i> product will eventually accrete more features, too. Some manage it better than others, but they all become more complex. And so the wheel turns again.<p>At the same time, plugins provide a safety valve, as well as a way to form partnerships. Plugins can be a way to give certain features an "audition" before maybe rolling them into the product itself (or bundling the plugin, maybe with somewhat tighter integration than before).<p>TL;DR Products have a natural cohort of users. If the users grow up, the products do, too. Also plugins.
Be very careful when adding too many features, because if you ever want to take them away (to simplify the site / UX) your users will hate you.<p>Just changing the look of a page will usually make people go crazy. Ebay's yellow background story is something that developers can learn from: <a href="http://www.uie.com/articles/death_of_relaunch" rel="nofollow">http://www.uie.com/articles/death_of_relaunch</a>
I joined a small company that had made this mistake horribly and many times over. The entire product was just a mess of half-baked incoherent features. It looked like many were put in to satisfy customer requests while others were just there to be able to say "It's got X!" without thought to the rest of the product. There were even two duplicated features in different places with different names. The worst part (well, best from my point of view) was that a lot of them didn't actually work correctly. They didn't have testing. That gave me license to chop a lot of it away with the justification of "If anyone was using this they would have told us it was broken. They didn't so they aren't. Get rid of it.". In those days we had feedback like "It's free and worth every penny". Now it's more like "I introduced it to my colleague and he was impressed, expect another sale soon". The feature set now is smaller than it was then, and looks less impressive when it's itemized, but what's left is more focused on a narrower type of user in one profession, more powerful and cleanly integrated into an elegant, usable product.
I once worked on a large application whose features were driven largely by customers and it wasn't pretty. You easily end up with a bloat and 'death by preferences' [1]. So I agree, your product vision should drive your features.<p>What I didn't realize at the time (and I think many don't) is that when you have customer requests for features that don't align with your vision you should consider making your product extensible. Keep a small core product and provide plug-ins for additional features. Customers pick the plugins they need or write their own.<p>[1] <a href="http://insideintercom.io/product-strategy-means-saying-no/" rel="nofollow">http://insideintercom.io/product-strategy-means-saying-no/</a>
Sure, adding features that hurt your stability and your chances of growth is a terrible idea. Many a company has made that mistake before, and ended up with an unworkable product.<p>We do have to make sure that, with the features we have, the product is actually viable though. There's also many projects out there that just won't get anywhere because there is no compelling reason to use them over the alternatives.<p>For instance, I know of a small data visualization project that happens to have far better performance than KineticJS and D3: It was built precisely because those two libraries were tried, but just didn't provide the right frame rates for what a team was trying to do. The problem is that the current implementation's only interactive features are pan and zoom: Not even an event on mouseover. Want to highlight something based on a search? No dice. This makes the library so narrow in its applications that the project just can't capture users.<p>an MVP should be minimum, but we can't forget it must also be viable.
> No, your customer will not get angry if you don't implement all their suggestions.<p>Actually, they probably will... and then either they'll go find a better replacement for your product, or implement it themselves/find someone to (this happens with various proprietary web apps I'm forced to use. :)
Not bogging down your service with unneeded features is a feature in it of itself. And often times the best feature.<p>Also, ditto with it not being the rule that customers know what's best. Customers are for the most part good judges of their own happiness, but it's a heuristic, not a hard-and-fast rule : take it with a grain of salt. If you know what you're doing, you, as the designer of the product, should know more about it than the user, the layman who uses the product, so you know what'll be the best in the long term better than the user.<p>But another thing about being the designer of the product is that you spend so much time with it you start staring at it from a millimeter away, losing sight on the grand purpose. It's something you can't prevent even if you're aware of it; as the artist, it's your job to focus on detail. It's why programmers initially thought Dropbox was just "rsync and ftp with a neat UI, what's the big deal?". The more you focus on detail, the less you focus on the big picture, which is an important perspective to have -- which is why it's also important to keep tabs on what the user says h/she wants.<p>They hated the News Feed when it was originally released and they shat on the iPad when it originally came out.<p>But they also thought OK Soda would be a good idea.<p>Maintain a balance.
The point is interesting, and follows the more general Lean approach. I can easily see how to decide not to implement a feature — what is less clear is <i></i>how to address<i></i> such requests: any public forum, related to features or not, will have tons of those, and they are usually the most voted comments (because they are positive, lead to discussion and refer to unmentioned aspect of the service).<p>Should the company be silent? Should they say that those are further down the pipe than other, non-visible aspects (better synchronisation, platform compatibility); should they say that those have been considered and will not be implemented in the foreseeable future?