Users only care about 20% of your application

idiallo.com

396 points by jnord 5 days ago


hansvm - 3 days ago

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.

tnolet - 3 days ago

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.

CodesInChaos - 3 days ago

Pretty similar article to some old Spolsky blogposts:

https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...

https://www.joelonsoftware.com/2006/12/09/simplicity/

prasadjoglekar - 3 days ago

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.

https://marketingscience.info/value-paretos-bottom-80/

themafia - 3 days ago

> 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.

ChrisMarshallNY - 3 days ago

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...

a4isms - 2 days ago

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.

davedx - 3 days ago

> 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

reinvent42 - 3 days ago

> 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.

sharkjacobs - 3 days ago

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.

lo_fye - 3 days ago

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.

ryangibb - 3 days ago

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.

throwmeaway222 - 3 days ago

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

jillesvangurp - 3 days ago

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.

isk517 - 3 days ago

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.

oldandboring - 3 days ago

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.

pjmlp - 3 days ago

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.

thomastjeffery - 3 days ago

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.

benrutter - 3 days ago

> 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?

card_zero - 3 days ago

Pluralism, huh. I suppose this applies to games, too, the different ways people enjoy the same game.

g42gregory - 3 days ago

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.

vjvjvjvjghv - 3 days ago

“ your software will be used in ways you never imagined.”

This is actually a lot of fun to discover.

einpoklum - 3 days ago

"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.

rpastuszak - 3 days ago

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.
i.e. keep removing features until the idea fits in your head, the value can be explained concisely to a small group of people to whom it'll just 'click'.

https://untested.sonnet.io/notes/miss-make-it-stupid-simple/

chrisrickard - 3 days ago

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.

nenenejej - 4 days ago

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).

ajsnigrutin - 3 days ago

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.

tormeh - 2 days ago

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.

ivanjermakov - 2 days ago

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.

[1]: https://suckless.org/

[2]: https://github.com/ivanjermakov/hat

atoav - 3 days ago

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.

hermitcrab - 3 days ago

>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.

tgv - 3 days ago

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.

BinaryIgor - 3 days ago

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

- 3 days ago
[deleted]
r_singh - 3 days ago

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

73189822 - a day ago

Indeed, it really fits the 80/20 rule.”

listenallyall - 2 days ago

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.

CodeCompost - 3 days ago

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.

ojbyrne - 3 days ago

This should really credit Joel Spolsky somewhere: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...

nextworddev - 2 days ago

Yes but you still need those useless features to sell

renegat0x0 - 3 days ago

Whoa. That is 20% more than I thought

worthless-trash - 3 days ago

Users dont care about 1% of my application, lets be real.

rpigab - 3 days ago

That's fine, I care about 0% of my users.

nottorp - 3 days ago

Yes but not all users care about the same 20%.

- 3 days ago
[deleted]
nubg - 3 days ago

[flagged]

api - 3 days ago

For different users it can be a different 20%

ltbarcly3 - 3 days ago

If only they could agree on what 20% so we wouldn't have to build the rest.

No I didn't read the article but the punchline is trivially obvious.

newsclues - 3 days ago

What percentage of an app do power users care about?