Product Management Tips: How to Drop Product Features Safely

As a product manager, it’s only a matter of time before you will need to drop a feature. A platform or browser may become obsolete. A feature that seemed like a good idea at the time may turn out to be useless. A feature that seemed like a dumb idea at the time but that executives insisted you put in the product may be proven to be useless. Your company may pivot and change its target market. Follow these steps to drop a feature safely so you remove it without upsetting your sales force, customers, or prospects.

Document the Process for Dropping a Feature

Document in writing all the steps that a product manager must follow when evaluating a feature drop proposal. Post the writeup on the list of standard product management operating procedures in your wiki. Make sure newly-hired product managers read the process as part of their orientation. You cannot afford the risk that a busy or recently-hired product manager will forget or skip a step. The product manager uses the feature drop process as a “to do” list, and their manager uses the process as a checklist to verify that all the steps were in fact done.

Designate an Owner for the Feature Drop Proposal

Dropping a product feature is a risky move. The company must not unknowingly remove a feature that a customer is currently relying on or that is needed to close a pending sale. Once it has been suggested that a feature should be dropped, the product manager for that area of the product should be responsible for running the process by which the company decides whether and how the feature should in fact be dropped. This provides accountability. (General rule: you should always have a single owner for any action item.)

Verify that Product Development Wants to Drop the Feature

Feature drop proposals often originate from the engineers who are responsible for building and maintaining features and realize they are wasting their time or from sales engineers who realize that features are unneeded and are consuming development resources that could usefully be applied elsewhere (like the sales engineer’s other pending feature requests). Wherever the idea came from, start by confirming with the core product development team of product managers, engineering, and QA that they want to kill the feature. You don’t want to waste the time of your sales force or customers formally evaluating a feature drop proposal if an engineer or another product manager could have told you off the top of their head that you still need the feature for some reason, such as a particular customer actually using it or it being necessary to support another feature.

Announce the Feature Drop Proposal Internally

Create a wiki page to track this specific feature drop proposal. Write an email that documents EVERYTHING you are proposing to drop: fields and controls in the user interface; API calls; preferences or configuration settings; schema changes in your database; and all capabilities or benefits that were provided (or supposed to have been provided) by the feature you’re now removing. Explain why you are removing the feature. Specify a deadline for replying with any concerns or objections and say you will proceed with contacting customers if you don’t get an objection by the deadline. Include a link to the wiki page for tracking the proposal.

Send the email out with the subject line “FEATURE DROP PROPOSAL: <feature name>: REPLY BY <date>” Use all caps for “FEATURE DROP PROPOSAL” and “REPLY BY” to highlight the importance of the email and increase the chance it will be noticed and read.

Send the email to the largest subset of your product development team, sales force, support organization, and executive management team that is acceptable given your company’s size and structure. At a small startup, this would be everyone. At a large company like Cisco, it would be the subset of those teams that work on the product in question. When in doubt, include people. The most dangerous mistake you can make when dropping a feature is to fail to check with someone who turns out to know a good reason you can’t or shouldn’t drop the feature.

If you have a weekly sales conference call, announce the feature drop proposal yourself on that call. People can overlook an email message. If you have a companywide task tracking system, you could assign each person a task to read the feature drop proposal and mark the task complete to indicate they’ve done so. This approach provides tracking and accountability.

Document the Feature Drop Proposal in Your Product Plan, Road Map Presentation, and Open Issue List

Until the feature drop is approved and completed, all standard communications about your product road map should record the feature drop as a pending change. Archive the email announcement on the wiki page for the feature drop proposal.

Develop a Transition Plan

If no one is using the feature, there may be nothing to do. (This is commonly the case for “senior executive bright ideas” that weren’t so bright.) Identify any customers who are using the feature and figure out a plan for each one. If a platform is becoming obsolete, you’ll need to verify your customers’ migration schedules for moving off the platform. If one feature is being replaced with another related one, customers may need to migrate data or educate employees about the change. Figure out all the action items for employees and customers. Document and track them.

Announce the Feature Drop Proposal Externally

Now that everyone inside the company agrees the feature should be dropped, find out if important stakeholders outside the company agree. How you do this will vary depending on the number of your customers and their size.

If you’re an enterprise software company with a small number of customers, work with the sales force to communicate the proposal to each customer who might be affected and confirm they don’t object. Usually this can be done as part of regular customer update visits or calls. For each customer, record the name of the customer employee who approved the feature drop proposal and the date of the meeting and archive the exact presentation you showed them in your wiki. After the meeting, send them a confirmation email that thanks them and says “As we discussed, we plan to drop feature XYZ in our upcoming product release. Thank you for confirming that the plan is acceptable to you.”

If you have larger number of customers, you’ll need to use more scalable ways of communicating the update. Post the proposal on your company blog. Announce it in customer-visible forums. Mention it in your customer newsletter. Ideally, if you have a customer portal, include a message there with an action item for the customer to confirm that they approve the idea. Send out emails to customers you think might care. For business-to-consumer software as a service applications with vast numbers of users, you might include a notice within the product itself. Include a deadline date for objections and a way to respond and give people enough time to respond before you finalize the plan and start work to drop the feature.

Finalize the Proposal Internally

Now that you have internal and external approval, do whatever change control process you use internally to formally add work to the product plan. Get formal approval as high as your company rules require. Send out a “FEATURE DROP APPROVED” email to all the internal groups listed above announcing the change. This way no one can claim they weren’t informed. Then file the tickets necessary to start the engineering and QA work to actually remove the feature.

This Feature Drop Process Really Works!

Kontiki successfully used this feature drop process to permanently drop 63 features over a two year period. Ten more features were removed at a product rewrite with the possibility of being restored at a future date depending on customer demand. There were no customer escalations. No features had to be restored. Removing the features resulted in a major savings of engineering and QA effort.

When product releases came out without the dropped features, only two customer representatives expressed surprise. One had not been informed by a co-worker who had approved the removal and then gone on parental leave. The other had forgotten that they had approved the feature drop. Both accepted the change when we showed them the presentation we’d given them and the record that their company had accepted the change.

Unneeded or obsolete features are dead weight that slow your product development team down. You need to remove them on an ongoing basis to ensure your development resources are focused on building and maintaining needed features, not zombie features that are lingering in the product out of inertia and inattention. Drop features, and do it safely!