The problem with planning obsolescence in this manner is that different people use their devices differently and have different expectations, both of which make

The problem with planning obsolescence in this manner is that different people use their devices differently and have different expectations, both of which make their devices go obsolete at different times. An ancient phone that hasn't had an OS update in years still has a good shot at being able to handle texts and phone-calls. If that's all a user wants from it, it's not obsolete until it becomes so old it can't talk to their carrier's network. This is the sort of user who might not be afraid of replacing batteries. Another user might want to do a fair bit with his phone and be just barely satisfied with the quickness of the interface when he first gets his device. A couple of updates, with their associated bloat, might reduce the speed of the interface enough that the phone becomes, as far as this user is concerned, ready for the junkpile. If you're making the phones these two users are buying, how do you choose an expiration date? If you put it somewhere in between the above two extremes, one user will angrily bin their phone long before the expiration date and place no further trust in such dates, or your brand, while the other user, knowing how long his phones typically last, might not even buy a phone with such a short official lifetime. Expiration dates are for milk and eggs. What users want is for the makers of the products they're using to commit to meeting their needs for a reasonable time period. People understand that hardware goes obsolete, but are less understanding when companies provide software updates that have so much bloat that devices become progressively less capable and effectively lose features. People get mad, and rightfully so, when companies refuse to sell repair parts and actively sue anyone making third-party parts.