Getting Desktop Users Off Decade-Old Versions: Update Policy and Deprecation Plan

You are the product manager for a desktop application that has been on the market for many years. In its preferences, users pick one of two update settings: install updates automatically (labelled as recommended), or ask the user before installing each new update. Because the second setting exists, a group of users is still running very old releases, some of them about ten years old. This creates two problems: 1. The engineering team resents the overhead of continuing to support such old versions. 2. Those users miss important security and performance fixes, as well as many new features. What would you do? ```hint Explain the holdouts first A user who is asked every day yet sits ten years behind is a puzzle worth solving before you choose a policy. List what could explain it, and ask whether every explanation calls for the same remedy. ``` ### Constraints and Clarifications When asked, the interviewer confirms: - The app checks for a new version every 24 hours. - When an update is available, it shows a message saying a new version of the app is available and asking whether to update, with Yes and No buttons. - A user who answers No keeps getting the same message once every 24 hours. - A new release ships at the end of every month. - The product has an availability SLA of 99.99 percent. ### Clarifying Questions - Who are the old-version users: individual consumers, or business customers whose IT departments control installs, and are any on operating systems the current release no longer supports? - Is the product paid, and would moving to the current version cost these customers anything or remove a feature or integration they depend on? - What does the 99.99 percent SLA cover: a backend service the desktop app talks to, and must that service keep accepting requests from old clients? - How many users and what share of revenue sit on old versions, and how far back does engineering actually support today? ### What a Strong Answer Covers - Diagnosing why users stay behind (declining, blocked, incompatible, or never shown a working prompt) using version data and segments before picking a fix. - A clear support policy: a minimum supported version and a deprecation timeline that balances engineering cost against customer disruption. - Changes to the update experience itself, such as prompt content, deferral choices, background download and install on restart, that make accepting easier. - Different handling for different segments: security-driven required updates, managed business deployments, and users stuck on old operating systems. - Success metrics and guardrails, including the SLA and the risk of churn or support load during the migration. ### Follow-up Questions - A large business customer says its compliance process allows updates only twice a year. How do you handle them? - A critical security vulnerability is found in every version older than two years. What changes in your plan? - Should the ask-before-installing setting be removed entirely? Argue both sides and make a call.