Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Low adoption of features and the sad realization

agyam.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: Low adoption of features and the sad realization

#21

Post by AnIdiotOnTheNet »

falcolas wrote: post #16
kstenerud wrote: post #4

People don't like it when things change. Change means things will break. Change means your way of doing things won't work anymore, and you'll have to waste time and money figuring out why. Change means that your fixes for when things go wrong won't work anymore. Change means months of hitting new edge cases. Change is scary. Once you have a solution that works well enough for your use case to succeed, your motivation…

I really, really wish that Slack would learn this. Their constant creep in features means I lose about a cumulative hour every other week trying to do something that I once knew how to do.

Aren't you glad you live in the era of "evergreen" software?

I sincerely believe IT people of the future will look back unkindly on this trend.

Re: Low adoption of features and the sad realization

#22

Post by otoburb »

donatj wrote: post #2

The number of features sales has told us some big sale hinged on, that subsequently no one has used, is very high. We actually restructured our entire product to win the sale of a very large customer who’s users didn’t fit perfectly into our metaphor. It was unwieldy and we basically rolled the whole thing back several years later.

>>We actually restructured our entire product to win the sale of a very large customer who’s users didn’t fit perfectly into our metaphor. It was unwieldy and we basically rolled the whole thing back several years later.

Did you close the booking because of that feature? That type of decision is sometimes dependent on the financial situation of the company.

Re: Low adoption of features and the sad realization

#24

Post by breakfastduck »

donatj wrote: post #2

The number of features sales has told us some big sale hinged on, that subsequently no one has used, is very high. We actually restructured our entire product to win the sale of a very large customer who’s users didn’t fit perfectly into our metaphor. It was unwieldy and we basically rolled the whole thing back several years later.

I could give almost limitless examples where we've been forced to drop everything and jump on implementing a hacky version of a new feature because sales convinced the CTO we were going to lose a major client if we didn't implement it asap.

They were usually never used, or used by an incredibly small percentage of users.

The platform ended up a complete mess because of the number of hacky features implemented and was a nightmare to maintain.

I'm sure we ended up losing more business due to the instability of the platform than we gained from adding these.

It's incredibly frustrating for the engineering teams who continually warned of the risks of rushing these things in without any analysis of usage.

Re: Low adoption of features and the sad realization

#25

Post by ekko_ »

craftinator wrote: post #19
falcolas wrote: post #16

Earlier quoted context omitted.

I really, really wish that Slack would learn this. Their constant creep in features means I lose about a cumulative hour every other week trying to do something that I once knew how to do.

Reminds me of Microsoft Office's latest big UI change, removing drop-down menus in favor of "toolbar ribbons". Went from being a power user / expert to a complete novice over night. I always wonder if there's a better way to make those types of transitions.

One favorable way would be to use the Unix Philosophy[0] to create a new product, rather than a complete re-design.

[0] https://en.wikipedia.org/wiki/Unix_philosophy

Re: Low adoption of features and the sad realization

#26

Post by Spooky23 »

donatj wrote: post #2

The number of features sales has told us some big sale hinged on, that subsequently no one has used, is very high. We actually restructured our entire product to win the sale of a very large customer who’s users didn’t fit perfectly into our metaphor. It was unwieldy and we basically rolled the whole thing back several years later.

How many people would be using it if you didn’t close the sale?

Video conferencing vendors would talk about this a lot until Zoom ate their lunch, then suddenly their principles about not adding features go away.

Re: Low adoption of features and the sad realization

#27

Post by damandloi »

donatj wrote: post #2

The number of features sales has told us some big sale hinged on, that subsequently no one has used, is very high. We actually restructured our entire product to win the sale of a very large customer who’s users didn’t fit perfectly into our metaphor. It was unwieldy and we basically rolled the whole thing back several years later.

I have seen product roadmap shifting in favor of sales requests and significantly changing the strategy. But hey, that's pivoting right?

Re: Low adoption of features and the sad realization

#28

Post by strogonoff »

> Customers tell the right problem, but never the right solution.

Thanks, I threw this on my phone’s lock screen.

I have a strong intuition along the same lines, but find it hard to phrase on the spot when explaining to stakeholders (and myself) why issues filed should not be considered actionable as is.

Re: Low adoption of features and the sad realization

#29

Post by abakker »

HatchedLake721 wrote: post #11
codeulike wrote: post #8

Earlier quoted context omitted.

I also hate demos of enterprise solutions. The feature details never matter to the financial buyer. What actually affects the financial buyer are product implementation delays caused by a major problem such as resiliency functionality or interoperability. Yes I've seen this a lot. The whizzy front end stuff in the demo is irrelevant.

I would say features never matter even for SMB demos. Sell the value and solutions, not features.

Yes, for the most part. People who need specific tools can usually find and buy the tools they need. Enterprise software is often great for the generics of "doing work" and often quite poor at the specifics of doing important, niche tasks.

Often, that is completely fine since the people doing those tasks can get their own tools and make things work.

Where it becomes hellish is when a large swath of users who are not able to self-service are given enterprise software which does not support the task they have to do, and then IT has to find a tool for them all to use, and then IT has to integrate that into the enterprise solution. It can get really messy.

Re: Low adoption of features and the sad realization

#30

Post by inetknght »

craftinator wrote: post #19
falcolas wrote: post #16

Earlier quoted context omitted.

I really, really wish that Slack would learn this. Their constant creep in features means I lose about a cumulative hour every other week trying to do something that I once knew how to do.

Reminds me of Microsoft Office's latest big UI change, removing drop-down menus in favor of "toolbar ribbons". Went from being a power user / expert to a complete novice over night. I always wonder if there's a better way to make those types of transitions.

> I always wonder if there's a better way to make those types of transitions.

Yes, there is. It's actually pretty simple and takes one step:

1) don't.

I can expand on that though with a few more discrete steps:

1) don't screw over people who already spent time (money) learning your product

2) don't screw over people who paid money (and time) for certifications in your product

3) don't assume that everyone will work better with the new flow

The toolbar ribbons tanked discoverability, readability, and usability.

Post reply on HN