Low adoption of features and the sad realization
agyam.com
agyam.com
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.
Yes I've seen this a lot. The whizzy front end stuff in the demo is irrelevant.
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.
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.
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.
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..."
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.
Mind you his approach actually seemed to work - people would ask things in sales meetings then you'd never hear of that request again. It only went wrong in one sales meeting where one person realised what his approach was and started asking for sillier and sillier things....
Did you close the booking because of that feature? That type of decision is sometimes dependent on the financial situation of the company.
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.
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
Video conferencing vendors would talk about this a lot until Zoom ate their lunch, then suddenly their principles about not adding features go away.
Yes, but who cares if they used the feature or not (!?!) the question was, did the buyer think it was 'essential' for the deal to go through.
I mean, cynically of course, but it matters.
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.
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.
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.
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.
As a dev I'd love a ctrl+p sublime style search.
I sincerely believe IT people of the future will look back unkindly on this trend.
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.
as others have said, the pop-up is really the issue here.
If they haven't even attempted to do it now, chances are they won't after you implement a new feature.