Product management: from a good idea to an appropriate feature

    Product manager - the position is ambiguous. In the post-Soviet space, a full-fledged product management culture has not yet developed, although there are already quite a lot of food companies. Former business analysts, project managers, marketers and other specialists, each of whom has his own approach to his new tasks, become the “Products”. I would like to share a few points about working with new product features that seem important from my bell tower.

    image
    This is also a kind of product management, but we will talk about something else.

    Disclaimer:

    Hardly any of the following can be universal advice. I mainly deal with services that the user practically does not encounter, which leaves a kind of imprint on the work and the rules that I follow.

    Feature request, good and bad.

    If the product you are working on does not have ultra-narrow specifics, almost everyone you consider will be obligated to send you a feature request. You need to be able to filter them, especially if resources are limited. If a designer with tears in his eyes convinces that your data processing system will come to an end, if you do not bring the interface in line with fashion trends, this does not mean that you need to drop everything and make the system resemble the latest research of Sir Jonathan Quince. Or vice versa: when the programmer defends the point of view that the user does not need hints, because “Everything is already obvious”, this is not a reason to refuse tooltips. In general, many not very good ideas are caused by professional deformation: UX is ready to take care of the user to the detriment of the business, developers prefer a warm tube command line to any interface, Some business guys do not care about anything other than deadlines and money, etc. All this should be corrected.

    For example, I filter freshly invented features like this:
    • frankly weak or dangerous idea, you can immediately refuse;
    • non-obvious feature, additional analysis is needed;
    • obviously a useful feature, put it in the backlog, set the priority.

    Each new feature should work either on the target (without this functionality it is difficult / impossible to achieve the general goals of the product), or on KPI (this functionality will improve existing indicators). These can be either related or orthogonal entities.

    An example of a goal-oriented feature:
    • port the application to Windows Phone so that it is present on all mobile platforms
    An example of a KPI-oriented feature:
    • personalize the “Best Articles of the Week” block to increase the number of pages viewed per user

    If the feature does not match either one or the other, something is wrong with it. Ask yourself and the one who suggested this feature a simple question, “Why?”. Quite often, a feature request arrives, “because it's fashionable!”. By asking the question “why?”, You can separate useful ideas from low-sense fashion trends. There is no need to be afraid to ask the same question to high-ranking bosses who can throw inadvertently thoughtful thoughts on the go, counting on what you take under the hood and immediately begin execution.

    Separately, I want to note that the argument "So the competitors have already done!" It’s not enough to head over to development. It's pretty funny to watch how a particular project blindly copies something down to fairly fine details, not knowing that such an implementation was caused, for example, by local restrictions of the framework used.

    Before starting development

    When planning a feature, it is extremely important to provide for one thing that the user will not see, but useful for the product manager to make the right decisions. This is universal logging. It is not only and not so much technical logs (technical experts should take care of this all the same), but about the business logic of the project.

    Be sure to log everything that does not match the ideal user behavior scenario. If you have all the information about visits that do not fit this scenario, you can always analyze what is going wrong and what time to pay attention to. The planned scenario can be very different from the real one, and without full logs, you will not know about it.

    Consider how you test the effectiveness of a feature. Perhaps this will also require some special logs. Lack of information about the work of the new functionality is an impermissible mistake for the product manager. Make sure that the logs are easily accessible to you and those who participate in the analysis of the project together with you: in large companies it may happen that you have to go around five people from different departments to get the cherished knowledge.

    Utility check

    There is such an antipattern in product management: “Let's make a cool feature, but we'll see!” In such cases, “... we'll see” often leads to “Well, everything seems ok,” which is clearly not enough. The problem is especially relevant for KPI-oriented features.

    Before the feature is developed and appeared on production, you need to decide how the experiment will be carried out, what data will be used and what will be the criterion of success / failure. No need to reinvent the wheel; statistical sciences have long prepared a theoretical basis for thiswhich is easy to follow. This also applies to A / B tests, which are one of the best ways to test the utility of a feature, and any other methods. Without preparing the design of the experiment in advance, it is easy to succumb to the temptation and pull the result by the ears.

    A correctly designed experiment will protect you from incorrect cause-effect relationships. “After”! = “Instead of”; no matter how nice it is sometimes to associate user growth with the wise development of the product, perhaps this is just a temporary external reason like seasonality. For example, increased user activity may be associated with weather conditions, holidays, inaccessibility of competitive projects, etc.

    Instead of a conclusion

    For product management, there is nothing more important than common sense and system. Each decision should correspond to the general line of development, be balanced and considered from different angles. Even an ideally realized and good idea in itself is not necessarily useful in the context of a product.

    Also popular now: