How to create effective product teams?

Many had to deal with a situation where the manager requires a team of unicorns with a rainbow skin, and the deadline was yesterday. In such a team, work can turn into an eternal conflict, everyone is trying to protect their interests and everyone completely forgets that they initially came together to make a quality product and communicate benefits. Such a team can hardly be called effective.



About what an effective product team is, how to build it and what needs to be done so that all team members are maximally involved in the process, we talked with experts in a panel discussion that took place in our office. Together with us, answers to questions were sought by Roman Abramov (CarPrice product director and founder of ProductStar), Mikhail Aleksandrovsky (Founder Dostavista), Anna Boyarkina (Head of Product Miro), Ilya Krasinsky (CEO Rick.ai), Michael Yan (CEO ManyChat) . Details under the cut.







On August 8, a panel discussion took place in the office of ManyChat, at which they discussed the topic of building an effective product team that is relevant for many companies. The invited experts were





The meeting was moderated by Kira Matveeva, product director at the Lamoda Group. During the discussion, we discussed what tools and processes exist, how to unite and direct a team, help employees grow and develop, maintain motivation, pump skills, and also answered questions from the audience.



For those who especially appreciate the effect of personal presence, we suggest watching the broadcast recording . For everyone else - a detailed transcript of the discussion. Enjoy reading!







What is a product team, what is its difference from a non-product team?



Roma:

A product team is a team that saws a product, most likely online. In my understanding, it may include developers, testers, marketers, designers (especially). These are not just products. The task of the products is to lead and organize this team. So that they feel good together, and that all this leads to a result.



Ilya:

Let's add a holivar right away so that it is not boring: when everyone agrees with everyone. I am always bombed when the product team "saws the product." By the way, the team differs from the employees in that the team members are united by one goal. I love the teams that are responsible for the money, and then it turns out that 60% of the time you don’t need to cut the product. On the contrary, it is necessary to throw out the unnecessary from it.



Michael:

Let's continue to holivarit. I do not agree that the team is about money. It's about some product metrics. Product and non-product teams are different in that non-product teams have goals in non-product metrics. Nothing more.



Michael:

Let's add something else to this. Usually everyone agrees with everything, but here they started with a dispute. We had a big question - whether the products are responsible for money or some other metrics. I recently read a good thing on Product Star : "The goal of the product manager is to raise the company's revenue." It seems to me that this combines different points of view, because different companies at different stages can have completely different goals. And the product team goes to the company's mission through the tasks and goals that this company now faces. At the very beginning, you may have the task of reaching profitability. Then, when you come to profitability, you continue to grow, then you can think about many other things.



Anya:

This is a very complex, controversial and strange question. Each of us added our own meanings. If you think about it, the product manager and product team is a team that has a product at its disposal, and through it the team affects the metrics, the company's business, and the achievement of goals. I agree, they can be different. It can be capitalization, it can be money, it can be some other indicators. In the general case, this is not just a story about the team sawing some features (although this is cool and interesting), but about how the team solves the problem of achieving the goals of the company.



Team structure, roles and types of organization. Who can be in the team, and what are the areas of responsibility?



Anya:

I think it’s interesting to tell ... At one time, we decided to split the team into a team of a basic (core) product and a growth team. Somewhere 3-4 years ago, when we prioritized tasks, there was always a conflict of interests: what we invest in - in the development of product functionality or in experiments. Making value or trying to scale it? One of the cool solutions that works at this stage (I’m not saying that it will always be that way): a separate team was allocated for growth. You need to understand that we have the whole business divided into two conditional parts: part of the profit is generated from self-service, when some guys come and buy a product, and there is also a human-touch business with a sales department. It is in self-service that the growth team works and provides GoToMarket (approx. GoToMarket - entry to the market) for new products. The team employs 20-22 people: product managers, designers, developers. There are 4 product managers.



Ilya:

That is, these are, in fact, 4 teams that have certain metrics, they can figure faster, and so on. And the infrastructure teams that control them so that they don’t heal anything.



Anya:

What does infrastructure teams mean?



Ilya:

I love this scheme: you need to do quick experiments. This is a completely different type of team, the developers accept the rules of the game that “we are not doing it right now, right, with design patterns, database and ORM. We are making a stub; they have thrown the front, rolled it out as soon as possible, and so on. ”



In this case, the problem arises that a lot of teams start to make a lot of trash code, its quality drops, so they are strengthened by infrastructure teams that do code reviews, insure the quality of the code, and so on. Features are focused on product metrics and quick experiments, infrastructure teams - on code quality, complex and long components, engine, refactoring, etc.



Anya:

Yes, in general terms. There must always be some kind of foundation that allows you to do quick experiments.



Michael:

We also have something similar. Some time ago, we divided product development into Core and growth teams. Each team has squads (approx. Squad - a team) that deal with something separate. Like many companies, we began to separate development and products. But when growth began, we began to make squares where there are developers, products, analysts, and someone else, if necessary, for example, DevOps. Initially, the developers obeyed the service station and nothing more. Now they also obey him, he dismisses them, raises them, and that’s all. But at the same time, the developers are also members of the squads. This works well, the code is maintained in good condition. Initially, we have all the developers of Signora. This is also bad when there is no movement, when someone is teaching, raising someone.



Ilya:

But do you have some kind of asymmetry, some teams are focused on quick experiments, others are on code checking and refactoring: billing, for example, is an eternal painful topic that is sawed and refactored for a long time?



Michael:

There is an infrastructure team that is not in the growth team, it deals with the deep, "intimate parts of the code."



Anya:

We have one too!



Ilya:

I will add. There is one thing that I do not see so often. What is cross functionality? When we do not run to another department, because we have designers and developers on the same team. And I really like to add sales managers to the product team so that they stay there part of the time. There are customers, and sales managers communicate with customers, understand what they need. And there is a product team that is involved in product development. I like to bridge the gap between sales managers and the product team. I want the sales to come into support and development and talk about what is going on, somehow influenced.



Michael:

We have an interesting point. We were originally a remote team and tried to get growth as little as possible. When we became more than 20 people, we gathered in the first Moscow office. Then we got an office in San Francisco, we hired a local cool dude from Atlassian who built big stories. He also began to hire local people. And we had a problem that marketing began to separate from the product team.



Now we are starting to build new teams. We started sending developers to the office of San Francisco. They help marketers with their knowledge and skills.



And now we are forming two growth teams that will unite in one era (approx. Product Area, a product line combining several product teams) and will work together with marketing. They will have their own metrics and their tasks. One team will be in San Francisco, the other in Moscow. And in order to achieve their goals and move forward, they will need to constantly synchronize. I can’t say that this is already working, but it seems to me that it will be cool.



Roma:

From the interesting, I can say three things. First, our trend is “less, but better.” There were 100 out of 600 people in IT. Now there are less than 50 people, but they are doing better and more. Three strong developers, even without a product, will do more than 10 bad ones with a product. As a forge of personnel, we have a Kirov branch.



The second trend and reality is that we have a lot of offline. Business is not only sales, but also huge retail, franchises throughout the country, huge warehouses, thousands of cars that completely turn around the whole country in three days. For all this, we do CRM, all the bindings that people need. This is often neglected by people with an online background, but this is important, and it's a great story.



The third trend - we transferred all IT to remote work. The results have doubled, the turnover is zero. Previously, a junior came, we trained him, he mastered it, and as soon as he raised his hand, he was swept away - in Avito, Cyprus. Now everyone is happy, they are working at home, the wife is nearby, the productivity is excellent, a good motivator for the developer, everyone is good.



We switched gradually as an A / B test. We have the OKR business system, we have been using it for two years, it helps a lot to synchronize with the business. At first there was one day from home, any. Then there were two days from home, then three. This quarter was entered all week from home. While everything is working cool, people are happy, there are results. I believe that this is the future - why sit in a stuffy office, pay rent.



There is only one plug - these are processes. The main problem was discrimination against remote employees. “Why are we going to connect some dude who is sitting out of the house. Let him sit there. ” But when everyone understands that tomorrow and I will sit from home, everyone connects everyone. I myself work remotely.



How to make sure that all remote employees are involved as much as possible?



Roma:

