Upsides to unshipping: The art of removing features and products(mixpanel.com)
mixpanel.com
Upsides to unshipping: The art of removing features and products
https://mixpanel.com/blog/upsides-to-unshipping-the-art-of-removing-features-and-products/
44 comments
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.
This is mutually beneficial for both parties.
I'd say that's definitely the right way to do it.
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.
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.
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.
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.
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)
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)
[deleted]
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.
Reducing a development team's understanding of their target market to "line goes up" underlies a lot of the harms arising from modern software.
> 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.
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.
It's the classic fallacy.
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...
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...
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.
EDIT: fixed typos
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
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.
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.
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.
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.
As someone who shipped a "feature" and had to roll it back because it broke the users' flow (even though it was an improvement by all means):
It can be acceptable to un-ship a feature, breaking users' flows -- as long as there are other means that are left for them to accomplish the same result with just as much effort.
Even then, people having to re-train themselves is not a good thing, but at the very least it should still be possible to get the same result.
In our case, the way the users (ab)used the old implementation allowed them to do something that was not easily done by other means.
So we simply flipped the switch back, enabling the old behavior.
I really hope that the developers elsewhere would do the same in a similar scenario for products that I use.
It can be acceptable to un-ship a feature, breaking users' flows -- as long as there are other means that are left for them to accomplish the same result with just as much effort.
Even then, people having to re-train themselves is not a good thing, but at the very least it should still be possible to get the same result.
In our case, the way the users (ab)used the old implementation allowed them to do something that was not easily done by other means.
So we simply flipped the switch back, enabling the old behavior.
I really hope that the developers elsewhere would do the same in a similar scenario for products that I use.
“engages only a small subset of users”
Careful with this one. Restore from backup is not used frequently but crucial.
Careful with this one. Restore from backup is not used frequently but crucial.
99% of apps in the iStore "engage only a small subset of users".
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.
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.
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?
> 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.
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.
Because a general consumer cares about user facing features, which improve product usability.
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.
Our industry is pathetic.
Our industry is pathetic.
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.
Leica is a very unique camera company in that they can get away with removing features (screens, the ability to shoot in color) while charging more.
B/W sensors have very real upsides over a color sensor if you want a B/W image.
Yes, but for many, even enthusiasts, that's a very steep tradeoff.
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.
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 own a film Leica (M2). I also own the top-tier Fujis from 2017 (X-Pro2, X-T2, X100F).
The Good Old Leica Bullshit is, to me, a process-over-product feeling. I don't care as much about comparing the result of Tri-X@1600 to Fuji's (excellent) film simulations. I care much more about 1) using something with absolutely no electronics in it, 2) having to wait to see the results and thus divorcing myself from the moment, 3) knowing that, with proper care, this 60-year old camera will likely outlive me.
The Good Old Leica Bullshit is, to me, a process-over-product feeling. I don't care as much about comparing the result of Tri-X@1600 to Fuji's (excellent) film simulations. I care much more about 1) using something with absolutely no electronics in it, 2) having to wait to see the results and thus divorcing myself from the moment, 3) knowing that, with proper care, this 60-year old camera will likely outlive me.
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).
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).
This seems like good content, but it feels so much like an ad.
Agreed - SO hard to read. Either it hasn’t been edited or someone thought the long winded style would keep me scrolling.
Good thoughts though as you say.
Good thoughts though as you say.
Content marketing well is an art. You have to source quality writing talent who can weave a story without it coming across as an ad.
The no notch option on my Galaxy A40 got unshipped. Not happy.
I'd prefer to rewrite.
https://businessofsoftware.org/2015/10/david-heinemeier-hans...
https://businessofsoftware.org/2015/10/david-heinemeier-hans...
Just don’t let Google see this article please.
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.
[1] https://killedbygoogle.com
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
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?