[HN Gopher] Upsides to unshipping: The art of removing features ...
___________________________________________________________________
Upsides to unshipping: The art of removing features and products
Author : villaaston1
Score : 58 points
Date : 2021-08-27 09:19 UTC (13 hours ago)
(HTM) web link (mixpanel.com)
(TXT) w3m dump (mixpanel.com)
| madrox wrote:
| 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.
| paulryanrogers wrote:
| 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.
| tppiotrowski wrote:
| "engages only a small subset of users"
|
| Careful with this one. Restore from backup is not used frequently
| but crucial.
| vlovich123 wrote:
| > 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.
| thibran wrote:
| 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.
| gregmac wrote:
| 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.
| gwern wrote:
| https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
| ant6n wrote:
| This seems like good content, but it feels so much like an ad.
| nikodunk wrote:
| 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.
| toomuchtodo wrote:
| 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.
| 11eleven wrote:
| 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).
| ummonk wrote:
| Just don't let Google see this article please.
| benjaminjackman wrote:
| > 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?
| jka wrote:
| 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)
| [deleted]
| UglyToad wrote:
| 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.
| mook wrote:
| 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.
| tsjq wrote:
| reminds me of Python3
| pc86 wrote:
| How?
| gmueckl wrote:
| What you want sounds reasonable, but it has one flaw: it takes
| more effort and thus costs extra money to the business.
| guerrilla wrote:
| What you say sounds reasonable, but it has one flaw: That's
| what they're being paid for.
| toomuchtodo wrote:
| 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.
| guerrilla wrote:
| I'd say that's definitely the right way to do it.
| reaperducer wrote:
| _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.
| birdman3131 wrote:
| 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.
| vlovich123 wrote:
| 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.
| drewg123 wrote:
| 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?
| asutekku wrote:
| Because a general consumer cares about user facing features,
| which improve product usability.
| AnIdiotOnTheNet wrote:
| 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.
| pc86 wrote:
| 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.
| psychomugs wrote:
| 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_.
| cultofmetatron wrote:
| 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.
| psychomugs wrote:
| 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.
| formerly_proven wrote:
| B/W sensors have very real upsides over a color sensor if you
| want a B/W image.
| psychomugs wrote:
| Yes, but for many, even enthusiasts, that's a very steep
| tradeoff.
| falcor84 wrote:
| 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
___________________________________________________________________
(page generated 2021-08-27 23:01 UTC)