What does it take to implement a new feature in a network
It frequently happens that in various customer feedback channels users try to recommend some “really necessary feature” or “definitely needed tool” that they propose to implement as soon as possible because it will save the world, apparently. After all, it seems to be very easy to add a small feature and put some business logic in it to save Bruce Willis and Jason Statham the trouble, rescue the world from danger and help affiliates earn more money.
Below, I will describe the process that stands behind adding a new interface feature into major products and how many people can actually work on it.
Customer feedback is a crucial development tool for any product, and that’s why major companies try to receive feedback through various channels and analyze it as thoroughly as possible to make a decision on the development of new features. Many ad networks run support chats and create Telegram channels where they answer users’ questions.
In the majority of cases, feedback is analyzed by a product manager who can then discuss it with users and comment on various proposals. These proposals are not always valuable and relevant for all users, and that’s why any update that has been accepted for consideration is called a “hypothesis” and must be validated in terms of its relevance and the cost-effectiveness of its implementation.
The validation process typically includes the analysis of the proposal itself based on the number of similar recommendations, as well as examining the cost of development, implementation and user adaptation. In small scale companies, such hypotheses are validated at strategic planning meetings or at regular product discussions. On the contrary, in major companies, this process can be much more complex and typically involves various preliminary tests or discussions with a wide range of decision-makers or just industry experts.
When the hypothesis passes the validation process, its development is being planned jointly with teams that can implement it technically. Besides, major companies also involve analysts in the development process who are supposed to measure the effectiveness of a new feature after it is implemented and collect certain statistics beforehand to be confident that an update will yield positive results.
Regardless of a company’s size, development teams always have a certain plan of activities that is drafted based on a long-term strategy for a year or half a year ahead. To secure the necessary time and resources, a product manager has to prove the relevance and profitability of a new feature to the management and sometimes to a development team.
As surprising as it may sound, if the company uses Agile or SCRUM software development methods, product managers do gather the entire team at the strategic planning meetings to discuss the goals and general profitability of each new feature. What’s even more surprising is that a team can actually challenge this decision and refuse to start working on a certain feature. For instance, a team can do so because they don’t see the potential benefits of an update or prioritize and believe in other goals that in their opinion are more important for the company.
So, a feature has been discussed, priorities have been assigned, and now the work on the task can actually start. Since almost all companies use agile development methods and adjust them to their own needs (after all, these methods are called “agile” because they can be used selectively), the development process is divided into small increments that are generally called sprints and last from one to two weeks. At the end of this period, the development team is supposed to present the end product. This cycle typically includes not only the development process itself but also automated and manual testing.
After the implementation in the test environment, a new functional feature has to undergo manual testing and is then demonstrated to the client, namely a product manager and the representatives of a certain business department, for instance, a sales team.
When it comes to the implementation of any feature, the best approach is to carry out A/B testing on users or some tests on a particular group of users. Sometimes these tests are conducted on a special group of users who have agreed to beta test a new feature and are not afraid of change but are rather knowledgable about the subject and are able to provide articulate and impartial feedback. There are also other sample types, for instance, only new users or only credible partners in direct contact with a company’s support team or managers. There are also other options where a new feature is measured by internal metrics, which is carried out by the analytics department if a company has one.
We have finally reached a point where the developed and tested feature can be unveiled and demonstrated to the users. This stage is a crucial one, especially if these updates affect a huge number of users that must be informed about the new features and sometimes even taught how to use them.
After testing, bug fixing and collecting sufficient statistical data, the feature is finally available to all. The users receive a newsletter or a message in their personal account describing the updates and a short user guide.
This stage is considered final, but in fact it is preceded by another step where a product manager jointly with the development team write software documentation for the support team and account managers, as well as plan and hold internal training meetups where they describe how a new feature can be used and where one can find information on it.
The described operating procedure is relevant only for large scale products and teams. There are some relatively small companies in the market where this process is simplified and does not take that much time. From the perspective of a major company, however, this is the only possible method of work that allows for the exact calculation of costs and profit, as well as enables one to prioritize all the features according to their end value and measure the effectiveness of each update.
At first glance, this process may seem very long and tremendously time-consuming. However, if all the internal development processes have been organized properly and effectively, then this mammoth task will only take a week or two.
In conclusion, I would like to remind you once again that feedback is always a must have and one of the most important development tools for any high-quality mass product. As you now know, a seemingly simple proposal is not always easy to implement. However, the more accurately you will describe the relevant issue, the more chance that a new feature will be finally introduced. Moreover, many companies now encourage detailed feedback and assistance in working on the product with various bonuses such as transferring a small amount of money into your account or granting life-long privileges in the use of a product.