3 ms·

Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing". If you're in a situation where you have customer

Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing". If you're in a situation where you have customer's just be honest about the changes coming and give them enough runway to get the changes made.

beachy 2y ago
Yep. If you gradually degrade performance, and word of your intentions fails to make it to the right people, the victim may well have to devote significant effort to trying to work out what's going on. Boy will they be pissed when they find out.
- bongodongobob 2y ago
  This is standard practice though. You can only communicate it so much. If your customers ignore it, that's on them. You either have a hard cutoff date or you introduce failures or throttling. The latter is friendlier.
bongodongobob 2y ago
Yeah you do that and you'll still have customers that ignore it. That's why you have to slowly degrade it at a communicated point in time. You're not being sneaky about it, it's planned. It's that or you dedicate a ton of manpower to hold everyone's hand for a hard cutoff which will always be painful.
lazyasciiart 2y ago
We have customers using a client that was officially deprecated in 2020 and stopped working altogether for six months in 2022, along with as much announcement noise as we could make. A year later I was surprised to realize the environment change that had blocked it was gone…and people were still using it.
compootr 2y ago
Yes, and you should do this after being honest that it's being sunsetted Set a date it'll be 100% available until then begin degrading it. After all, you didn't guarantee 100% availability/usability after said date all this to say, if you release both versions, I'd monitor adoption and keep v1 alive if a lot of customers (esp. big spenders/enterprises!) depend on it
chipdart 2y ago
> Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing". You're conflating sunsetting old services with forced upgrades. Degrading services when preparing for sunsetting the service is a surefire way to convince product managers to bump up migrations in their priority queue. Announcing sunsetting doesn't work. Reaching out directly to stakeholders doesn't work. What works is the urgency of avoiding downtime. The alternative is simply pulling the plug on a fixed date, which is not preferable.

beachy 2y ago

Yep. If you gradually degrade performance, and word of your intentions fails to make it to the right people, the victim may well have to devote significant effort to trying to work out what's going on. Boy will they be pissed when they find out.

bongodongobob 2y ago
This is standard practice though. You can only communicate it so much. If your customers ignore it, that's on them. You either have a hard cutoff date or you introduce failures or throttling. The latter is friendlier.

bongodongobob 2y ago

Yeah you do that and you'll still have customers that ignore it. That's why you have to slowly degrade it at a communicated point in time. You're not being sneaky about it, it's planned. It's that or you dedicate a ton of manpower to hold everyone's hand for a hard cutoff which will always be painful.

lazyasciiart 2y ago

We have customers using a client that was officially deprecated in 2020 and stopped working altogether for six months in 2022, along with as much announcement noise as we could make. A year later I was surprised to realize the environment change that had blocked it was gone…and people were still using it.

compootr 2y ago

Yes, and you should do this after being honest that it's being sunsetted Set a date it'll be 100% available until then begin degrading it. After all, you didn't guarantee 100% availability/usability after said date all this to say, if you release both versions, I'd monitor adoption and keep v1 alive if a lot of customers (esp. big spenders/enterprises!) depend on it

chipdart 2y ago

> Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing". You're conflating sunsetting old services with forced upgrades. Degrading services when preparing for sunsetting the service is a surefire way to convince product managers to bump up migrations in their priority queue. Announcing sunsetting doesn't work. Reaching out directly to stakeholders doesn't work. What works is the urgency of avoiding downtime. The alternative is simply pulling the plug on a fixed date, which is not preferable.