Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upsides to unshipping: The art of removing features and products

mixpanel.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Upsides to unshipping: The art of removing features and products

#31

Post by vlovich123 »

> 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.

Re: Upsides to unshipping: The art of removing features and products

#32

Post by vlovich123 »

reaperducer wrote: post #16
benjaminjackman wrote: post #3

> 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. A…

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 wif…

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.

Re: Upsides to unshipping: The art of removing features and products

#33

Post by 11eleven »

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).

Re: Upsides to unshipping: The art of removing features and products

#34

Post by [deleted] »

jka wrote: post #21
benjaminjackman wrote: post #3

> 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. A…

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 p…

[deleted]

Re: Upsides to unshipping: The art of removing features and products

#36

Post by madrox »

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.

Re: Upsides to unshipping: The art of removing features and products

#37

Post by paulryanrogers »

madrox wrote: post #36

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…

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.

Re: Upsides to unshipping: The art of removing features and products

#38

Post by romwell »

vlovich123 wrote: post #31

> 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. A…

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...

Re: Upsides to unshipping: The art of removing features and products

#39

Post by romwell »

gregmac wrote: post #19
thibran wrote: post #4

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 an…

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.

Re: Upsides to unshipping: The art of removing features and products

#40

Post by romwell »

tppiotrowski wrote: post #2

“engages only a small subset of users” 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.

Post reply on HN