▲ 405 points
back
189 comments
At one SaaS I worked at, I spent a day or two on a foolhardy initiative to analyze our users based on the subset of features they actively used (hoping to reign in the complexity of the product to a few core archetypes we could design for, ideally eliminating some of the more annoying features on the way). The results weren't any better than a weighted random choice. Beyond the login page (and even that had a few customization options), every single person really did have a different 20% they cared about.
> every single person really did have a different 20% they cared about.
I have always wondered what would happen if someone had to invent spreadsheets from scratch, today.
Would conditional formatting and pivot tables get removed, because only 1% of users use them?
Would they feel supporting column, bar, line, area, pie and X/Y charts was just too complicated? That being able to customise the chart styles and colour schemes was just going to confuse users?
Would they think obscure jargon like 'vlookup' was too confusing, and difficult to localise internationally? Would they think formulas were too complicated to ever be a mass-market feature, as well as too difficult to input on mobile?
Would they discover 80% of office suite users don't use the spreadsheet beyond shopping lists, and replace it with a shopping list tool?
My theory is the modern software industry couldn't produce such a product. I don't think I've seen the industry produce a mass market product that requires a comparable level of user expertise in 20 years.
That’s why pushing back on features is important. It is super hard to remove them once they are in.
Most of the time it goes way that sales people promise something you build it „because that’s going to be great huge customer” - but after a year or 2 years that huge company moves away because people who originally wanted features moved to other jobs or departments and you are left supporting something some other customer started using by coincidence and is using it in totally wrong way but it somehow works good enough but still initial effort is not paid back and best would be to kill the feature.
Would you consider each 20% to almost be its own utility app (could possibly be a standalone app), or do you think each 20% were simply different workflows for the same app (each user prefers a particular workflow).
Very true.
But then you start selling to Enterprise and everything changes. Because one missing "hygiene feature"* can tank the the whole deal. And every Enterprise has a different one.
*like a toilet. It needs to be there. You use it 3 minutes per day. If it is not there, the house is uninhabitable.
As best I can tell we've never sold the same product twice. Product roadmap is "whatever the last person I spoke to asked for." And tech debt maintaining a grab bag of 5,000 almost-but-not-quite-entirely-production-grade "must have" features that the customers rarely if ever use despite claiming that not having it was a deal breaker, is, well, debty.
>You use it 3 minutes per day.
Damn you must get a lot of fiber.
I had started writing this in a new thread, then saw yours....
"Unless it's Enterprise users. Then 1000 Enterprises all care very seriously about 2 custom features no one else cares about. You had to do horrible things to your code base to support, that will only kick some poor dev in the face two years after you left, and a year after the customer churned."
At least a toilet is fairly standard these days. Not so much with digital only products.
I like to call these "windshield wipers." Rarely used yet essential.
> like a toilet... You use it 3 minutes per day
I think you may need to go see a doctor about that, seriously.
Pretty similar article to some old Spolsky blogposts:
https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
There's a marketing corollary that is called the Modified Pareto. Briefly that it's not 80/20 but 60/20. That is 20% of the heaviest or power users will consume 60% of the product. But that means the 80% will actually consume 40%. That's no longer small enough to ignore, so you have to cater to the light or infrequent user.
> Instead of fighting feature bloat, you can embrace the idea that your software will be used in ways you never imagined.
Which is why interoperability is the most important feature you can embrace.
I get the abstract sense reading this article that the main problem is software and sometimes version specific file formats. I don't mind cobbling three tools together, it's just that the tools seem to mind being used as part of a pipeline.
The dream of Unix is a tricky thing.
I've found that I'm not so good at anticipating how my work will be used, so I tend to "pave the bare spots"[0].
[0] https://littlegreenviper.com/the-road-most-traveled-by/#pavi...
Back in the days when desktop applications were the thing, I recall a (probably apocryphal) claim that nobody used more than 5% of Microsoft Office, but no two users used the same 5%.
So it always appeared to be bloated with features nobody ever used, but actually somebody, somewhere, was using every one of the features. I doubt the number was actually 5% or that usage of features was close to even, but the principal idea seems reasonable. Different users use different subsets of a product.
> Kagi didn't need to beat Google for everyone; they just needed to serve that specific slice of users perfectly. They focused on being the ideal 20% for people whose 20% Google was ignoring.
Yes, this is actually a critical insight into how to find product-market fit
> I often destroyed our home computer when I was a kid. Armed with only 2GB of storage, I'd constantly hunt for files to delete to save space.
Many people have a similar experience, but it's amusing that statements like this can roughly indicate your age and the systems you were dealing with... Mine is 40 MB.
I made a little hobbyist app for myself, and I think it's pretty nice and occasionally think about polishing it up and releasing it.
And the first reason I don't is because I'm not interested in promoting it, and it's pretty pointless to release to no one.
But the much bigger reason is because I'm not interested in implementing the remaining 80% that I don't use myself.
Yes, but many of them care about different twenty-percentses, so you probably still need the whole thing to keep the number of users you currently have.
BUT if you can find a feature that few people use, but which requires a lot of maintenance and/or ongoing development time, get rid of that bit and enjoy a higher ROI.
This is a good argument for the Unix philosophy's "do one thing" to avoid the bloat the author describes. E.g. vi, sendmail, and some bash for Word's mail merge. Or Emacs and some lisp. But then the onus is on the user to compose these tools to something that solves their particular problem.
20%? I imagine most of us use 0.1% of Jira. And it's the same 0.1% for all users in the org. The app is massive, millions of lines of code and we're effectively using like 60 SQL statements that run within it.
create issue, edit issue, move issue, update issue status, close sprint, repeat
But they don't necessarily care about the same 20%.
Another thing worth considering is that your users won't actually know what features they are going to get until after they've used the application. Users will install your app not based on what's in the app but based on what they think is going to be in the app after they install it. That's an important distinction. All that hard work you are doing on features won't actually pay off until after you convince people to use the app.
This is especially important when you are trying to make an MVP. Lack of features is almost never the problem that prevents users from installing and staying in your app. Usually the actual issues are with your messaging, marketing, etc. Or maybe your app doesn't do anything that actually interests users. Whatever it is, your feature set probably has nothing to do with it. Adding more features won't solve these issues either. This sounds simple but I've seen companies get this wrong.
The simplest MVP is simply trying to get users to sign up before you even have anything implemented. It's a common pattern to validate ideas.
The best confirmation that your messaging is right is users getting disappointed after they sign up. That's still bad but now at least you know that at least the messaging is right and that you can convince people that what your selling is worth having.
This of course leads to another issue: launching your app before it is a proper MVP for whatever your messaging promises. If you promise lots of things that aren't actually there, you are probably setting people up to be disappointed at least somewhat.
A related point here is that many features are nice to haves that are hard to monetize because they aren't that essential. Especially with SAAS applications there are usually a lot of nice to haves that people don't actually want to pay for. Treating your customer wishes as requirements is going to need a lot of scrutiny. Do they actually value what they get? Would they pay for it? Does it solve some important pain point? Etc. It's more important to understand why they ask for stuff than to exactly deliver what they ask for.
I am reminded of an episode of Seinfeld where Jerry gives his dad an expensive, multifunction PDA called "The Wizard" but his Dad doesn't immediately see the use. Jerry explains it can do all kinds of things, for example, it has a calculator he can use to calculate tips at restaurants, leading Dad to conclude it's a $200 tip calculator. Jerry keeps protesting "it does other things!" and the old folks act like they can't even hear him.
While hitting 100% utilization will probably never happen in any significantly large application, in my experience almost every application has a good 10-30% of it that remains unused because they are extremely unintuitive to anyone who isn't on the development team, has a absolutely awful and inefficient workflow, or is so basic that it would only be of value to companies that would in no way be able to afford that application in the first place.
They also care 0% of how it was written, unless it stands on their way, hence why nowadays we have applications of various quality levels, when looking under the hood.
More interestingly, users care about 20% of each of the other applications they are trying to use. Not only is it frustrating for them to be bombarded with the 80% of your app they don't care about, it's frustrating when they can't easily replace that 80% with the other apps they prefer.
The entire premise of an "application" is, in my opinion, a huge mistake. Each application, by virtue of being just that, is designed to be a silo of functionality and usability. An application monopolizes the functionality for the use case it was designed to apply to. Not only does an application hold its functionality hostage, it insulates itself from the functionality of other applications. This creates a brittle system with incredible overhead.
There's a reason many of us prefer to use a terminal emulator and shell utilities: they are designed with the opposite goal, to collaborate with each other as much as possible. That's often worth dealing with the ~40 years of cruft that the shell comes with, but accessibility could definitely be improved.
> Slack works similarly with its integrations. Discord does this with bots and servers. The platform provides the foundation, but users craft their own experience on top of it.
Not really the articles core point, but to me at least, those two products are full of loads of stuff I don't want!
I thought VS code was a good example, I'm curious about if anyone has other examples that they think do modularity well?
Pluralism, huh. I suppose this applies to games, too, the different ways people enjoy the same game.
“ your software will be used in ways you never imagined.”
This is actually a lot of fun to discover.
Correct, but each may be using different 20%.
In the enterprise software (think ERP), each user may be using only 0.01% of the overall functionality. And the entire company maybe using only 1% of the functionality.
I like to call this approach MISS (MISS – Make It Stupid, Simple) or better:
Make
It
Stupid
Simple,
To
Experience
Revenue
= M.I.S.S.T.E.R.
https://untested.sonnet.io/notes/miss-make-it-stupid-simple/
This is why AI development will be huge in the “Buy vs Build” space… Businesses (with a capable tech team)can build the 20% of the SaaS they need, and stop paying for the 80% every single month.
I wonder of the 80% how much would they care for it if they had time to discover and learn it. And how much they really just will never care (unless their role / conpany changes).
"Your application"? That post talks about Microsoft Office. That's the giant corporation + the government's application. Give LibreOffice as an example if you want to talk about large apps that can be "yours", at least partially.
And indeed, we should make sure the apps we write are FOSS, so that those users who care about those various 20%'s feel that its also "their application", and may actually help out - with money or code or time.
I kinda miss the unix philosophy... one tool for one job. A PDF reader should read PDFs, there's no need for it to have its own (possibly paid) cloud service and an AI chat bot.
I do get why some integrations are beneficial (eg. office software with text editing, spreadsheets and a database, so you can generate eg. letters with data from a database, etc... but every service needing its own cloud and adding a useless AI chatbot is just a useless overkill for me.
I don't think we should chase simplicity/austerity in our products, but we should chase elegance. Ideally, features should compose so their utility multiplies instead of sums. The program should be fast and have a UI that's easy to learn. That kind of thing. There's a difference between being big and being bloated.
I guess most people don't care about our applications at all. They care about how it solves a problem they want or need to have solved.
That is the starting point. You can get people to care if your application becomes a great tool for the things they want to do. And good tools don't get in your way.
I'm building things for internal users, and they are quite demanding. Many features don't get used often (as is obvious), but may be critical for serving different clients. The software is also open to external users, and they really stick to the basics.
>You can't predict exactly which 20% each user will need, but you can build systems that let them find and enhance their own slice.
If your users are programmers, engineers or scientists, fine.
If your users are not the above, fuhgeddaboudit. You will end up in support hell.
That's why is so crucial for any great product (or striving to be) to have reliable usage metrics - you then have reliable data to decide what's worth focusing on and improving and what's not so much
With AI type tools though it’s more likely than ever that the 20% each user group cares about is a different aspect / feature of your application
From another angle, user doesn't need 80% of your application. This is a key to keep software simple, fast, and convenient to use. The downside (for some) is that because every users's needs are different, software needs to be tweaked and compiled by the end user.
Notable example of this approach is suckless' programs[1] such as dwm, dmenu, and st.
I also took this philosophy and wrote hat - a hackable text editor[2]. Mostly because tweaking neovim was not a pleasant experience and took more steps than it should.
new | threads | past | comments | ask | show | jobs | submit
I only use one of these links regularly, another one occasionally, and the others, if I happen to press it, it was probably a misclick. So about 20% seems like a good approximation.
I didn't read the article but in my experience, 80% of the application are parts that you rarely touch, config stuff and "LEFT JOIN" stuff.
There is always one or two parts where all data comes together and that is the heart of your application. Yeah those are the parts your users care about and pay you to make.
This should really credit Joel Spolsky somewhere: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
Yes but you still need those useless features to sell
Indeed, it really fits the 80/20 rule.”