Everything is decided by practice. If you write to an employee, but he is not online, if Slack does not have the status “went to lunch”, then next week he sits in the office. A person must be responsible, if he works remotely, he must be available constantly.

SkyEng talk a lot about their practice in this area. One of the major providers says that you can work while standing, and use an ironing board as a stand. I bought a comfortable chair, I'm sitting at the kitchen table, talking on Skype, everything is fine.



Ilya:

The office should be there so that you can get together and discuss ideas. But the cool thing about the remote thing is that people are sitting and doing their own thing, nobody distracts them once again. Cool when the number of meetings is minimal. The most important thing, in my opinion, and what we teach onboarding as a team:



  1. How is the task posed. This is an eternal problem. We use the situation-problem-solution framework (see the first 2 chapters of the Minto pyramid book) and set the task from the result, that is, answering the question of what to do and what the result should be.
  2. Culture of mining: first, team members write the text, then call up and discuss blockers and questions briefly or plan deep actions.
  3. Culture of delivery of the result, including intermediate.



    In general, distributed teams are about adults who know how to manage their time and help them do it effectively.


Is product and project one person?



Anya:

The product must decide whether they need a project or not. If you need to move things forward, then who cares?



Michael:

We had a graduation of products in which we saw gradual growth. By the way, Roma talked about this before the panel discussion . For us, the first level product is when you can take a problem from the backlog and solve it. When there is a specification and description, you only need to complete it. The second level is to find a solution when the user's “pain” is known. Any person of level 2 must be able to and level 1. The third level, when there is a specific metric at the input that you need to influence, and there are already problems and opportunities for it. The fourth level is working with strategy. In the current component, the product, which is located inside the cross-functional team, either performs the functions of the project manager itself, or (better) the team itself has a distributed function of the project manager. When a team is small (for example, 6 people) and worked together, and sprints are short, a project manager is not needed. For larger units - eria, which consist of several teams, there is a product owner, who can also work directly with product managers within teams. So now we have no project managers in ManyChat.



Anya:

Often in different interviews they ask me: “Do you have a product engaged in project management”? It's cool when there is a team that moves itself. But still, this is an important skill, and you must understand how to do it. If you need to come to a result, you need to be able to solve issues. Therefore, I believe that skill should be, because without it it is very difficult to move things forward, especially in situations with a high level of uncertainty. It may turn out to grow a team that will do everything by itself, but you need to be able to do this.



Michael:

The product must be responsible for ensuring that the result is achieved. And how this is done is not important. If there is competence within the team - this is cool. If not, you need to make up for it.



Michael:

We historically had a different project and products, then the number of teams increased, and we realized that we did not need a separate project manager. When everything is more or less adjusted in teams, it is not required. A project is needed when a new team is formed, it needs to be built, processes should be adjusted. We need a person who knows how to do this. But if he continues to be needed, then something is wrong on the team. Each team decides how it works. Initially, the projects participated in all this. Over time, several projects remained, they are not assigned to specific teams and do other things.



Ilya:

Very close to the pattern that "we profess." Thanks to Maxim Dorofeev, a phrase such as “a man with assholes” appeared in the industry. This person is very easy to identify, he often works on weekends, and if he goes on vacation, then everything falls apart in the team. He pings everyone all the time so that they come to daily meetings. There is such a class of guys who lock everything on themselves, and problems arise. It turns out a “manager-pass” that constantly transfers tasks between people with a loss of meaning along the way.

Our products can act as projects in a team, they can promote tickets in the system. But we really love it when developers write tickets themselves. Our project counts metrics, visualizes problems in the team, monitors how many tasks are in progress, looks at the speed of progress, estimates where the tasks hang - whether they are code reviews or not. It helps to make diagnostics. The project is outside the team, in the sense it does not close the process to itself, but it helps, facilitates, and they are at the launch stage with the team.



The project manager is a “word cover” into which you can stuff anything. In general, if an employee wants to, I can give him the position of Queen Victoria. What difference does it make? Someone likes the term “Scrum-master”, someone likes the “process facilitator” more.



Michael:

Agile Coach ...



Ilya:

I love them from a distance ... I love them very much, but from a distance.



