Product management: from a good idea to the appropriate feature
Product manager - an ambiguous position. In the post-Soviet space has not yet developed a full-fledged culture of product management, although there are already quite a few product companies. The “products” are former business analysts, project managers, marketers, and other specialists, each of whom approaches his new tasks in his own way. I would like to share a few theses about working with new product features that seem important from my bell tower.
This is also a kind of product management, but it will be about something else.
Hardly any of the above can be a universal advice. I mainly deal with services that the user practically does not encounter, which leaves a peculiar imprint on the work and the rules that guide me.
')
If the product you are working on does not have an extra-narrow specificity, almost everyone he counts considers it his duty 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 into line with fashion trends, this does not mean that you need to drop everything and make the system resemble Sir Jonathan Quince's latest research. Or vice versa: when the programmer defends the point of view that the user does not need prompts, because “Everything is obvious”, this is not a reason to abandon the tooltips. In general, many not-so-good ideas are caused by professional deformation: UX is ready to take care of the user to the detriment of business, developers prefer a warm lamp command line to any interface, some business guys don't care at all except time and money, etc. All this should be amended.
For example, I filter new features like this:
Each new feature should work either on the goal (without this functionality it is difficult / impossible to achieve the overall goals of the product), or on KPI (this functionality will improve existing indicators). It can be both connected and orthogonal entities.
An example of a goal-oriented feature:
If the feature does not match either one or the other, something is wrong with it. Ask yourself and the person who offered this feature the simple question “Why?”. Quite often the feature request comes, "because it is fashionable!". By asking the question “why?”, You will be able to separate useful ideas from obscure fashion trends. Do not be afraid to ask the same question to high-ranking bosses, who can go on the move not fully thoughtful thoughts in the hope that you take a visor and immediately proceed to the execution.
Separately, I want to note that the argument “This has already been done by the competitors!” Is not enough to take on the development head-on. It is quite funny to watch how a project blindly copies something down to fairly small details, not knowing that such a implementation was caused, for example, by the local restrictions of the framework used.
When planning a feature, it is extremely important to provide for one thing that the user will not see, but useful for making the product manager the right decisions. This is universal logging. This is not only and not so much technical logs (the technical guide should take care of this), but the business logic of the project.
Be sure to log everything that does not correspond to the ideal scenario of user behavior. If you have all the information about visits that do not correspond to this scenario, you can always analyze what goes wrong and what it is time to pay attention to. The planned scenario can be very different from the real one, and without having full logs, you will not know about it.
Consider how you check the effectiveness of the feature. Perhaps this will also require some special logs. The lack of information about the work of the new functionality is an impermissible miss by the product manager. Make sure that the logs are easily accessible to you and those who participate in the project analysis with you: in large companies it may happen that you have to go around five people from different departments to get to the cherished knowledge.
There is such an anti-pattern in grocery management: “Let's make a cool feature, and then 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 base for this, which is easy to follow. This also applies to A / B tests, which are one of the best ways to test the usefulness of a feature, and any other ways. Without having prepared the design of the experiment in advance, it is easy to succumb to the temptation and pull the result by the ears.
Properly designed experiment will protect against incorrect causal relationships. “After”! = “Instead of”; no matter how pleasant it is sometimes to associate the growth of users with a wise product development, perhaps this is just a temporary external reason such as seasonality. For example, increased user activity may be associated with weather conditions, holidays, inaccessibility of competitive projects, etc.
For product management, there is nothing more important than common sense and system. Each decision should correspond to the general line of development, be weighed and considered from different sides. Even a perfectly realized and good idea in itself is not necessarily useful in the context of a product.
This is also a kind of product management, but it will be about something else.
Disclaimer:
Hardly any of the above can be a universal advice. I mainly deal with services that the user practically does not encounter, which leaves a peculiar imprint on the work and the rules that guide me.
')
Feature request, good and bad.
If the product you are working on does not have an extra-narrow specificity, almost everyone he counts considers it his duty 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 into line with fashion trends, this does not mean that you need to drop everything and make the system resemble Sir Jonathan Quince's latest research. Or vice versa: when the programmer defends the point of view that the user does not need prompts, because “Everything is obvious”, this is not a reason to abandon the tooltips. In general, many not-so-good ideas are caused by professional deformation: UX is ready to take care of the user to the detriment of business, developers prefer a warm lamp command line to any interface, some business guys don't care at all except time and money, etc. All this should be amended.
For example, I filter new features like this:
- frankly weak or dangerous idea, you can immediately give up;
- non-obvious feature, need additional analysis;
- obviously useful feature, we put in backlog, we set priority.
Each new feature should work either on the goal (without this functionality it is difficult / impossible to achieve the overall goals of the product), or on KPI (this functionality will improve existing indicators). It can be both connected and orthogonal entities.
An example of a goal-oriented feature:
- port the application to Windows Phone so that it is present on all mobile platforms
- make the block “Best articles of the week” personalized 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 person who offered this feature the simple question “Why?”. Quite often the feature request comes, "because it is fashionable!". By asking the question “why?”, You will be able to separate useful ideas from obscure fashion trends. Do not be afraid to ask the same question to high-ranking bosses, who can go on the move not fully thoughtful thoughts in the hope that you take a visor and immediately proceed to the execution.
Separately, I want to note that the argument “This has already been done by the competitors!” Is not enough to take on the development head-on. It is quite funny to watch how a project blindly copies something down to fairly small details, not knowing that such a implementation was caused, for example, by the 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 making the product manager the right decisions. This is universal logging. This is not only and not so much technical logs (the technical guide should take care of this), but the business logic of the project.
Be sure to log everything that does not correspond to the ideal scenario of user behavior. If you have all the information about visits that do not correspond to this scenario, you can always analyze what goes wrong and what it is time to pay attention to. The planned scenario can be very different from the real one, and without having full logs, you will not know about it.
Consider how you check the effectiveness of the feature. Perhaps this will also require some special logs. The lack of information about the work of the new functionality is an impermissible miss by the product manager. Make sure that the logs are easily accessible to you and those who participate in the project analysis with you: in large companies it may happen that you have to go around five people from different departments to get to the cherished knowledge.
Utility check
There is such an anti-pattern in grocery management: “Let's make a cool feature, and then 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 base for this, which is easy to follow. This also applies to A / B tests, which are one of the best ways to test the usefulness of a feature, and any other ways. Without having prepared the design of the experiment in advance, it is easy to succumb to the temptation and pull the result by the ears.
Properly designed experiment will protect against incorrect causal relationships. “After”! = “Instead of”; no matter how pleasant it is sometimes to associate the growth of users with a wise product development, perhaps this is just a temporary external reason such as seasonality. For example, increased user activity may be associated with weather conditions, holidays, inaccessibility of competitive projects, etc.
Instead of 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 weighed and considered from different sides. Even a perfectly realized and good idea in itself is not necessarily useful in the context of a product.
Source: https://habr.com/ru/post/201496/
All Articles