Low adoption of features and the sad realization
1–10 of 44 posts
Re: Low adoption of features and the sad realization
#2We 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.
Re: Low adoption of features and the sad realization
#3The 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.
Re: Low adoption of features and the sad realization
#4Change 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.
Re: Low adoption of features and the sad realization
#5Before 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.
Re: Low adoption of features and the sad realization
#6The 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.
The interesting question is whether it was a mistake. Just because it was eventually rolled back, doesn't mean it wasn't worth it to win the large customer.
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....
Re: Low adoption of features and the sad realization
#7Re: Low adoption of features and the sad realization
#8I 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…
Yes I've seen this a lot. The whizzy front end stuff in the demo is irrelevant.
Re: Low adoption of features and the sad realization
#9People 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…
Re: Low adoption of features and the sad realization
#10If 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.