> 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.
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)
> 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.
Conversely Google does this all the time and has enough of a brand reputation problem around it that they struggle to launch new lines of business that rely on trust that you’re not going to take away the product shortly after launch. Case in point for one of the large reasons I think Stadia failed in addition to the absurd pricing model. There were other headwinds but I think Microsoft proved with Xbox that you can stick around long enough to be successful. I think Apple’s ecosystem is more forgiving here, but that’s because they’re generally more careful about bringing out products in the first place and then taking a very long time to sunset them (eg iTunes). User trust is real and you can sacrifice it if you must, but that isn’t reflected by usage numbers today.
Being on the receiving end of this too many times (particular by Google), I couldn't more strongly disagree with the sentiment in this post.
Here's my message to product managers reading this: If I see you starting to regularly remove features, I will proactively stop using your product, before you get to remove a feature I rely on.
I believe this highlights the difference between products and services...two words we tend to use interchangeably.
Services benefit from turning things off, because operating them costs time and money. It doesn't matter if you lose a subset of users who cared, because your operational metrics are what you optimize for. I used to manage a team of three engineers that couldn't do anything new because we owned 10 legacy backend services that were relatively unused. We followed a rubric similar to this.
Products, however, never benefit from turning things off, because it lowers value. For example, imagine the trivial case where a desktop product with no backend removes a feature because it's deemed niche. This would make no sense except in cases that are, themselves, niche.
Everything is a service now, so I understand how these words can get conflated. Services have subscription fees, which are better for the business to plan YoY. However, let's not forget that services and products are different things, and if you're using something that will inevitably turn things off the longer you use it, then you're using a service. Consider this the next time you're in a thread complaining about the planned obsolescence of iPhones or that Google shut down Google Reader.
This distinction is disappearing. Internally we have product owners and call new SAAS offerings 'products'. I found this trend difficult to accept yet here we are.
The real reason is, adding features is simple, you just have to understand the one use-case the feature adds.
When removing a feature, you have to understand all the real world use-cases, before you can kill it. This is a lot of work, therefor it is much easier to not touch it and work on the next feature.
There's a lot of accidental "features" in products, enabled by users coming up with novel (unexpected and/or unpredicted) ways to do things. It reminds me a lot of this: https://xkcd.com/1172/
A lot of this comes down to shifting the burden within responsibilities of the team. Product management having a good understanding of the hidden use cases is ideal, but really hard. Not doing that means you have Development and QA spending time on stuff no one uses.
One of the interesting outcomes is when you accidentally break a feature. If someone complains at least you know it's being used, and ideally PM starts a discussion on the real use case. My favorite is noticing something is broken while working on adjacent code, and looking at git blame to see it's been broken for months. In theory at least, that should be an easy decision to kill it; in practice my experience is everyone is always very hesitant to actually do that.
Somewhat orthogonal to the story, but in the intro they talk about adding features and say: "Imagine the internal ‘pat on the backs’ and recognition that occurred when Gmail fully launched dark mode for the mobile app,[...] or Apple announced their M1 chip"
How is implementing dark mode even remotely comparable to launching a new general purpose CPU and transitioning an entire product line from one CPU to another?? Is changing the color on a web site that hard?
> How is implementing dark mode even remotely comparable to launching a new general purpose CPU and transitioning an entire product line from one CPU to another?? Is changing the color on a web site that hard?
They're definitely not comparable, but having been involved in implementing dark mode for an iOS app (the quote you're reffing is talking about the mobile app, not website): Yes, implementing dark mode for at least an iOS app can be surprisingly challenging (or at least, a lot of work). It's probably much easier to write a brand new dark-mode supporting app, but retro-fitting it onto an existing app is a whole other thing.
Your designers need to re-colour the entire UI (and this turns out not to mean just "Map colour X to colour Y" btw), you need to cope with on-the-fly switching (iOS devices can be configured to switch dark mode setting automatically at sunrise/sunset), anywhere you're doing custom drawing needs to have dark mode retrofitted into it, and if you're getting imagery from a backend anywhere you'll probably need to add support for getting both light/dark mode images at once (which of course also means you need to re-draw all that imagery for dark mode as well). There's bound to be more stuff I'm forgetting.
So yeah, dark mode for an app can be a bit of work, it's not just swapping colours.
Nowhere do they imply that they're at all comparable. They're not comparing them to each other. They're comparing them to eliminating comparable features.
Apparently for today's developers, yes. Used to be users could arbitrarily change their own colors and fonts, now having 2 whole choices takes a team of developers months of work.
yea seriously... you can by a brand new fully mechanical leica with manual everything for $5k.
for that price, you can buy a nikon 6ii and 2-3 top of the line lenses.
I understand that there's a leica "look" that people love but you can do that with a combination of raw file processing an d lens calibration for substantially less.
I'm someone who was affected by Mixpanel's decision to end their messaging product.
I think having the ability to message users was a huge selling point for Mixpanel. It meant that you could track user events and details with Mixpanel and use them to send behavior triggered emails, push notifications and SMS on the same platform.
From what I see, it seems the issue was, they never realized or marketed how great it was having user analytics and messaging on the same platform. Their messaging product didn't have to be the best feature wise, it solved a lot of pain points.
No need to send your user events to a separate messaging platform, you could easily track downstream actions users took after receiving or opening a message you sent with Mixpanel to get more accurate conversion data as utms can be unreliable, it had competitive pricing (multichannel messaging platforms for large audiences are very costly).
You're optimistic if you think it will get any worse :)
See, Google's performance reviews value launches because launches create a lot of impact and growth.
On the other hand, deprecating and killing existing features clearly has little negative impact ("doesn't move the needle!"), while freeing up developers' time for other launches.
So the incentives are aligned perfectly well for the three year launch-abandon-kill cycle, which gets people promotions.
As long as "median time using the platform, in years" is not a metric that Google even looks at, you can count on things staying the same, and the graveyard[1] growing.
benjaminjackman|4 years ago
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?
mook|4 years ago
reaperducer|4 years ago
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.
jka|4 years ago
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)
UglyToad|4 years ago
Reducing a development team's understanding of their target market to "line goes up" underlies a lot of the harms arising from modern software.
gmueckl|4 years ago
tsjq|4 years ago
vlovich123|4 years ago
Conversely Google does this all the time and has enough of a brand reputation problem around it that they struggle to launch new lines of business that rely on trust that you’re not going to take away the product shortly after launch. Case in point for one of the large reasons I think Stadia failed in addition to the absurd pricing model. There were other headwinds but I think Microsoft proved with Xbox that you can stick around long enough to be successful. I think Apple’s ecosystem is more forgiving here, but that’s because they’re generally more careful about bringing out products in the first place and then taking a very long time to sunset them (eg iTunes). User trust is real and you can sacrifice it if you must, but that isn’t reflected by usage numbers today.
romwell|4 years ago
It's well known that 99% of the users use about 1% of MS Excel's features (exaggerating, but bear with me).
The kicker? It's different 1% for each users.
Remove the "infrequently" used features, and the product is no more.
More on that from Spolsky: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
falcor84|4 years ago
Here's my message to product managers reading this: If I see you starting to regularly remove features, I will proactively stop using your product, before you get to remove a feature I rely on.
EDIT: fixed typos
madrox|4 years ago
Services benefit from turning things off, because operating them costs time and money. It doesn't matter if you lose a subset of users who cared, because your operational metrics are what you optimize for. I used to manage a team of three engineers that couldn't do anything new because we owned 10 legacy backend services that were relatively unused. We followed a rubric similar to this.
Products, however, never benefit from turning things off, because it lowers value. For example, imagine the trivial case where a desktop product with no backend removes a feature because it's deemed niche. This would make no sense except in cases that are, themselves, niche.
Everything is a service now, so I understand how these words can get conflated. Services have subscription fees, which are better for the business to plan YoY. However, let's not forget that services and products are different things, and if you're using something that will inevitably turn things off the longer you use it, then you're using a service. Consider this the next time you're in a thread complaining about the planned obsolescence of iPhones or that Google shut down Google Reader.
paulryanrogers|4 years ago
thibran|4 years ago
When removing a feature, you have to understand all the real world use-cases, before you can kill it. This is a lot of work, therefor it is much easier to not touch it and work on the next feature.
gregmac|4 years ago
A lot of this comes down to shifting the burden within responsibilities of the team. Product management having a good understanding of the hidden use cases is ideal, but really hard. Not doing that means you have Development and QA spending time on stuff no one uses.
One of the interesting outcomes is when you accidentally break a feature. If someone complains at least you know it's being used, and ideally PM starts a discussion on the real use case. My favorite is noticing something is broken while working on adjacent code, and looking at git blame to see it's been broken for months. In theory at least, that should be an easy decision to kill it; in practice my experience is everyone is always very hesitant to actually do that.
tppiotrowski|4 years ago
Careful with this one. Restore from backup is not used frequently but crucial.
romwell|4 years ago
And Windows Phone did have all the other apps that engaged large subsets (from Netflix to Uber and everything in between).
Windows Phone was killed by lack of apps.
The moral, in case it's not clear, is that most of the value proposition of any major product are parts that "engage only a small subset of users".
Different subsets for each part.
Remove the parts, and you are left with no product to speak of.
drewg123|4 years ago
How is implementing dark mode even remotely comparable to launching a new general purpose CPU and transitioning an entire product line from one CPU to another?? Is changing the color on a web site that hard?
darren_|4 years ago
They're definitely not comparable, but having been involved in implementing dark mode for an iOS app (the quote you're reffing is talking about the mobile app, not website): Yes, implementing dark mode for at least an iOS app can be surprisingly challenging (or at least, a lot of work). It's probably much easier to write a brand new dark-mode supporting app, but retro-fitting it onto an existing app is a whole other thing.
Your designers need to re-colour the entire UI (and this turns out not to mean just "Map colour X to colour Y" btw), you need to cope with on-the-fly switching (iOS devices can be configured to switch dark mode setting automatically at sunrise/sunset), anywhere you're doing custom drawing needs to have dark mode retrofitted into it, and if you're getting imagery from a backend anywhere you'll probably need to add support for getting both light/dark mode images at once (which of course also means you need to re-draw all that imagery for dark mode as well). There's bound to be more stuff I'm forgetting.
So yeah, dark mode for an app can be a bit of work, it's not just swapping colours.
asutekku|4 years ago
pc86|4 years ago
AnIdiotOnTheNet|4 years ago
Our industry is pathetic.
psychomugs|4 years ago
cultofmetatron|4 years ago
for that price, you can buy a nikon 6ii and 2-3 top of the line lenses.
I understand that there's a leica "look" that people love but you can do that with a combination of raw file processing an d lens calibration for substantially less.
formerly_proven|4 years ago
11eleven|4 years ago
I think having the ability to message users was a huge selling point for Mixpanel. It meant that you could track user events and details with Mixpanel and use them to send behavior triggered emails, push notifications and SMS on the same platform.
From what I see, it seems the issue was, they never realized or marketed how great it was having user analytics and messaging on the same platform. Their messaging product didn't have to be the best feature wise, it solved a lot of pain points.
No need to send your user events to a separate messaging platform, you could easily track downstream actions users took after receiving or opening a message you sent with Mixpanel to get more accurate conversion data as utms can be unreliable, it had competitive pricing (multichannel messaging platforms for large audiences are very costly).
gwern|4 years ago
ant6n|4 years ago
toomuchtodo|4 years ago
nikodunk|4 years ago
Good thoughts though as you say.
somewhereoutth|4 years ago
ericwooley|4 years ago
https://businessofsoftware.org/2015/10/david-heinemeier-hans...
ummonk|4 years ago
romwell|4 years ago
See, Google's performance reviews value launches because launches create a lot of impact and growth.
On the other hand, deprecating and killing existing features clearly has little negative impact ("doesn't move the needle!"), while freeing up developers' time for other launches.
So the incentives are aligned perfectly well for the three year launch-abandon-kill cycle, which gets people promotions.
As long as "median time using the platform, in years" is not a metric that Google even looks at, you can count on things staying the same, and the graveyard[1] growing.
[1] https://killedbygoogle.com