Live data from Hacker News

Low adoption of features and the sad realization

agyam.com

31–40 of 44 posts

Re: Low adoption of features and the sad realization

#31
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…

>>or used by an incredibly small percentage of users.

Sometimes it is not the number of users that need the feature but just 1 or 2 very important users... The ones that have the final say over Yes we use this, or no we do not

Re: Low adoption of features and the sad realization

#32
post #31

Earlier quoted context omitted.

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…

>>or used by an incredibly small percentage of users. Sometimes it is not the number of users that need the feature but just 1 or 2 very important users... The ones that have the final say over Yes we use this, or no we do not

Yeah that can certainly be true - unfortunately we often found that the very important users to us didn’t see us as important as we saw them, meaning we’d implement these hacky features on their request on short timescales only for them to then refuse to integrate for weeks - we could have done the feature properly had we not been pressured into getting it over the line so soon.

Re: Low adoption of features and the sad realization

#33
i've seen well respected product managers ship features that go unused. it seems to be pretty common.. but i think what is uncommon is talking about low adoption, it's not a pretty conversation to talk about for anyone. but a product manager that does talk about it and wants to refine the roadmap strategy is really valuable.

Re: Low adoption of features and the sad realization

#34
post #31

Earlier quoted context omitted.

>>or used by an incredibly small percentage of users. Sometimes it is not the number of users that need the feature but just 1 or 2 very important users... The ones that have the final say over Yes we use this, or no we do not

Yeah that can certainly be true - unfortunately we often found that the very important users to us didn’t see us as important as we saw them, meaning we’d implement these hacky features on their request on short timescales only for them to then refuse to integrate for weeks - we could have done the feature properly had we not been pressured into getting it over the line so soon.

Ahh yes the old "Hurry up and wait"... been there too many times....

Re: Low adoption of features and the sad realization

#35

Earlier quoted context omitted.

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 b…

Something needed to be done though. I use LibreOffice every few weeks, they still use the toolbar UI by default, and it's faster to google where an option is than to go hunting for it.

As a dev I'd love a ctrl+p sublime style search.

Re: Low adoption of features and the sad realization

#36

Earlier quoted context omitted.

You seriously have to ask? Pop-up blockers were invented for a reason. Things that jump out and demand your attention are annoying, period.

Thank you for your feedback. I have removed the pop-up for now. No warning about the ugly readability experience in dark mode.

if you really care about it, can already detect it, and show a pop-up, surely it'd also be doable to show a header or something?

as others have said, the pop-up is really the issue here.

Re: Low adoption of features and the sad realization

#37
post #5

I work for a large company and when discussing a product with a startup/small company, usually in a relatively new market, I've noticed interesting behaviour: Before I meet, I try to think of ways their product could be provide benefit including non-obvious ones. So I ask if their product does this or that, and why I think it could be useful. Some companies tell me: it is on the road map, or why they think the featur…

> Other companies take it as a feature demand. I find this bizarre, because I have barely (or never) used their product.

This is something that I've seen constantly from the PMP/offering manager/product manager types and have been in the room where it happens. The thing that is utterly baffling is that it's usually a vague intent from an interested but not current user but then the person writing down these imagined requirements asks zero follow-up questions in a complete disservice to the user. So for example 'does your product use AI' or 'do you have a slack integration' open ended questions turn into firm requirements 'to close the deal' internally but with a completely headless goal. When I am usually in the room I at least give the customer the dignity of trying to work out what their idea/perceived benefit is with them so I can accurately transmit the knowledge to the team. Often someone more experienced with the product's offering can solve the real customer use case with existing features that just doesn't have the same label.

My favourite firing of a software company was when they expressed that they were refocusing from clear stability initiatives to machine learning driven analytic dashboards. This was even though this was a customer retention meeting company to company that was spawned over threats to not renew... because of stability issues.

Re: Low adoption of features and the sad realization

#38
post #5

I work for a large company and when discussing a product with a startup/small company, usually in a relatively new market, I've noticed interesting behaviour: Before I meet, I try to think of ways their product could be provide benefit including non-obvious ones. So I ask if their product does this or that, and why I think it could be useful. Some companies tell me: it is on the road map, or why they think the featur…

What do you think is a happy medium between the technical buyer and the financial buyer if not a demo?

My company is having trouble with this right now, in that we built a tool for the users with some higher level features managers would like, but it's still 3 ranks below the person purchasing the software. Even pitching it as a cost savings, they reply with "oh, my teams don't have trouble with that so we're not wasting money on it" then someone lower usually cuts in and says "well, we've been having trouble with it recently..."

Post reply on HN