[acituan]

> Fine, but why are they so bad at weighing it against long term trust?

I want to remind the loss aversion and status quo bias. We tend to evaluate losses more important than they are, which is why for example it is hard to throw seldom used things away.

That said, why should feature removal mean automatic loss of trust? Because this feature is not important to me personally, it actually increases my trust that they can reorient their focus instead of churning man-hours on a feature just because it existed. Now I get it, it was an important feature for some people, and next day they might remove a feature that I find important, but in aggregate they clearly weighed its usage/perceived importance against removal decision.

[uluyol]

Never heard the name "status quo bias" before, thanks for bringing that up.

I don't really care about this particular feature, but I do care about the trend. Why should a feature be sunset? It seems like this must be because of (a) bugs/maintenance burden or (b) a poor design or one that is mismatched with the current product direction. The fact that Google sunsets so many features and products suggests that both of these happen with high frequency. (b) is especially worrying, why can't they spend time before launching to figure out what they're going to do and commit to it? They aren't a small startup, they've got tons of resources. I'm sure they're trying, but whatever they're doing is not working, in my opinion.

For the record, I'm not a Google hater, but this is just so frustrating to watch as a user.

[acituan]

I totally sympathize with the frustration, and experience that as a user too. But I would like to suggest that digital product design is usually a moving target, based on constantly changing consumer engagement, competition and other market conditions, so they have to follow a dynamic, adaptive strategy. Now, could they commit on a feature despite these, yes of course, but that too many of such commitments will have a cost to us users in terms of lack of new innovation.

I imagine this picture; a “tech-smith” is building an elaborate, complicated machinery and we as the users are watching it, clapping to it, interacting with it. Some are asking “this machine should have bells”, some go “it should have whistles”, and the techsmith wants to add and remove those based on those parameters. In reality, no one knows what the final machine should look like and no one knows how exactly they will use it. So there is a sweet spot in which unexpected changes are budgeted for so that it can change to conform better to what we want and what we find useful as we gain experience with the machine. Which means sometimes the techsmith will need to go “you know what, I’m going to take this bell away because not many are using it and it is causing me problems, and instead I’ll use the materials and energy to add these extra wheels” even after having invested a lot to that bell initially (which is laudible, because they are also fighting against their own sunken cost fallacy).

This should be familiar to software engineers; “why the requirements were not perfect before I started writing the software” doesn’t work well in real life. In reality as the engineer and the user gain more experience with the system that is gradually emerging, they acquire new participatory knowledge of that system and that causes a change in requirements, in a dynamical, reciprocal fashion. (Which is one of the reasons why waterfall processes are not as popular today for most products). I think the same goes at a higher scale, if not complexity, for these comnplicated machinery big tech builds that is used by billions of people.