Remove unnecessary features and products to improve your business.
Yuri Andreikovich, Senior Product Manager at Wrike, told at the ProductSense conference in Minsk, when and why to remove features from the product.
I work at Wrike , a collaboration and project management service. Wrike has over a million users, but our direct customers are companies that pay for employees. There are about 17 thousand.
More than once I came across the need to remove features from a product, and sometimes they came to me with a request: “We have several thousand users, they use something, and we want to remove it. Act. " I will tell you at what stages of the product life cycle it is worth thinking about removing features and which pitfalls can be circumvented.
Let's see why remove features from the product at all. An extra feature is one without which the product will be better, and an extra product will be the one without which the business will be better. Removing features and products is worth it for several reasons:
In the product life cycle there are several stages when it is convenient and useful to remove features. I will tell you what to look for and what tools to use to make a decision.
Making a new feature
You have decided to add a new feature to the product. It seems to you that this is a good idea, but it can be the other way around. It is better to kill the feature before you start doing something. There are good tools to test the hypothesis: analytics, custom, market analysis. If, after research, you realize that you do not need to add anything - you are great.
Checking hypotheses
By interviews and analytics it is not always possible to understand whether you need to make a feature. Metrics and feedback from real users are more valuable, so you have to make a prototype. Try not to run it to the entire audience, because deleting or making significant changes will be more difficult and painful. To simplify the task, you can run a prototype on a part of the audience or create an isolated environment for test features. In Wrike we use Labs - this is a closed section in the service, where any user can turn on an experimental feature and leave feedback.
Preparing for release for all users.
After you run a feature on some part of the audience, you need to analyze the results. There is a dangerous story “we have already done” when the feature is written and it can be launched even today. But you need to stop and remove everything that users do not need.
For example, in SEMrush they made analytics for marketers and launched them in test groups. Then we analyzed what was useful. Unsuccessful experiments removed and launched to the entire audience about 30% of the functional. The value of the product has grown, and resources are not being spent either now or in the future.
Something broke
If the feature is already done, it may break at some point. Probably, you will learn about it from the support service or from the fallen tests. However, it is not always necessary to fix a feature or add a fix to the backlog.
For example, for internal teams we did scoring users, which they could integrate to themselves. When the service should have been integrated, we learned that it does not work for more than a month. Let us skip the story, why our monitoring did not reveal the problem earlier - more importantly, we did not immediately correct the problem, but decided to talk with the teams.
Many low priority tickets
Helpdesk receives requests with user problems. After analyzing them, you will see the areas of the product or features that you don’t like to do. Check if they are needed, and if not needed, schedule their removal. If you decide to leave features, allocate resources to correct errors and monitor their status.
Making a new version
When a product is already mature, a lot of obsolete and unnecessary things have accumulated in its code. Sometimes you have to make a painful decision about big refactoring or rewriting the technical part of the functional.
Command overloaded
We made a new version, then a new feature or product, got carried away - and five more products appeared. At some point, the team begins to burn, because you need to support all this. People are demotivated and do not have time. To avoid this, deal with all the products: conduct an interview, collect analytics, analyze the results. Get rid of unnecessary or less priority products or transfer to other teams that have resources.
Feature blocks development or scaling
It happens that some feature imposes restrictions on the scaling and growth of the product. In Wrike, we were faced with the fact that one of the root features, which was used by thousands of users, interfered with the normal scale and development of the product. Despite the risks in the short term, we did a lot of work and removed the feature, simultaneously changing the architecture of the application.
Schedule a review every six months: together with the analyst and the UX specialist, look at the data and analyze what is happening. So you quickly figure out what features or products may become candidates for removal.
When you have already found the problematic feature, the question arises whether to delete or not to delete. In order not to be mistaken, you need to analyze all the data:
When removing a feature, you need to think about the risks:
Assess the risks:
When you have qualitatively evaluated the risks, try to minimize them:
I outlined three scenarios for removing features: bad, controversial, and universal. But each situation is unique, so the same scenario can be good in one case and bad in another.
Bad
You can give the feature to die slowly if you are very busy with other things. But you still have to do it sometime.
Plus: no need to strain.
Cons: feature still takes resources, users are unhappy.
Controversial
Delete imperceptibly. But there is a risk that users one day will not see some kind of screen, graphic or button and will raise a negative wave. Therefore, remove the feature without warning, only if you are sure of small risks:
Plus: easy.
Minus: there is a chance to underestimate the risks.
Universal
Sometimes you can not remove a feature, but sell it to a competitor. If you don’t need this part of the product, it can see the value in it. Or select a feature into a separate product and transfer it to a free team.
Full performance by Yuri Andreikovich.
I work at Wrike , a collaboration and project management service. Wrike has over a million users, but our direct customers are companies that pay for employees. There are about 17 thousand.
More than once I came across the need to remove features from a product, and sometimes they came to me with a request: “We have several thousand users, they use something, and we want to remove it. Act. " I will tell you at what stages of the product life cycle it is worth thinking about removing features and which pitfalls can be circumvented.
Let's see why remove features from the product at all. An extra feature is one without which the product will be better, and an extra product will be the one without which the business will be better. Removing features and products is worth it for several reasons:
- You spend support and developer resources on maintenance.
- Users get upset that you do not develop the feature they use. They do not know that you no longer want to deal with it.
- The team is difficult to focus. If a product manager and a team have one hundred features or several products, it is difficult for them to keep up everywhere.
- Inconsistency appears in the product. For example, you translate all service texts into Russian, and on one screen you support Russian localization, and on the other — non-priority — anymore.
- The total value of the product decreases. Daniel Kahneman as a result of the study revealed a cognitive distortion of the average assessment. For example, if you suggest a person to evaluate the Parker pen, the price will be one. If you add cheap Chinese to the Parker pen, the price of a set of two pens will be lower. The cost of expensive pens will decrease due to the cheap. So the value of the product will decrease due to unnecessary features and grows if you remove them.
8 reasons to think about removing features or products
In the product life cycle there are several stages when it is convenient and useful to remove features. I will tell you what to look for and what tools to use to make a decision.
Making a new feature
You have decided to add a new feature to the product. It seems to you that this is a good idea, but it can be the other way around. It is better to kill the feature before you start doing something. There are good tools to test the hypothesis: analytics, custom, market analysis. If, after research, you realize that you do not need to add anything - you are great.
Checking hypotheses
By interviews and analytics it is not always possible to understand whether you need to make a feature. Metrics and feedback from real users are more valuable, so you have to make a prototype. Try not to run it to the entire audience, because deleting or making significant changes will be more difficult and painful. To simplify the task, you can run a prototype on a part of the audience or create an isolated environment for test features. In Wrike we use Labs - this is a closed section in the service, where any user can turn on an experimental feature and leave feedback.
In Labs, users are warned that we can disable experimental features at any time. Therefore, they do not tie up the processes on these features.
Preparing for release for all users.
After you run a feature on some part of the audience, you need to analyze the results. There is a dangerous story “we have already done” when the feature is written and it can be launched even today. But you need to stop and remove everything that users do not need.
For example, in SEMrush they made analytics for marketers and launched them in test groups. Then we analyzed what was useful. Unsuccessful experiments removed and launched to the entire audience about 30% of the functional. The value of the product has grown, and resources are not being spent either now or in the future.
Something broke
If the feature is already done, it may break at some point. Probably, you will learn about it from the support service or from the fallen tests. However, it is not always necessary to fix a feature or add a fix to the backlog.
For example, for internal teams we did scoring users, which they could integrate to themselves. When the service should have been integrated, we learned that it does not work for more than a month. Let us skip the story, why our monitoring did not reveal the problem earlier - more importantly, we did not immediately correct the problem, but decided to talk with the teams.
It turned out that teams either had backlog stuffed with integrations for half a year ahead, or they already use another service, or they have serious problems in the processes and they don’t have time for that.Nobody would use scoring for the next six months. Therefore, we did not begin to restore anything, but on the contrary, we closed the service and put it off until better times. Work on priority products and features and get rid of unnecessary ones in time so as not to waste resources.
Many low priority tickets
Helpdesk receives requests with user problems. After analyzing them, you will see the areas of the product or features that you don’t like to do. Check if they are needed, and if not needed, schedule their removal. If you decide to leave features, allocate resources to correct errors and monitor their status.
Making a new version
When a product is already mature, a lot of obsolete and unnecessary things have accumulated in its code. Sometimes you have to make a painful decision about big refactoring or rewriting the technical part of the functional.
If the volume of the technical problem is very large, treat refactoring and rewriting as a new product. Understand the problems and analytics to simultaneously remove unnecessary features and increase the value of the product.
Command overloaded
We made a new version, then a new feature or product, got carried away - and five more products appeared. At some point, the team begins to burn, because you need to support all this. People are demotivated and do not have time. To avoid this, deal with all the products: conduct an interview, collect analytics, analyze the results. Get rid of unnecessary or less priority products or transfer to other teams that have resources.
Feature blocks development or scaling
It happens that some feature imposes restrictions on the scaling and growth of the product. In Wrike, we were faced with the fact that one of the root features, which was used by thousands of users, interfered with the normal scale and development of the product. Despite the risks in the short term, we did a lot of work and removed the feature, simultaneously changing the architecture of the application.
Regular Review
Schedule a review every six months: together with the analyst and the UX specialist, look at the data and analyze what is happening. So you quickly figure out what features or products may become candidates for removal.
How to decide on the removal of features
When you have already found the problematic feature, the question arises whether to delete or not to delete. In order not to be mistaken, you need to analyze all the data:
- Vision features and product. If you do not understand why this feature is needed and how to develop it, it makes sense to figure it out. If it does not work out - a good reason to think about deleting.
- Match product and features. Assess where the product and feature are developed separately. When the directions do not match, you can make a separate product from a feature or deploy the whole product in the direction of a feature, if it brings money and grows well.
- Value and workaround. If we select a feature and the user cannot solve the problem in another way, it can be painful. Often people use outdated awkward solutions, even if you have already implemented a new convenient functionality. This may be the power of habit, and perhaps the functionality is hidden behind ten screens. Bring the value of the new solution to the user.
- Metrics. Each feature and product has metrics that help evaluate their profitability and efficiency.
Risks when removing features
When removing a feature, you need to think about the risks:
- You can harm the brand. Maybe you have only five fans of features, but they will destroy the company in social networks and on specialized sites. You need to analyze what kind of people they are and how they interact with support.
- For some, removing a feature can be critical, and it will go away.
- Users of the feature can "derail" support. This will happen if you have not assessed or poorly assessed the risks. You may have to return the feature, but before that it is better not to bring.
It is necessary to work with risks in two stages: to evaluate and minimize.
Assess the risks:
- Analyze analytics: for example, in Wrike, analysts help product managers evaluate feedback qualitatively and quantitatively.
- Talk to support, sales managers, account managers. You may receive unobvious answers that will affect your decision. For example, account managers can say that they use little of the feature and it does not solve the problem, and sellers consider it an excellent trigger for sale and use it in every conversation with customers.
- Be sure to consult with lawyers. Maybe in the user agreement it is written that you are obliged to warn about changes in the product for six months.
When you have qualitatively evaluated the risks, try to minimize them:
- Talk to users. You will understand what kind of people they are and how they can react to the removal of the feature, as well as determine the significance of the feature and the possible consequences of its removal.
- Prepare Q & A for support, marketing and sales to reduce user anger and help teams deal with difficult questions from them.
- Bring your plan to management and act as transparently as possible. If the management, top managers and investors will not understand the risks, you will be the “bad guy” - even if you do everything right.
How to remove features
I outlined three scenarios for removing features: bad, controversial, and universal. But each situation is unique, so the same scenario can be good in one case and bad in another.
Bad
You can give the feature to die slowly if you are very busy with other things. But you still have to do it sometime.
Plus: no need to strain.
Cons: feature still takes resources, users are unhappy.
Controversial
Delete imperceptibly. But there is a risk that users one day will not see some kind of screen, graphic or button and will raise a negative wave. Therefore, remove the feature without warning, only if you are sure of small risks:
- the feature has a small audience
- deletion will not affect the brand,
- You do not have strategic clients.
Plus: easy.
Minus: there is a chance to underestimate the risks.
Universal
- Communicate with users, analysts, sales managers and account managers, lawyers, management. Prepare a Q & A, update the help and other public documents, pages on the site.
- Warn in advance that you are going to close the feature. This will help users to get used to this idea and transfer their data, if necessary.
- Close access to the feature for new users.
- If instead of a feature you make a new functionality, give the user the opportunity to try it.
- Go to the end, because there will be many obstacles and fears.
Sometimes you can not remove a feature, but sell it to a competitor. If you don’t need this part of the product, it can see the value in it. Or select a feature into a separate product and transfer it to a free team.
If the feature hasn't taken off from the first time, sometimes it is enough to finish it. You think that nobody likes her, and she is just hard to find. Conduct tests, collect feedback. Give the feature a second chance.
Check list
- Identify problem features and products: find out why they are not engaged in, whether they need to be developed or it’s time to close.
- Assess the ability and necessity to remove features at each stage of the product life cycle.
- Do research and tests to see if you need to remove a feature or product.
- Analyze the data that you have to decide on the removal of features, as well as product vision and features, product match and features, value and workarounds, metrics.
- Evaluate the risks, act transparently, warn everyone that you are going to remove the feature. Manage user expectations to reduce their pain and maintain loyalty.
- Give the feature a second chance.
- Delete the feature according to the scenario that suits your situation: rely on the checklist, add or delete steps as necessary and make an informed decision.
Full performance by Yuri Andreikovich.
Source: https://habr.com/ru/post/438048/