Nope. Only after our software reached a certain amount of features (compared to our competition, mainly) did we start to experience real growth.<p>Our customers would not accept not having some features because the fewer features are so great. Nope. They need many features, and have complex workflows, that's how it goes.<p>This doesn't mean that the features you offer shouldn't have a clear purpose and be easy to use.
The article contains an image of a (relatively basic) calculator, asking the question: "How many of these buttons will you really push?"<p>Well… all of them. I may not need tan every day, but when I do, I need it to be there.
This line of thinking is how we end up with a market of disposable, crappy toys satiating the immediate needs of "minimum viable users" but being incredibly wasteful over time.<p>Out of the examples named:<p>- Twitter - has plenty of features, and a larger ecosystem of additional features that, despite them trying their hardest, they didn't manage to kill.<p>- Lyft - it's a meatspace service that's to some extent open-ended in terms of feature, but the app aspect itself is featureful compared to their simpler competitor: central dispatch taxi ordered through a phone call.<p>- Venmo - can't comment on it, it doesn't seem to exist in my parts of the world.<p>- Slack - it has lots and lots of features, constantly adds new ones, and it has a large ecosystem of integrations. Those features and integrations are a big reason Slack is adopted in organizations, over alternatives. If you want to compare it against a focused tool that does one thing and does it well, compare it against IRC.<p>Great products do their primary use case well, but have high mastery ceiling - meaning there's potential to learn to use the tool better to achieve higher efficiency/productivity/satisfaction - and support interoperability, which means a bespoke set of features can be integrated by users who need it.
Counterpoint: Joel Spolsky's "Bloatware and the 80/20 myth" from 2001.<p>> <i>Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release “lite” word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the “word count” feature which they need because most journalists have precise word count requirements, and it’s not there, because it’s in the “80% that nobody uses,” and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can’t use this damn thing ’cause it won’t count my words. If I had a dollar for every time this has happened I would be very happy.</i><p><a href="https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv-bloatware-and-the-8020-myth/" rel="nofollow">https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...</a>
This tends to be true in case of consumer products and tend to be not true in case of professional products.
Google search is simple, Google AdWords is not, and never was.
You cannot create a professional 3D modeling software, photo editing software, IDE, video editing software without starting relatively complex. Professionals need to use quite a lot of sophisticated features to be productive. The learning curve is less of a concern in a professional setting.
(I kind of know it because I have been working on a VR 3D modeler for a while. To create a professional-grade software the barrier to entry is quite high, so small developers try to create simple-to-use consumer, hobby-ist, products. I am creating a hobby-ist product, which is already much more complex than a consumer product.) If you look at reviews of the smaller products, the overwhelming majority of criticism is lack of features.
This is an overly broad generalization.<p>Computer software products can and should come in all sizes and flavors and designs.<p>This is the most powerful and flexible machine invented. You can’t say the software that runs in them should be like this or like that.<p>What you can say is some products do well by being simple.
I'd use every one of the buttons on that calculator. Admittedly I've never had need for gradians, but they're on the same button as degrees and radians, so it would still get pushed. For everyday use I use Qalculate!, and for more complicated calculations Maxima or LibreOffice Calc, all of which are far more advanced than a Sharp EL-501X. Dumbing down products makes them worse.
A more accurate statement would've been -<p><pre><code> Solving fewer problems, better makes for a great product.
</code></pre>
There are more ways to make a great product. This is just one of them.
"Less features make my job easier, so please have less features" - UX designers reluctant to solve the problem they were hired to solve<p>Well, duh. Developers can relate, short programs are exponentially easier to write well than large ones. That's <i>the challenge</i>.<p>> Think about the most successful products you know. The ones you use everyday, as a customer. Twitter, Lyft, Venmo, Slack.<p>I wouldn't think of these products and I don't use them every day.<p>I would think of very complex applications with an incredible amount of features that I'll mostly never use. However, this large surface area overlaps with what I need. There is no "more focused" app that does the job.<p>I would also think of the top software companies - Microsoft, Oracle, SAP, IBM. None of these companies are known for their "simple and focused" applications. Quite the contrary.<p>Sure, if you have a little app that's just a frontend for one thing, keep the focus. Otherwise, keep in mind that "it doesn't do the <i>one</i> thing we need" is generally a deal-breaker, whereas "it does one-hundred things we <i>don't</i> need" is not. Everyone's needs are slightly different and critical mass is important.
That's good advice; if you are building a command-line tool for Unix. :)<p>The thing is I can chain command-line tools using a pipe, embed them into scripts and more. I probably can't do that with your app.<p>My guess is that great products are based around workflows rather than features. Have a vision, work towards it.
The pictured sharp calculator made me rage at the state of modern desktop calculators in most OS’s. The other day I needed atan (inverse tan) and found the built in windows/osx calculators do not support this function. Google for web calculator, nothing. In the end I hacked up a quick c based program. A 40 year old calculator with a 4004 or 6502 CPU can do more than default desktop applications.<p>Removing features can eliminate a customer or two.
Many great products have many, many features. One of the examples given (Lyft) might appear simple on the surface, but think about the complexity behind just one element: the matching and routing for Lyft Line (similar to UberPool).<p>Lyft has many, many engineers, and I'm pretty sure they're doing more than fixing bugs, dealing with infrastructure scaling etc.<p>One thing great products <i>do</i> seem to have in common is that they are easy to use, in the sense that their UI has few elements, and much complexity is hidden from the user.<p>This is similar to the concept of having APIs that are simple, but which are serviced by code that does a lot under the hood, hiding the complexity from the API consumer.
Tell that to WeChat and a bunch of other Asian products.<p>The idea of great products is kind of misguided.<p>Talking about great products is something industry people do it's not something users of the product think about them.<p>In other words, it's academically interesting but not useful to determine whether a product is actually successful which IMO is part of the greatness of a product.
As examples of this thesis, apparently, it shows photographs of a camera flash, a bookshelf radio, a turntable, and a pocket calculator. Yow.<p>How many people have used <i>any</i> of those standalone devices in the past 10 years? How many of you have used, in the past 10 minutes, any of those as a feature of a single device that includes all of these? I rest my case.<p>The 1968 Braun catalog may end up in an industrial design museum for its beauty, but people aren't buying products like that for their beauty today, any more than they're buying 1968 sports cars. People open their wallet for features.
Though the article doesn’t say anything new, it’s astonishing how hard it is for founders (especially of SaaS products) to actually do this. I run a UI/UX design firm that focusses on B2B SaaS products and the biggest difference I see between great and ok products is the founder’s a ability to accept simplification and focus. Feature creep sounds like you may be adding ‘more value to your end users’. In reality, you’re making your product more generic, less valuable, and slower in terms of helping the user get from point A to B.
My iPhone is a great product because it does more.<p>Great products don't have to be spartan. But in my experience they do seem to be intentional and value craftsmanship.
I recently wrote this to someone who was thinking of learning Pico-8 (a very minimal game engine) I was saying they should just learn Unity instead.<p>...<p>Something like Pico-8 reminds me of a program from my days as an architect.
Sketchup, it was a very intuitive 3d modelling program aimed at architects, it was very easy to learn, but once you've got the hang of it you start running into all sorts of limitations, like the initially lovely UI becomes a total mess when u have a big and / or complex model, it performs really bad, it cant do proper renders at all, and so on. In the end, after struggling with Sketchups limitations I just learned 3DSmax It could do everything Sketchup could do + soooooo much more, the learning curve was much steeper at the very start, but afterwards, working with it was much easier and faster, and allowed me to do a lot more. I would have been much better off if I had started with 3DSMAX, as opposed to wasting time struggling with Sketchup trying to get it to do stuff it couldnt.
Unfortunate. So many of the comments here seem to miss the point and this is a theme I have noticed through my career as a developer.<p>Yes, every button on a calculator is eventually needed by someone as are every optional concern in every application, but every optional concern is not needed by everybody and certainly not frequently.<p>Selectivity of desired features is a bias. The inability to account for bias in product design makes for shitty products that are either excessively complex or excessively expensive.<p>All terrain tires that are extremely safe for driving in snow are great, but I don’t need that living where I do since it almost never snows here. It is an unnecessary excess that I certainly would not want to pay for. For me this is no different than the <i>tan</i> button of a calculator which I have also never needed.<p>The inability to perceive or account for bias, as evidenced by the comments here, are why many employers are hesitant to elevate developers to product management positions, which is another form of selective bias.
I think bad products do either too few things adequately or many things badly. Good products either do a few things well or many things adequately. <i>Great</i> products, on the other hand, do many things well, <i>by appearing to do fewer things</i>. Additional features are designed, in great products, to be discovered as you need them.
This is a religious debate. Some people are delighted by additional features, others by thoughtful design. It’s hard to see the other viewpoint and how this can be mutually exclusive.
If you don't mind, here is my personal angle:<p>"In reality, great products do a whole lot, while providing a helpful, intuitive and somewhat shy interface. In this way, they allow to achieve solid results for complex problems in no time.<p>Customers who are lucky enough to interact with such product at least once in their life often describe it as being simple and even magical.<p>But do not let this fool you. Simplicity and magic do not equal to the lack of functions or settings.<p>Great products get the job done. They do it in timely fashion. They do not brag. They do not ask you to sign in. The do not put you through myriads of advertising. They do not overcast nor crash customers' lives by their own egos. They just work."
This might be a bit of professional bias on my part but I like to think of product-market fit using ideas inspired by information theoretic model-data fit:<p>Low resolution fit: The product vaguely and simply fits its market.<p>High resolution fit: The product is complex and is tightly tailored to the market.<p>Overfit: The product is so tightly tailored to some users that it only fits well a small part of the market.<p>Underfit: The product is so generic that it's easy to copy or is missing important features.<p>Then it becomes about trying to achieve optimal fit. It's almost a bayesian thing in my mind. You want a product or platform that is not overfitted, not underfitted, high resolution where it needs to be, low resolution otherwise.<p>There is one more dimension I find useful which I will call "crossfit" because it is inspired from the concepts of cross entropy (<a href="https://en.wikipedia.org/wiki/Cross_entropy" rel="nofollow">https://en.wikipedia.org/wiki/Cross_entropy</a>) or KL divergence (<a href="https://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_divergence" rel="nofollow">https://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_diver...</a>).<p>Having bad crossfit means that the product fit is biased in some suboptimal way. It might fit a side market of a greater market, it might focus on aspects that would be more important in another market or it might use a design language that is better tailored to different users.<p>Having bad crossfit often happens when product teams with expertise in one domain apply their knowledge to a second domain without being sufficiently familiar with the differences. Without taking into account differences in key details of the new domain, without learning the new lingo or without properly weighting the different levels of importance of challenges, product fit tends to end up not quite right.<p>An extreme but common example is that of software developers (like myself) designing interfaces that are very difficult to use for anyone but other software developers. However, it can also happen in subtler ways even for experienced product designers when they jump into a new field they are not very familiar with.<p>Having good crossfit is about learning to speak the language of your users.
> The ones you use everyday, as a customer. Twitter, Lyft, Venmo, Slack.<p>Somehow I am living in a different world. I don't use any of those services on a daily basis. Actually, Twitter is the only one I come across sometimes when someone links/embeds some tweet.
There is a notion of feature death with products but to improve retention you do need to keep shipping out new features so I disagree here.<p>It feels like this article is piggybacking off the minimalism advocated in design schools. Minimalism is not the same thing as throwing out or ignoring features. How does the author reconcile their thesis with the fact that they're suggesting ignoring customer suggestions?<p>The attitude of if it ain't broke don't fix it is really you asking to be crushed by a competitor.<p>This said, the caveat here is when it comes to ideas. Better approaches to solving a problem are often simpler or more elegant, and require an out-of-the-box approach.
This is very timely advice for me. It sounds very easy in theory, but in practice it's been very difficult when you have lots of customers and leads pulling you in many different directions.<p>On the other hand, you can always have a distinction between products and companies. Especially when companies acquire other companies, just to add one more product to their portfolio (e.g. Google, Facebook.)<p>So no-one is saying that a single company can't work on multiple products at the same time. Sometimes it's just not very obvious whether something should be a feature or a separate product with it's own brand, landing page, and pricing.
This article was written with full fallacies. One example of this logical fallacy is because it doesn't count that features are done based on KPI. It's not about adding nonsensical features, it's about to increase KPIs, therefore, make even more business. Also, this rule doesn't apply to all products, so it's a fallacy. People who downvote this just doesn't understand or never carried a business seriously. They're just hedonists on design. That's all.
Hmm. So the device in your pocket that replaces a cell phone,radio,camera,flashlight,computer,pager calculator,day timer, music player and more is not the perfect counter example?
Me: "I am selling this product that does X very well"
Prospect: "Does it do Y and Z?. If it can do Y and Z, I will buy it"<p>Y and Z is different for each and every client. That's how products becomes bloated. It is demand from real world clients that demands features to be added before they can buy your product.
Has anyone used Notational Velocity / nvAlt? I've been reading about it all day (longingly -- sold my Mac a while back), and that's why this headline jumped out at me. I have tried dozens of apps and haven't found anything that even <i>comes close.</i>
<i>Google Search</i> is a good example of this. But this isn't always true. <i>WeChat</i> and <i>Facebook</i> can be considered as counter examples.