Novel:

Many guys come to our courses who work in the role of a project. They come with considerations that they know better what to do than other guys, they want to learn new skills, for example, to learn how to communicate with users and so on.



But I’m sure that the person who is responsible for the result should not just give promises without looking back at the team, but clearly understand that he has “under the hood”. He can draw castles in the air, although maybe another year will have to do refactoring. Only then can he ensure the result.



How to develop in a product team?



Roma:

When I went here, I tried to aggregate in my mind with what questions come up in development plans. The most common questions:

First question: where to find the mentor? Can you become my mentor?

The second question: what course to choose, what to read?

Third question: how to grow if you have already become someone?

The coolest thing is when your mentor is your leader. I myself sought to ensure that my leader was a mentor. The mentor from the outside does not know the context of the issues that you decide, and there are a lot of minuses in this. But each company has information levels, and the leader can know even more than you. He can advise what to do without even going into details.



How to pump? The product profession is very diverse and versatile. But in different places of work different skills and abilities are needed, they must be pumped from different sides. There are B2B and B2C products, and these are completely different stories. What the guys are talking about mass products, in B2B it will be 80% useless. You need to study everything and choose where you are interested in digging.



Third, what to learn, where to run, if I'm already cool. I see that in this room there are many cool and experienced guys, and many of them think that they have already heard all this, and there is nothing new. But the most important thing is not to think that you know everything better than others. The more you expand the field of knowledge, the more it has contact with reality, and the more you do not know. If it seems that you know everything, then you are degrading.



Need to expand networking. For example, I set a goal for a year every week to meet and drink coffee with cool dudes - those who are cooler than me or who are comparable to me. Now this is a habit: I just suggest someone to meet, drink coffee. We discuss the automotive market, remote work and so on. I tell what I found out, and the guys what they know.



If you already have a lot of knowledge, then you need to share it. It pumps you further, because when knowledge needs to be structured, you run through it again, fill in the gaps, start to think why it is so and not otherwise, whether it is possible differently, on which it depends. By themselves, these reflections already give a boost. Go to conferences, participate in meetings, come to conferences, you can visit us at webinars.



Ilya:

Everything is much simpler with me. It so happened historically that I have been engaged in education and educational products for a long time, including doing courses specifically for products. For me, pumping is my daily work. The team has a joke that when Ilya gets tired, he starts reading a workshop or designing a design.



One of the first things I do (thanks for this to Misha Trutnev, who suggested), I pay attention to what skill each person pumps, non-stop. For example, a product team comes to you. They tried hard, put a lot of energy and emotions, but they got complete crap. How to explain this to the team so that they don’t lose their motivation, but run to refine everything. This method helps me: praise a person (just for the cause), explain everything, but at the end to explain what skill he is pumping now, to show that he is growing. Someone lacks the ability to write text, someone engineering things. Many products are afraid that they do not understand the development. When you show what skill the guys are swinging, it inspires and gives feedback. They begin to work with redoubled energy - this is true in 90% of cases.



Second - I put everything into skills. We are being diagnosed, at what level the team is, what they are doing. If the stage is now MVP, what hypotheses do they test. What stably "flies" at teams? Many are afraid to do custdev, especially in another country. They do not know how to communicate with users, do not know how to segment, do not know how to try and make mistakes. Therefore, a lot of my work is team support. Either you need to strengthen the team, or you need to cheer them up.



About personal development - this is for me the most painful issue for 10 years. Then I formulated that I want to spend 30% of the time on my development. And then it was very easy to do, but now everything is more complicated. You go to the plateau when you do not understand how to pump further, what to do. I agree that there are many coaches and mentors, and every year it works worse and worse, at least for me. I decided that I was raising my bar.



A friend invited me, I came to the second company, assigned CEO 2 a day to work, and since I don’t have the opportunity to lock projects on myself there, I have to constantly delegate or help, act as a coach. In this company it’s easier for me than to develop a business from 0 to 1, because there are tens of millions of users around the world, money flows. As a result, the slightest change in conversion pays for any investment in the team.



