5 ms·
Low adoption of features and the sad realization
- donatj 6y agoThe 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.
- syrocode 6y agoThe 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.
- arethuza 6y agoI once worked with a CEO who would always answer "Yes" to questions about whether the product did something, much to my horror as Director of Engineering. 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....
- otoburb 6y ago>>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.
- breakfastduck 6y agoI 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 6y ago>>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 6y agoYeah 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 6y agoAhh yes the old "Hurry up and wait"... been there too many times....
- Spooky23 6y agoHow 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.
- damandloi 6y agoI have seen product roadmap shifting in favor of sales requests and significantly changing the strategy. But hey, that's pivoting right?
- jariel 6y ago"some big sale hinged on, that subsequently no one has used" 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.
- kstenerud 6y agoPeople 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.
- deleted 6y ago[deleted]
- damandloi 6y agoThe solution provider is incentivized to add new use cases. Thus, always bringing the change that nobody has asked but the market.
- falcolas 6y agoI 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 6y agoReminds 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.
- ekko_ 6y agoOne 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 https://en.wikipedia.org/wiki/Unix_philosophy
- 6y ago
- dade_ 6y agoI 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.
- codeulike 6y agoI 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.
- HatchedLake721 6y agoI would say features never matter even for SMB demos. Sell the value and solutions, not features.
- dan_can_code 6y agoNothing 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 6y agoSorry for that. May I know what annoyed you the most? The old style popup (JS alert) or the presence of the popup?
- AnIdiotOnTheNet 6y agoYou seriously have to ask? Pop-up blockers were invented for a reason. Things that jump out and demand your attention are annoying, period.
- damandloi 6y agoThank you for your feedback. I have removed the pop-up for now. No warning about the ugly readability experience in dark mode.
- guitarbill 6y agoif 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.
- dan_can_code 6y agoThanks for getting back to me. I wasn't expecting a response. As you've mentioned below it is now off which is great. It was just a very jarring, personally I feel its best to allow users to make their own opinions of the experience, I don't find the dark mode experience that bad at all. The text is white and the background is black. Good enough for me!
- ChrisSD 6y agoConstant 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.
- dcolkitt 6y agoSeems 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
- bumbledraven 6y agoIt 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.
- strogonoff 6y ago> 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 6y agoFWIW this is called the https://en.wikipedia.org/wiki/XY_problem https://en.wikipedia.org/wiki/XY_problem
- strogonoff 6y agoXY 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.
- mackle_hair 6y agoi'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.
- richard_g 6y agoA 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 6y agoGood 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".