Upsides to unshipping: The art of removing features and products
mixpanel.com
mixpanel.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?
This is mutually beneficial for both parties.
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.
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 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)
Reducing a development team's understanding of their target market to "line goes up" underlies a lot of the harms arising from modern software.
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 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...
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
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.
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.
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.
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.
Careful with this one. Restore from backup is not used frequently but crucial.
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.
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?
Our industry is pathetic.
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.
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.
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 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).
Good thoughts though as you say.
https://businessofsoftware.org/2015/10/david-heinemeier-hans...
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.