The Concept and Process of Feature Closing

The process of planning a product, developing it, releasing it, and getting users to use it can be extremely difficult. Therefore, once a product or feature is released, the decision to close it tends to be avoided even if the market changes or the feature differs from the hypothesis and is not accepted contrary to initial expectations. Additionally, it's common for teams to lack motivation or availability to work on a product closure, as there’s little incentive in shutting down a product.

So how should the decision to close a product or function be made? This article focuses on the demise of a product or function, and explains the process of consideration and the key points of decision-making.

Cost

Whether in B2C or B2B contexts, it's common to adopt a freemium model, allowing a broad user base to access the product for free. In fact, even if the product is deployed for free, there are various costs involved. Let’s first review the significant costs involved in maintaining a product.

1. Infrastructure

. First of all, infrastructure: In B2C, millions of users are likely to use the service, so the cost of infrastructure cannot be overlooked in providing the service. Conversely, in B2B, unless it is for consumer use, it is often not expected to be used by too many users. However, in certain cases like marketing automation, where large datasets are handled, substantial infrastructure costs may arise.

2. Security

. As with infrastructure, in terms of operations, there is a charge for the use of tools and systems for monitoring and verifying security.

3. Support costs

Even without further development, a certain level of support is necessary as long as users continue to use the system. Once the company becomes non-focused, the number of users does not increase much because marketing activities will no longer be focused mainly on the target product or function, but support will not be completely unnecessary.

It is necessary to be ready to answer user inquiries when they come in, and although this is less visible, it is surprisingly costly, so it is important to be aware of this.

4. Development costs

. Even without additional development, a certain amount of maintenance may be required. For this reason, it is necessary to keep an overview of the specifications. In some cases, when an area becomes a non-focus area and no additional development takes place, the person who had grasped the specifications may leave the company. If proper handover doesn't occur, catching up during necessary maintenance will require significant resources.

5. Impact on other development

. It's uncommon for further development beyond maintenance to be done on a product or feature that's no longer a priority. However, when developing other functions, the design is based on the assumption that there are products or functions that are not being focused on, and in some cases this can lead to unnecessary complexity, resulting in an increase in development man-hours.

As mentioned above, infrastructure, security, and support will naturally arise even without new marketing. In addition, maintenance and other development projects will be affected, which can lead to significant costs in some cases.

Timing of Decision Making

With cost in mind, we would like to specify the timing of the decision to close a product or feature.

First, in the case of products with large infrastructure costs, we often discuss whether or not to close them at the same time as we proceed with verifications related to monetization and user growth and determine that they are at their limits, and when to reduce the focus to a non-focused area. This is because it is difficult to find meaning in continuing a product that does not generate revenue because it is considered a clear running cost.

In terms of security, cost is also important, but the security risk may increase with the previous responses. If the risk is rising for other products or products as a whole, we will take measures collectively, but in cases where security is the only problem in the targeted product or function, we often find it difficult to proceed with measures beyond the scope of maintenance. However, in cases where security is the only issue with a product or function, it is often difficult to move beyond maintenance.

Secondly, there are few cases where the urgency to close a product or functionality is driven solely by support costs. Since support costs are a consequence of product factors, they are unlikely to be the primary factor influencing the decision.

Conversely, development resources are a very valuable management resource for business expansion, so if it takes a large amount of development resources to support a product or function, it is likely to lead to a decision to close the product or function. Specifically, there are cases in which a product or function that has not already been additionally developed fails or clearly needs to be modified, but this is a case in which a large amount of man-hours are required. In other cases, the existence of a non-focused product or function may increase the scope of influence on other development projects, making it difficult to design, and thus straining development resources. In this way, we often raise the importance of the issue and proceed with a response when the impact on development resources materializes.

As described above, we will proceed with discussions and make decisions to close products and functions according to the nature of each cost, such as running costs, intervening risks, and impact on development resources.

Process of closing a product

Closing a product or function often has a significant impact on users as well as within the company, so the closing process must be carefully executed.

1. Internal decision making

. Once the costs, risks, importance, and urgency are fully understood, an internal decision is made. Then, after summarizing the reason for closure, the target, the scope of impact, and the existence or non-existence of alternative measures that can be taken by the user and their details, the date and time of closure will be decided based on the development man-hours and schedule.

2. External Communication

. Then, a communication plan is created, not only for internal stakeholders, but also for external stakeholders who will be affected by the closure. In addition to prior notification on the product, press releases may be used in some cases, and individual explanations may be given if there are heavy users of the target product or function. Although we sometimes receive harsh feedback from users at this time, it is highly valuable from the perspective of looking back and for future product development, so we recommend that you summarize the information and read it over with all concerned parties.

3. Close the product or function

. Finally, commend the product or feature for closing as tightly as you did when you put it out. Even if the decision is to close, remember that those involved worked hard to develop and release the product. And closing is often a very difficult project, as it is easy to receive negative feedback from various stakeholders. If you can't give credit where credit is due, even if you make the decision to close a product or feature, you will not be able to execute it, and the cost will continue to drip down the drain.

Conclusion

Making the decision to close a feature that has been released after a great deal of effort, and then specifically closing it, involves a complex mix of feelings by various stakeholders. In the midst of all this, it is necessary to calmly evaluate the cost and value, and steadily close the function.

We hope that product managers will not only add features, but also make decisions to close features, sometimes ruthlessly, and take a stand to promote them, which will lead to the further evolution of the product and the realization of the product vision.