Comment by benjaminjackman | Hacker News Reader

Comment by benjaminjackman | Hacker News Reader

benjaminjackman

> Even after features or products are deemed to have little to no value, teams keep them around for ages instead of responsibly removing them. The most common argument we hear is, “This [small subset] customer [sic] regularly uses the feature and we’ll lose out, if we remove it.” Instead of associating unshipping with the traditional ‘What do we lose?‘ perspective, let’s reframe to a ‘What do we gain?‘ perspective. After all, unshipping can actually improve product metrics.

Being on the other end of this, maybe it's great for the business to streamline things and save costs, but as a user it's not fun having a feature I am using disappear because I am part of only a small group using it. Instead of saying 'what do we lose' (nothing except perhaps a few customers ... if the customers have an option to move platforms, which often they don't) what does the customer using the feature lose? What's our plan to replace their use case with something more efficient?

You also have to be careful about the users' trust in your product, and your brand: unshipping is a lot more negative than shipping. Do it enough and you get things like https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-... where people get to write articles about your terrible record of unshipping things.

as a user it's not fun having a feature I am using disappear because I am part of only a small group using it

Apple is really bad at this with Siri. One example: For what feels like a couple of years, almost every night I'd lay on the floor and play with the cat. Occasionally I'd call out, "Hey, Siri, where is my wife?" And Siri would reply something like "She is 8.3 miles away."

This was how I could tell when my wife was about to arrive home and it was time to put away the cat toys and start making dinner.

As of a couple of iOS versions ago, now all Siri will say is something like, "You'll have to unlock your iPhone for that." If I was near my phone, I wouldn't be shouting into the air.

A LOT of Siri responses these days are, "You'll have to unlock your iPhone to do that," or "I can't do that here, but you can do it on your iPhone." I understand that it's probably for privacy (though Siri is supposed to know it's me speaking), but it makes me less likely to use Siri at all for anything else.

Google is the same way. I have smart lights and my phone will insist on unlocking to change them whereas the home mini will just turn them on and off. But the mini does not always hear.

My guess is that it’s not necessarily about knowing that it’s you speaking. To satisfy that query, it has to let you make iCloud queries of your wife’s position with keys that aren’t secure (eg can be retrieved by hooking up to a computer with malware).

The other attack surface is that someone invokes Siri physically with the button on the phone. I think this does speak to the fact that Apple should probably add a security level which is “voice unlocked” which gives a transient key for Siri queries, which they can even tie together through the internal activity API so that only the daemons that are accessing such data in support of an actual validated query get to unlock the relevant data.

That's a useful perspective: let's say 3% of a service's userbase really loves an obscure feature (they rate it highly), but at the scale of the business, it doesn't make sense to support that feature within the core product.

That seems like an indicator that there could be a viable business around that single feature. But can that business exist if the larger company's product doesn't provide interfaces that allow peer products to interoperate?

(I wouldn't call those "plugins" or "API integrations" -- those make it seem like there is one "primary" product and one vendor who creates a smaller, secondary component. in the Unix philosophy, any two tools can combine without the need for any clear priority of roles)

I think this (original quote) is why I regard an organisation being "metrics driven" and associated working process as a bad sign.

Reducing a development team's understanding of their target market to "line goes up" underlies a lot of the harms arising from modern software.

What you want sounds reasonable, but it has one flaw: it takes more effort and thus costs extra money to the business.

What you say sounds reasonable, but it has one flaw: That's what they're being paid for.

They might not be paying enough. It’d be reasonable to go to these small cohorts and say “our data shows these features are not broadly used, we are considering deprecating them, would you pay more to keep them?”

This is mutually beneficial for both parties.

I'd say that's definitely the right way to do it.

reminds me of Python3

How?

suggesting to reduce / stop backward compatibility

Reply on news.ycombinator.com