3 key qualities of a successful product manager: Anton Danilov

Product Manager is one of the key roles in technology companies. He is responsible for the business metrics, the success of the product itself, and also the leadership of the cross-functional team that works on product releases and improvements.

Despite the fact that the position of product manager is a serious challenge for potential candidates, many IT market professionals consider it an important milestone on a successful career path. Candidates who consider a position as the next stage of their career are usually interested in two main questions:

• What technological expertise should I have?
• What skills / qualities are key to being successful in this role?

To give an answer to the first question is, in general, quite problematic, since the need for technological expertise is always dictated by the specifics of the company. Therefore, we decided to concentrate on the second point and ask product managers from Wrike what key skills a product manager must have in order to be successful in their role.

Initially, we planned to collect opinions of PM Wrike in a digest, but we were so engrossed in the dialogue with our colleagues that it all turned into a series of articles and interviews.

So, let's begin. Our first guest name is Anton Danilov. Anton - Group Product Manager in Wrike, manages the direction of Enterprise. In the past, Anton was responsible for the online sales infrastructure at Kaspersky Lab, and before that he worked at Microsoft and Sun Microsystems. Total experience in product management - more than 10 years.

- Hello Anton.

- Hi Artem. Thank you for calling to talk.

- I recently spoke to a number of candidates who wanted to send a resume to the position of product manager in Wrike, and they always asked me two questions. First, what should be the expertise in technology. And second, what are the key qualities that a candidate needs to demonstrate in order for you to consider him a successful product manager.

- Well, firstly it is worth saying that judging by the questions, the person is just beginning his way in product management.

- Yes, and I, among other things, want this article to become to a certain extent such an aid. And here's the question I want to ask you: what, in your opinion, are the three key qualities for a product manager?

- Three key qualities are a very difficult generalization. If I bring in only three, then each of them will be broken down into several more, because there are actually not three of them. It will be difficult to call three such, having begun to possess them, a person will become a product manager.

- Let's not be attached to the number, but at the end of the conversation we will count?

- Good. The first is probably the most important - I would call it “product feeling”. I'll explain now.
What is the feeling of the product? It can be said professional distortion, when everything is perceived as a product. Generally everything. Even if it is a product of nature, it is the result of some activity, some process.

And in this sense, it becomes obvious that a person must understand - the result of what this phenomenon has become, and why did it turn out exactly this result? And what is the result - good or bad? And what is measured by “good” or “bad”? And for whom it is good, but for whom it is bad? And maybe there are other ways to assess, which will allow to look at this product in a completely different light. And the “product feeling” necessarily includes an understanding of how exactly to evaluate - a good product before us, or a bad one.

Here we sneak up on global things - in particular, the ability to distinguish the good from the bad. By and large, this is called a sense of taste.
When I talked about the fact that you look at everything as food, you see their differences. Which, in turn, means that some of them are better on some scales, some worse. The product manager understands that products are made for something, they have some meaning, some purpose.

This means that when a person is working on a product, he thinks about what he does for him, trying on some scale to make it better. Products should always think about the user's problem, but sometimes there is a distortion - they start thinking about what solution the user wants from them. And here lies a great danger. Users usually do not think of universal and workable product solutions. Of course, it is right to listen to the suggestions of users, but it is much more important to concentrate on the problems and solve them systematically.

- That is, people do not need a product, but a solution? Peter Drucker , a classic of management in his books, liked to give an example that a person who is engaged in drilling, in fact, needs not a drilling rig, but a hole in the ground.

- Absolutely.

- Accordingly, if you offer him any solution for the appearance of a hole in the ground, do you solve his problem?

“Moreover, in the thinking of Peter Drucker, one more step forward could be taken. A good product manager would ask, “Why do you need a hole in the ground? Do you need oil? And, in fact, in the end, you do not need oil. You need the profit you get when you sell it. ”Here is an example of how you can think. This example is very good. The man in his argument took one step. You can do two more.

