That's fine, I care about 0% of my users.
Users only care about 20% of your application
91–100 of 199 posts
Re: Users only care about 20% of your application
#92I 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.
Re: Users only care about 20% of your application
#93Earlier quoted context omitted.
The best decision I ever made was moving from a company that acted on the whims of whomever the sales team spoke to last, to a company that had a strong product vision and was happy to say no to their customers on occasion. 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 yo…
Even if you weed out the willy nilly stuff, you will bump into Enterprise users that are actually correct. 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.
Are you talking about structural fundamentals or product features?
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.
Re: Users only care about 20% of your application
#94Earlier quoted context omitted.
Companies frequently moan about "re-training", but in my experience users of e.g. Word, or Excel don't need re-training, they need training. A large number of people how "Knows Word", can't use any of the feature beyond changing the font and font size, not even the "headings". 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. Especiall…
My state (Germany) recently switched away from Microsoft to open source solutions and public offices have week long delays due to employees not finding buttons they were used to. They expect a 1 to 1 copy of the Microsoft product. Training should be software independent. People need to be educated with computer basics, if they work in a field that requires the usage of computers. Having to go to some public office in…
> Training should be software independent.
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
Re: Users only care about 20% of your application
#95But 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.
Re: Users only care about 20% of your application
#96Earlier quoted context omitted.
Users are complete human beings, and their interaction with your product is a tiny slice of their life. They use your product to solve problems that they have. If the 80% of your product that they aren't using doesn't relate to their problems, they won't use it, even if they know that it exists. For example, I've never used Microsoft Word's mail merge function, even though I've known it exists for probably twenty yea…
But the thing is, being scared of something breaking is something we as software engineers have pushed onto users. 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…
That fear is very real, and I've noticed it on my team at work. Our (internal) help desk ticket work load has increased quite a bit over the past ~5 years or so, even though our user base hasn't changed much.
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.
Re: Users only care about 20% of your application
#97Earlier quoted context omitted.
Even if you weed out the willy nilly stuff, you will bump into Enterprise users that are actually correct. 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.
Are you talking about structural fundamentals or product features? 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 d…
You missed some universal ones that are both necessary, and a total pain:
- 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".
Re: Users only care about 20% of your application
#98Earlier quoted context omitted.
It's crazy how well Joel Spolsky's works aged. 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.
There's a few that have not, like his stance on rewrites. Apparently, if Joel's guru status had been properly respected, Netscape would be a powerhouse today, running on its Navigator codebase, because "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it." https://www.joelonsoftwar…
Rewrites can and sometimes do result in better code. They just don't usually help a business bottom line. And rewriting stuff didn't help Netscape anyway (but it did help Firefox, after Netscape went out of business)
Re: Users only care about 20% of your application
#99Earlier quoted context omitted.
Are you talking about structural fundamentals or product features? 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 d…
You missed some universal ones that are both necessary, and a total pain: - 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 develo…
It wasn't an exhaustive list, it was to articulate the difference between structural features, which all of those are, and product features, which are specific to your product.
Re: Users only care about 20% of your application
#100Earlier quoted context omitted.
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.
The best decision I ever made was moving from a company that acted on the whims of whomever the sales team spoke to last, to a company that had a strong product vision and was happy to say no to their customers on occasion. 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 yo…
It really depends on the industry. In a narrow vertical market with only a limited number of large customers, the vendors pretty much have to roll over and do whatever the customers demand regardless of product vision. Give the customers what they want or else they'll find a more pliable competitor. The power dynamics are different in more horizontal markets.