
Low adoption of features and the sad realization - damandloi
https://agyam.com/low-adoption-and-sad-realization/
======
dade_
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 feature
will never be used, or an explanation of why it is extraordinarily difficult
to implement. Cool. You probably know what you are talking about and I learned
something interesting (to me anyway).

Other companies take it as a feature demand. I find this bizarre, because I
have barely (or never) used their product. Some almost seem insulted that
limitations in their product are being raised. Not my intention, and that
raises a huge red flag, for "The lady doth protest too much, methinks"

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. Extending the timeline affects other
projects, the budget, and the pushes out the timeline for the benefit to be
realized. Edge cases and niche features don't, the business will usually sign
off on production with an agreement that these issues will be resolved by the
vendor. Rarely do the big problems arise in demos, but the small manageable
ones do. The technical buyer is thrilled that their pet requirements are met,
and the financial buyer is furious that their programme was a failure.

My 2 cents.

~~~
vsareto
People get offended by unsolicited advice all the time. Regardless of your
intentions, that's how some people will perceive it. It's worse if they know
you haven't used their product, because that makes you seem like you're
flippantly handing out advice. You're likely giving off the impression that
you think you're right without any experience or consideration of their
product.

None of that actually discredits your suggestions though; you could be right.

As a counter example, some people are PoC||GTFO types who wouldn't take
offense easily but would rather punch holes in your argument. Seems like you
might be jumping in with the advice before you know if it's that kind of
environment.

~~~
Gibbon1
I have thing thing. I think if you're going to punch holes in someones
argument then you should also commit yourself to figuring out if it can saved.
Otherwise you're just being an ass. That said one thing I'm aware of is one
should be careful when giving advice that you aren't dragging their vision
through the mud either.

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

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

~~~
syshum
>>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

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

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

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

~~~
passthefist
FWIW this is called the
[https://en.wikipedia.org/wiki/XY_problem](https://en.wikipedia.org/wiki/XY_problem)

~~~
strogonoff
XY problem is invoked when someone is asking for help, to get to the bottom of
the problem.

I am dealing specifically with product users or prospective users who,
possibly via stakeholders, request new features to implement.

The tip I quoted is very helpful with the latter as means of explaining why
feature request should not be treated as actionable to stakeholders. Until I
manage that, neither XY nor any other approach can be used.

------
kstenerud
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 to adopt change goes through the floor. The bigger the
organization, the worse the worst case scenario, and the lower the appetite
for change.

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

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

~~~
inetknght
> _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.

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

------
ChrisSD
Constant change is a nuisance. When I'm working on a task I want to be able to
concentrate on doing that task, not relearning my tools for the umpteenth
time.

If the new feature doesn't affect my current workflow, then great! I can
ignore it until I'm ready. The trouble, as the article notes, is the
application making me aware of this brilliant new feature. Often application
developers do this either by breaking a workflow and forcing interaction with
the new feature or otherwise nagging me while I'm wanting to do something
else.

Education outside of the application (tutorials, good documentation, blogs,
etc) is perhaps a better way of driving adoption of features.

------
dan_can_code
Nothing to do with the content but the pop up for 'lack of dark mode
optimisation' on this website is more annoying than the actual lack of dark
mode optimisation

~~~
damandloi
Sorry for that. May I know what annoyed you the most? The old style popup (JS
alert) or the presence of the popup?

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

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

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

------
dcolkitt
Seems like yet another manifestation of the Pareto principle.[1] 80% of
software value comes from 20% of the features.

[1][https://en.wikipedia.org/wiki/Pareto_principle](https://en.wikipedia.org/wiki/Pareto_principle)

------
richard_g
A good sign is when people are trying to do something using a complex
workaround because they need it that badly, and you can implement a change to
make it easier.

If they haven't even attempted to do it now, chances are they won't after you
implement a new feature.

------
JoeAltmaier
Good advice to consider customer feedback carefully. Its been said, ask a
farmer what they wanted in 1900, they'd have said "A horse that can pull more
weight and eat less hay". They'd never had said, "a tractor".

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

------
bumbledraven
It would be interesting to see the year each company graduated from YC. There
might be a cluster of Ruby startups in a particular time period, and maybe
many of the Go startups came later.