And then the product manager who came to the oil company will say: “Ok, OK, this is a company that earns on oil production. How can we produce oil? ” And oil can actually be extracted in a thousand different ways. It is possible to pierce a hole in a certain place almost with a finger in the ground, and it will be driven from there by a fountain. And you can, for example, find another place where oil will be cheaper. And there offshore drilling of some layers, or technologies, where they create pressure with the help of water, break through something. That is, there are a lot of different ways to get oil. And it's not always a hole.

When a person comes to you and says: “I need a drill rig,” this immediately means that the user came to you with a solution. And you say to him: “So, so, wait a second. And what do we want to do? ” And the right conversation should get to the point that the product manager will say: “Ah! I understand you want to make money in this particular place in the oil production. OK". And we may eventually come to the drilling rig (or maybe not), but we will already know a lot about this drill rig, we will give exactly the right drill rig that is needed in terms of power, reliability, some other parameters, and, perhaps, the solution will be not in the purchase of the installation, but in something else, but the user's problem will be solved. I am not an expert in oil production, but this is pretty obvious.

A sense of grocery taste allows us to understand why a product is being made and how to solve a user's problem in the fastest way, but a good product manager also takes into account the company's mission, and even sometimes thinks about how to make the world better around.
At the same time, he does not forget that he works in a company whose main goal is to extract profits by solving a user's problem. It is possible now to place a drilling rig for general use at the desired point. And then complicate it, and then complicate it, and then install the tower. That is, you can take several consecutive steps to solve the problem. The company will start earning on mining gradually, but more and more.

This feeling of grocery taste and understanding of what a product is, how it is built and how to solve user problems with the help of a product, and the desire to live it is one of the main features of a product manager. Simply put, he must be obsessed with the product and think of the product.

The second key quality is developed communication skills.
A product manager is a person who actually does nothing. He may not write a single line of code in his life. In essence, this is a person who is a creative transmission and connecting link, a translator and a translator. The most valuable thing he has is people who trust him, who work with him, this is his team. And here is included a very important aspect associated with the leadership component, with inspiration, with motivation. The product manager is responsible for whether his team wants to listen to him, whether he wants to understand what kind of product we are going to do.

- I understand correctly that a product manager, before the team starts to work, must “sell” the product idea to it?

- This is a simplification, but yes. He should be able to work with the team in such a way that the team wants to do it. He should be able to work in such a way as to motivate the team for the best that the team can do.

- Clear

- But not only that. Not only inspire the team to work. It is also the ability to work with conflicts, with objections, with demotivation, with emotional burnout.
This ability, for example, not to concentrate all responsibility in their hands, and not to say: “I’ll tell you what to do now”, but to build work with the team in order to get the effect of multiplying the efforts of the team. This is a very important point, because one head is good, two is better, and the sum of the team’s goals is many times better.

- I clarify once again: you said that the product manager is not the person who sits and writes the code.

- Absolutely not.

- Does this mean that theoretically the product manager may not have a technical background? And come, for example, from sales?

- I'm sure yes. Very often, people come into product management with a technical background, but it helps them not in the sense that they, as developers, understand technical architecture in the sense that structural and logical thinking is usually instilled into the technical background. It helps later in the work.

There are cases when deep integration or some other complicated things are included in the product manager's skoup. When designing a technically complex decision, of course, it will be difficult without understanding what language the developers speak. In such cases, the technical background is desirable, but I would not say that it is one of the key. I am absolutely sure that you can be a product manager, not understanding anything in the technical component. Very often, despite the fact that I have a degree in applied mathematics, I say to my team: “Listen, I don’t understand this. Tell me how it works. ” The team responds: "You need to write a component here." I ask: "What does this mean?". And so on.

- So these are normal questions? By asking them, don't you look stupid?

“Such questions can even bring PM closer together with the team, because you build communication in this way:“ I am an expert in my field, and you are experts in your fields. Let's combine our professional skills to achieve a common goal. ” Developers remain experts in their field, Piem - in their own. This is what concerns the leadership component. But that's not all.

