Users only care about 20% of your application
idiallo.com
idiallo.com
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.
Evernote’s 5% problem offers a cautionary lesson to tech companies
Then also you have ongoing costs of maintaining the feature that no one usually accounts for. Even if customer participated financially into creating the feature when they leave you are left with maintenance.
Obligatory xkcd reference:
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.
This is exactly what Joel Spolsky did:
> What was I talking about? Oh yeah… most people just used Excel to make lists. Suddenly we understood why Lotus Improv, which was this fancy futuristic spreadsheet that was going to make Excel obsolete, had failed completely: because it was great at calculations, but terrible at creating tables, and everyone was using Excel for tables, not calculations.
... so he went on and created Trello.
https://www.joelonsoftware.com/2012/01/06/how-trello-is-diff...
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.
It's a lot less exhausting when you're not changing priorities every quarter.
You also avoid the soul crushing experience of working really hard, crunching to get a feature out, only to realise your time was given away free to land a deal. Sometimes a deal that fell through anyway.
They will mention something you know you should have added but always wrote off as "bloat" or "not really really really needed". Those things start happening more and more the moment you are doing $100K plus deals.
Because I agree about the fundamentals, the things enterprises tend to care about:
- SSO / SAML / auth integrations
- ISO Certifications
- Regular Pen tests
- Localisation support
- APIs ( that they'll never use )
- Bulk operations
- Self-hosting ( or at least isolated / non-shared application cloud hosting )
Get these and similar right and it's the difference between landing enterprise or not.
But if you're talking about features specific to a product, or custom products for a platform, that's a very different thing, and that's where the great distraction can come in. That's where you'll end up developing features that go unused, and it's these which aren't so consistent across customers.
Imagine you make washing machines and get a request for:
" This Washing machine must have a pre-set button for a 57deg 38.5 minute wash. Without that, I couldn't consider this machine ".
You try to argue that you let users define their own pre-sets, and that they can set up their own pre-set for that cycle. But you're denied by the person in sales who insists that they need exactly that as a first-class button on the front of the machine.
That's the level of petty that some large customers will try. In some way, it can be seen as a good sign that they've engaged with your product, but sometimes you wonder if it's just a trial balloon for seeing if you'll put up with the unreasonable.
- Teams & Fine-grained Permissions
- Audit logging
- SOC 2/3 compliance
- Data wiping / retention / data policy management
- Reporting
- Cookie law crap (GDPR & CCPA)
- Myriad forms of custom product tiers & billing arrangements
I'd put these above several of the items on your list, and in my mind, they fit into the category of "things a developer calls 'bloat', that are actually necessary for enterprise sales".
In short, this is the kind of stuff that I think fits the parent comment's categorization: it drives enterprise sales, engineers hate building it, and it never really ends because the maintenance and detailed feature requirements change with almost every contract.
I’m looking for a TV. I buy after careful research, so there’s a 90+% chance I’ll end up with the TV I have in mind before walking into the store.
One device we frequently use (Linux) doesn’t send the “switch to me” hdmi signal when we start using it, so the “switch input” button on the remote is crucial.
The front runner has a One Button (TM) remote. “What fresh hell hast thou wrought?”, I ask.
On page 1, the manual says to change inputs you need to press the gear button, navigate through the settings menu to “inputs”, and then find the right input from there.
Ok, so do I get the crappier panel to avoid the settings menu every time I turn on the TV, or not?
Thankfully, page 10 has a picture of the remote, and it has a quick change input button, so that’s OK.
On top of that, I want the TV to be a dumb TV.
There’s no mention of this in the quickstart guide, but it has “Basic Mode” that which is that, except that calling something “Basic” is right up there with most four letter insults with kids these days.
As a bonus, after reading the manual, I also honestly can’t tell if it’s possible to have four hdmi inputs and also variable volume audio out at the same time.
If you’re going to produce differentiating features (or your competitors are differentiating you via enshuttification) you need to make that clear pre-purchase.
In enterprise it’s at least 10x harder to get this stuff right because you probably don’t use the product on a regular basis, and also, there are many more features.
What a lot of these HN programmers seem to miss, is it's not about what you or your application provides. It's about what your competition is willing to provide. If you don't have much competition then that's great, but the moment your 100k-10m paying user starts testing the other software your C-levels and sales people are going to have the programmers locked out of the building the moment they say they won't write a feature.
Small companies often have the CEO in a product position in my experience.
Still isn’t ideal though and more to your point, how they actually do the product role is really what matters. I.e. chasing shiny objects.
We landed our largest customer by gar a few years back, and we pushed back hard. However we had good arguments why, and explained why changing their workflow would be much better or offered some other approach to solve the problem that didn't involve a new bespoke and brittle feature.
On the other side were a team that knew the processes well and understood our arguments.
After they went live, the management thanked us for helping them improve their organization.
On the other hand there have been cases where decisions is made by leaders so high up they have no idea what's going on by those that need the tool, and aren't interested in spending time or effort on it. Not much you can do then.
edit: Though sometimes they learn. We've had a few customers who we said no to since their wishes were not really feasible, and who selected others and failed, and failed again, before finally ending up with us, on our terms.
I've worked in both types of companies, and the ones where sales dictated what we worked on this week were universally awful.
The reality is I only get paid because of those deals, and the post deal tech-debt sprint never happens.
So the work has to get done and if sales doesn’t give time for it to be done properly then in 3-6 months velocity will drop and the sales pipeline will dry up.
Any company that can’t understand that is not a long term company I want to work at.
The solution is for the cost of these new additions to come off the top of the deal (pre-commission) they are signing to re-align the incentives.
I’ve worked at consumer facing companies but also other enterprise SaaS and have to say I’ve never seen it done like this before. Just ruthless pursuit of features over polish, craft, etc.
Can your customer switch to another product, yes or no. If no, then polish won't happen.
Do customers actually value 'real' polish and not just a slick looking UI? If no, then real polish doesn't matter.
As a software writer you'll get your ass kicked into the ground by another company that writes catchy features and nice looking interfaces 9 times out of 10. So few actual customers know out to measure 'polish' that it's almost a non consideration.
I think you may need to go see a doctor about that, seriously.
Damn you must get a lot of fiber.
"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."
https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
To be fair, the author may not have been aware of these previous posts. I find that “kids these days” don’t really read the classics.
For those not aware, Joel Spolsky, Steve McConnell, Don Norman, and a whole bunch of others, really thought hard about our vocation, and wrote down their thoughts.
Might be worth a gander.
Some of them ended up proving wrong (like he once predicted that making graphic cards would be a very thin margin business[0]), but most are still true today. Probably truer than when they were written.
[0]: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v In his defense, by the time 'video chips' were totally different things from today's mighty 5080.
Consumer GPUs really are not where the money is. It’s only a tiny fraction of Nvidia’s revenue, and much lower margin. Datacenter GPUs are where the volume and margins are.
[0]: https://nvidianews.nvidia.com/news/nvidia-announces-financia...
Out of $46B about $41B is from datacenter.
It was very well done and strategic on their part but realistically without that they are not that much better than AMD and the margins would be much smaller if it had 1-to-1 compatibility as an x86 has.
Also, since improvements have been plateauing and entry level is becoming enough for more and more people the margins are going to diminish even more, high-end GPU is going to become even more niche overtime IMO.
So, I'd say he is not wrong in spirit, the timeline is just bigger than expected.
People know they should do coding tests in interviews, but not how they're designed to find smart and get things done.
People know they should code clean, but not how it only needs to be clean enough to spot dangers.
Some companies are paying super high prices for interns, and then don't try to integrate them into their recruiting funnel.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
There is of course some truth wrapped up in those thick layers of punditry, but even today that article gets trotted out as some kind of Revealed Truth of Software Engineering to be swallowed and digested without qualification.
(Edit: I agree that from-scratch total rewrites are rarely a good idea, and should require blindingly obvious justification at the very least. I still cannot take all the points about Old Code at face value, since rewrites often come about after Lots of Bugs have been found and continue to be found)
In-context, his point is pretty obviously (I think) more like "given a piece of code, it's never better to rewrite." His point is not that newer software can't come along and be better than old software. Rather, all other things being equal, rewriting is an inferior development choice.
Rewrites often do work out in the long term. However you end up spending 10 years on the rewrite and those are 10 years where the old thing isn't getting as many features (everyone knows it is dead long term so they only invest in the most important features thus allowing your competition time to catch up). Worse those, in 20 years (10 years after the rewrite replaces the old thing) the rewrite is showing age because of things you wish you had done differently.
Which is why I advocate for fixing the old code in place over time. No matter what your best ideas while turn out to be wrong in some way. Architecture decisions that seemed good turn out of have downsides. Languages that go obsolete. APIs everyone uses that you realize should have been done different (If they are only used in one places that is an easy change). Core data structures that no longer meet your needs, but you can't change without touching a million places that update it. You will need a long term effort to fix those mistakes whatever they are. Sure it will take longer to get the old thing to where it needs to be than the rewrite, but you are not saving anything as the new thing will have different mistakes that you will regret in 10 years.
Also the above is in context of a large program. My program to draw names for the family Christmas drawing is easy enough for anyone to write from scratch in an hour so who cares. When your are on a project that costs over 1 billion dollars to write you have different constraints (some of you are on small projects that it is better to write from scratch each time)
In our real timeline, Netscape did rewrite. During the rewrite their market share halved. And they died a few years later. So yeah, the lesson here is if you're okay to let your company just die and rebuild a new one, it's perfectly fine to rewrite the whole codebase.
CNNs and LLMs became feasible and viable much later. People in the 1500s would also have bet on the automobile and the Wright brothers. Right after drinking coffee from their microwave.
That said, I think your overall point isn't affected by my idea. Even a great mind can be wrong occasionally. He doesn't have to be right every time.
1. Observation: 80% of users only interact with 40% of the software
2. Conclusion: lets cut part of that 60%, since those are rarely unused features
3. Observation: 80% of users only interact with the 40% of the remaining software
4. Conclusion: lets cut..
You get the idea. In reality the most important thing is that users perceive your software to be able to solve their problems. If you want them to spend money you need to give them the feeling your software could also solve their problems if they came around in a slightly different shape. And those different problems may be covered by the unused features.
If you for example look at 3D software, that bone rigging system may be used by only 2% of users for 1% of the time, but a much higher fraction of users may not even consider your software if it doesn't have that feature in comparison to other software, even if they don't need it yet.
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.
[0] https://littlegreenviper.com/the-road-most-traveled-by/#pavi...
But it is worth noting that this can have trouble scaling in a complex enough environment and can be more expensive in the long run.
I’m not a huge fan of the CMMI, but Level 5 prescribes pretty much exactly that, though applied to the production process, as opposed to the end product.
Anyone can walk through a minefield, as long as they're patient, and don't mind walking past a lot of body parts.
Omaha Beach was a nightmare on D-Day, but a lot less challenging, in the next few days.
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.
“Without usage data, we can not guarantee that all features will remain in the software.”
Yes, this is actually a critical insight into how to find product-market fit
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.
But if you think about what's happening today, things have plateaued. Most people since at least 2005 probably have laptops, and generally those hover around 250GB, 500GB, 1TB of storage (with the bigger difference being top of the line/more expensive configurations, than with generational differences). More likely people now identify with 64GB, 128GB, 256GB for smartphones and tablets.
We will soon reach a point of mass market computation where the "mature" times are longer than the early years (1980 - 2005 = 25 years, 2005 - present day = 20 years and counting).
Large leaps, at least in storage, don't really happen (50MB to 1GB is <<extremely>> consequential, 500GB to 1TB is meh.
I put Windows 10 on it when it was released and used it for a Plex Server until around 2021. It wasn’t until last year that base MacBook Airs came with more than 8GB RAM and they still come with less storage than that. Not to mention that low end PC laptops still come at a lower resolution than my old Dell did.
Not a week later I was back to figuring out what to delete to free up some space for a new game...
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.
Occasionally I check in on it, and see it's still getting pageviews, clones, and sometimes forks. A few people raised issues about something beyond the 20% I built, and I say "go do it yourself", and then they do but at least they didn't need to start from scratch.
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.
I love Vim (RIP Bram, thanks for all the fish), but it's a tool for the less than 1% who loves that kind of thing.
Most people won't learn the tool because they see it only as an anecdotal detail bringing hindrance in their quest to "something".
create issue, edit issue, move issue, update issue status, close sprint, repeat
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.
That’s kind of the article’s main point.
Did you write that entire comment based on the headline only?
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.
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?
Some might use the debugger and some might use extensions and some might use AI and so on ... but there's nothing 80/20 (or 20/80) about the core of the product, and that seems to directly contradict the article's point.
This is actually a lot of fun to discover.
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.
Make
It
Stupid
Simple,
To
Experience
Revenue
= M.I.S.S.T.E.R.
https://untested.sonnet.io/notes/miss-make-it-stupid-simple/
For product like Microsoft Office (or whatever it's called these days) 20% is ludicrously high. I'd guess more in the 1% - 2% range. Especially Word is way to complex for the needs of most people, Wordpad covers the needs of most home users. I also thinks that's where the recentment for the remaining features come from. It's not that there's some number of feature hiding in a corner that's the problem, it's that almost the entire application is "useless".
I’ve lost count of the number of Word documents I’ve had to edit where the creator completely ignored styles and formatted every element individually.
Working with styles is relatively complicated (not hard, but distinct form pure wysiwyg picking font&size and hoc) and for most small documents doesn't have much of a benefit in the result.
For larger documents or professional work it's relevant, but by then people are used to adhoc ways
It makes you yearn for latex and xsl-fo(!).
If you want me to do it The Right Way, make sure that's a happy path, or I'm going to stop doing it.
Ironically, at the time the corporate templates didn’t even use styles. It was just a 5 page doc with all the different things a person might use, and we were expected to copy/paste what we wanted to get the proper formatting. This wasn’t officially stated, but that was the only way I could see to use it.
Agree, and I see this problem in both non-tech users and even sysadmins on my team when I'm looking for new hires.
I'll get resumes of people that are seemingly great, but they really only learned a few specific tools and had no general understanding of theory or even what those tools were doing. I don't care if you "know" Ansible, I do care if you know why we use orchestration management in the first place, and what those ansible playbooks are doing. Tools come and go, but the principles remain.
Likewise with general users. Don't train how to use Word, train how to communicate clearly, format ideas, and share them with others using a computer. The tool is irrelevant
--- start quote ---
Beyond the top 10 commands or so, however, the curve flattens out considerably. The percentage difference in usage between the #100 command ("Accept Change") and the #400 command ("Reset Picture") is about the same in difference between #1 and #11 ("Change Font Size")
--- end quote ---
The whole series is great: https://web.archive.org/web/20080316101025/http://blogs.msdn... and there's a presentation, too: https://www.youtube.com/watch?v=AHiNeUTgGkk
“Knows Word” and “familiar with Windows” are boilerplate résumé spam to match the keyword selection. No one actually is expected to follow up on those bullets.
Sometimes, there is indeed a new feature that could solve a problem that they have, but they don't know it exists. I've seen a lot of pop-ups in software that try to tell me about new features, but I never read them, because I'm always trying to do something else when they appear. Emailed newsletters also don't work, because the marketing people who design them always make them look like advertisements.
Finally, many computer users are deeply incurious about their computers, and are often too scared of breaking something to try an unfamiliar feature.
You click a control and something happens - you don't like it, but you don't know what turns it off or undoes it. There's no global state rollback. It's like the sheer terror those "don't show me this again" buttons instill - the concept is frightening even if I'm kind of annoyed by the message, and they rarely if ever include an explanation of exactly where to do to turn the control back on.
People are even afraid to do basic troubleshooting out of fear of breaking something and not being able to easily rollback to the point that something as simple changing the sleep settings on a computer results in a help desk ticket.
Low cognitive load should be a major goal, and that doesn't mean the app can't be feature rich. Make the app very fast, or at least hide latency from the user. No esoteric icons, instead default to plain text. If you have icons, no artificial delay between mouse-over and tooltip. No smooth scrolling. No excessive whitespace. No elements that move around while the page loads. No scrolljacking. And actually use your app so a random user like me can't find multiple bugs in it.
Chatgpt website is a good example of how to tick some of these boxes to achieve low cognitive load, despite being feature rich. It's very fast, and mousing over an icon displays the tooltip immediately. Although they have a few UI bugs that they need to fix, I would give them an 8.5/10. Gemini website is an example of how to tax cognitive load despite being feature poor and "simple". It's very slow for large contexts, it scrolljacks, and it has numerous bugs. I would give them a 2/10, partly due to the fact that it hasn't noticeably improved for over a year since I started using it, despite being one of their flagship products.
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 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.
Once you have a pdf viewer users want rotating pages, then bookmarks, then highlights, then form filling, etc.
That “just a pdf reader” is strictly worse than every pdf editor (which have to meet the minimum requirement of a pdf reader).
Apple’s Automator and Preview combo for me are indispensible and perfectly follow the Unix ideal. Automator composes well, and Preview does all the pdf editing well, and together they’re excellent software.
The version of Preview Apple just released on iPad is however basically just a reader, and do it hasn’t made itself relevant to any of my workflows or needs.
Full featured plus composable. That’s the sweet spot for the best apps.
Side note: I’m surprised there’s no ffmeg or imagemagik for pdfs (maybe there is?). Someone should build that.
Or one that I've actually hacked into a few contexts already: What if every multi-line text field could be replaced by a neovim buffer?
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.
If your users are programmers, engineers or scientists, fine.
If your users are not the above, fuhgeddaboudit. You will end up in support hell.
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.
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.
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.
No I didn't read the article but the punchline is trivially obvious.