Your calculation doesn't take into account the time savings for brand new users. Since they don't have to unlearn anything, they start saving the time immediately.

Not saying it is right or wrong, but a lot of the upsetting changes for existing users are for the benefit of new users.

We can start with the contention that that isn't true. Even for a new user, the change is going to bring with it a bunch of new bugs because the new code is new, and invalidate all of the solutions to problems that people can search for on the internet until the new thing is as old as the old thing (at which point somebody tries to replace it again).

Also, "users" are "people" and the average adult lifespan (18-78) is around 60 years. That implies that the time for the "new users" to become half of the user base is around 30 years, so what does that say about how often it makes sense to do this?

But suppose you're right. Then the solution is competition. Don't take away the old thing, provide both. If the new users want to use the new thing and the old users want to use the old thing, great.

And then if the new users still want to use the old thing you've got a pretty good red flag that you messed it up.

> That implies that the time for the "new users" to become half of the user base is around 30 years

That doesn’t add up at all... you’re implying that users are gained and lost at exactly the same rate, consistently, over a span of at least 30 years.

It doesn’t invalidate your other point about competition, but it’s a flawed argument to base any reasoning upon.

But the real situation is even stronger to my point, because most software in use today won't be in 30 years. So the real graph for established products is that you continue to get new users for five or ten years as young people learn and old people die, but never enough to even hit the halfway mark. Then your company folds or gets out-competed by something else, your user base falls off a cliff and the software becomes irrelevant.

The point at which "new users" are the majority of the user base never even happens.

> And then if the new users still want to use the old thing you've got a pretty good red flag that you messed it up.

Your new UI might be garbage, but there's no red flag here. A new user will likely need to make use of tutorials, troubleshooting, and other help online; most or all of which will be based on your old UI (and possibly coupled with comments like, 'Don't use the new UI, it's trash. Here is how to switch...'). Having been such a new user, I only pick the new UI when forced or when it's clearly better; the former being the more common case.

Sure, you can make your official documentation use the correct UI (or design your UI in such a way that the documentation can be agnostic—but then what is this big change that makes lives better?), but unless your documentation is very good, people are still going to need to reference all these other sources.

“... make use of tutorials, troubleshooting, and other help online; most or all of which will be based on your old UI”

Recently ran into this issue when submitting an app to Google Play. New interface didn’t even match up to Google’s own instructions. Frustrating.

I was working at a large real estate marketplace. Product management came up with a nice new UI for the backend every two months, because that was what they loved to do - also lots of designers hanging around that need to work! Real estate broker - the customers - hated it of course, they only wanted to get their job done, not relearn the UI every two months.

Rule of thumb: do not listen to the vocal minority, code for all the satisfied and silent customers.

Edit: unless there is a majority of unsatisfied customers (:

Listen to what the customer needs, not what they say. Change because it is really better not because it looks nicer.