In addition, a product manager is a person who works very much with stakeholders within the company, starting with direct management, to top managers and heads of neighboring areas.

A person should be able to speak different languages ​​and at different levels. For example, with his team he speaks a much more detailed language. Paints history for them in one way. But at the same time, when he comes with the same story to people of a much higher level of abstraction, for example, to top managers, he speaks briefly, succinctly, clearly. He can generalize, speak the language of business. That is, he understands who needs what information to convey.

Accordingly, there are three levels. There is a level of work with product managers of your horizontal. There is a level of work with the team. And there is a level of work with stakeholders. At each level, the colleagues of the product manager have their own motivation and picture of the world, their own idea of ​​reality. Success depends on how clear and transparent the communication will be. Therefore, the ability to work competently at all three levels is the communication package, which is very important for the product manager, but a whole separate conversation could be held on this topic.

Probably the third skill, I would highlight what is called execution. When a product is planned in conjunction with a team, the product manager must make an organizational effort for the release to take place. An important factor is the understanding of how to decompose a product into fragments. It can be broken down so that it will be in development for two years, and, in the end, nobody will need it. And you can break so that he immediately began to bring value. PM should understand where and how the product will be produced, for which customers, where and what risks this system has, how to break this development into fragments. And finally, how the decomposition will look at the level of scrum / agile. Here, as you understand, we are talking about the realities of the grocery organization.

This is a tactical thing, but, in fact, the ability to make sure that you get from the idea to the realization and measurement of results, the ability to carry the fire with you all the way, without losing it. This is not a sprint, this is a marathon, and the product must be able to run through this marathon.
On the other hand, beginner product managers often have a desire to make the solution ideal and not release it “ahead of time”. There is a fear that the result will be “not very”, and, not having great authority, the product will receive a low assessment of its activities. But in fact, this look is more likely from the level of the team. At the stakeholder level, quickly delivered value, a proven and confirmed or refuted hypothesis, and well thought-out subsequent iterations are much more valuable than a perfectly released product, in which there are many, many, many features, but which have been done for a very long time.

- For example, an addon is being prepared, and potentially this addon will have a very great value for customers. At the same time, it is still damp, but someone is ready to buy already in the current iteration. In your opinion, it is better to release more quickly and then deal with the consequences or determine some, so to speak, good is good enough level and take the time?

- Competently making such decisions is the work of the product. If the product manager is working on some very valuable add-on, he is very good at representing, for example, that there are five customers who leave if he doesn't give them anything. He can interview them and understand: four of these five, in principle, I can turn on the preview now. This development will not be available at all, it will be a closed beta. And then, having improved the functionality, it can be released to a wider audience.

In Wrike, we have a whole cycle of major functionality release. There is an internal beta - this is when we are ready to open the functionality only for internal users. We have a closed beta when we invite some selected customers and enable them to new features. Customers give us the first feedback, and the value is already beginning to be provided.

Then we release the development in Labs, when we enable the functionality of loyal customers who agree to give their assessment and feedback. Then - a public release. Next is the stage of improvements and iteration. Not all releases go through each of the stages of the path, but the full cycle looks like this. It is designed precisely for us to bring value to customers as quickly as possible, but at the same time gradually increasing this value, and collecting feedback on the way, making the product better and better. This is an iterative approach to design with value delivered quickly.

To summarize, if you try to highlight the three main qualities of a successful product manager, I would highlight the product's sense and ability to solve user problems, communication on three levels - with the team, colleagues and stakeholders, and execution - the ability to get things done, and do it iteratively, delivering value and correcting direction with feedback as quickly as possible. Each of these qualities is in fact a complex combination of competencies, skills, and experience, and each could be discussed in more detail and in detail. Perhaps we will sometime return to these questions and discuss them again.

Do not miss the report of Anton Danilov at the ProductSense conference, which will be held in Moscow on April 15-16.