Now there are five teams, the cost of each is $ 15,000. If at least one team succeeds in doing something, it gives a profit of 20-30 thousand, if it turns out well, then 50-60. This pays off the whole "circus with horses." Growing up at this stage is quite simple, but from 0 to 1 is very difficult. The time limit in this company sets me the bar for growth. You can take an additional product, improve your discipline, limit the time.



Michael:

There are times when someone shares something in our company. But we can’t say as in Google: "Do 20% of the time what you want." It all depends on what goals the company faces. Therefore, any question “how do you do this” should begin with what goals the company has, at what stage it is.



For example, everyone is very fond of talking about turquoise structures. But the huge problem is that if you are superficially acquainted with the topic, inspiration comes first, and then you understand - it is an analogue of the organism where each cell already “knows” what function it will perform. That is, the right people gathered for a specific task may be successful, but in a different situation, all this may not work.



Regarding development, I believe that theoretical training sets the stage well. But in reality, all the decisions we make come from understanding. Recently, we discussed the understanding of a product, and such a moment surfaced: a good product quickly and cheaply makes better decisions than another person. This is only possible if you have a real sense of product, market and people. You need to accumulate in yourself these substances. I recently traveled to Australia, and one of the things I did was schedule 10 interviews with agencies that use our product. I had two-hour meetings at which I wanted to find out how they work. I spent this time feeding my neural network with information. The model of the world is stored in the neuron, and the closer the internal model of the world is to the real one, the better you will conduct the simulation (think about whether it will come or not). Feelings appear, sensations that are worthless. It's like a photo, which can be in high resolution, or maybe a couple of pixels - it seems like something is visible, but the details are not clear. Each time you chat, you add “new pixels” to the picture. That is, you can immediately understand what works and what doesn’t.



Therefore, we believe that learning takes place in the process. And for this you need to set the tasks in the specific metrics that follow in a cascading manner from OKRs. There is a big mission, annual goals, quarterly and so on, come out of it. It is necessary to give a person the opportunity to learn, the freedom to achieve or not achieve a goal, to also create tools, introduce mentoring to support people. When a person is faced with the reality that he cannot do something, he begins to look for opportunities and pumped.



Anya:

I completely agree about pumping the neural network - this is perhaps the only way to train myself. When you immerse yourself in a new topic, you need to quickly train your neuron. If you are a product manager, and you are solving a problem, you need to find your counterpart from a successful company. After all, when we do something, we often don’t know something ... simply because we don’t know it. You need to ask such people as many questions as possible. For example, you never hired people. Then you need to find someone who did this, find out what difficulties are. Having made a picture, you can go and try to apply it. As it deepens, it so happens that new questions arise. You can also go for advice on them. We can all be pumped that way. You can read a bunch of books, but nothing happens without action. The difference between learning or not is in action. If you go and do something, it changes a lot. We, as a company, teach people to find their counterparts in order to better dive.



Ilya:

Unfortunately, this does not always work, but there are a lot of skills with coaches and a trainer. Of course, a huge number of business trainers push any trash, but this can be determined by the pool of recommendations. However, we did not learn to drive without an instructor.



I easily pay coaches. This money pays off in a week. Many products do not spend especially money on their education, and I do not understand this. At one time I invested in education, courses of more than a million rubles (and then it was other money).



Michael:

Our issue with pumping is solved simply: we take already pumped ones. A more complex topic is the work of a product manager. This is a very difficult profession in Russia, people in short supply. A good product manager should have a huge set of different skills and knowledge, initially love to develop. At some point, we shifted the problem of pumping products to the products themselves. We announced that one of the core values ​​of the company is initiative. At the interview, we announce that we are bad micro-managers, and people have nothing left to do but grow. We allow mistakes and learn from mistakes. And if the person is not micro-managed, if the person has the opportunity to take the initiative, they begin to say: “And there is a conference ... and there is a mitap ... I want to go.” In addition, we have theoretical support, a library. We advertise literature.



Of course, when you are faced with a practical task, you select the right conference and the right book. It is better when the need for growth comes from a specific task.



And in conclusion



We asked experts to share useful links and put them in one place. All information can be obtained from our bot on Facebook or in the Telegram channel .



All Articles