Developers vs. Business

My name is Dmitry Volkov. During my work as a product manager, I have accumulated a lot of stories about victories and failures, how to build communication between development and business, and what cannot be done in any way. Today I will tell two such stories.

I made some of the packs before switching to Yandex.Money. Today I will tell you how in a Siberian company we lost a strong PM due to mutual misunderstandings about what business really needs. The second story will be about how important it is to explain to the team that the product is needed by the market, and how speed, efficiency and coordinated work of all participants of the process come with it. And a little more about how such things work in Yandex.Money.
')

From the editor: this text is the result of Dmitry Volkov’s report at the Piamnaya meeting on February 28, 2019. The opinion of the editorial board on some issues may not coincide with the opinion of the author.

A couple of years ago, I changed my small business to work in a large Siberian enterprise, where I built a service for money transfer online. At that moment I worked with five teams, each of them had its own project manager, and this helped me a lot, because then it was quite difficult for me to communicate with all these introverts brothers. One of the teams was recently assembled and a PM was appointed there with a very strong background. Prior to that, she worked for several years as an analyst in a large bank, and it was difficult for a financial product to find someone more suitable.

I must say that this PM really was a faceted diamond - firm in its decisions and judgments and suited us a little more than completely. At that moment, it seemed to us that we lived according to Agile, so we constantly arranged for planning, grooming, retrospectives, and at almost every meeting the PM pressed with authority, with its own judgment and tried to dominate the team and the products.

She questioned everything - that this feature can be implemented in the architecture of our product, challenged the team's assessment and doubted the adequacy of other products. From time to time such disagreement reached the sabotage of the company's work. How did this manifest itself?

Once we conducted corridor tests, talked to a focus group and suddenly realized that the ability to add a passport issue date is not the most obvious thing for users. We asked the team to cut a bundle with a standard calendar in Android and implement a feature using a simple drum to select numbers, dates and months of the year.

But PM considered our idea absurd. She did not agree that the nonsense that we now offer is generally worth doing. At that moment, I realized that we are not able to interact - it is unclear what we are doing, why and how the interests of clients are taken into account.

However, the problem came to light pretty quickly. The whole thing was in an extremely simple, easy and relaxed position of the business: "I said - it is necessary, so do it." And this caused the internal conflict in the project in the decision to make some feature that we offer.

In business, such a formulation has developed historically. I understand that from the point of view of the product it is not true, but the growth of a large company by 3,500 people was tied to plans, quarterly projects and financial indicators. Therefore, everything related to money, caused one reaction: "We must do." And each time when we were asked the question: “Why do we implement this feature?”, Our answer with my colleague was the same: “Just because it is necessary, because for the money”. Our whole business was for money. Sending money transfers is about money. Everything depended on money - our salaries, bonuses and buns on coffee points.

At some point, everyone quarreled with everyone. Testers quarreled with developers, testers quarreled with admins, admins quarreled with us, because something didn't work for them, we hit them, but it didn't work again, we hit them again. Created complete bedlam. It was not clear what to do, and to resolve the conflict, we had to involve a team of HR and technical director of the company. After some time, we decided that the team should be dismissed.

I was damn ashamed, but the decision was made - we dismissed the team, distributed colleagues to the remaining teams. The project was offered to switch to another product that was not related to remittances, so as not to overlap more with such good fellows like me. She, unfortunately, took this situation very close to her heart and quit that very day.

So because of poorly built communications, and by and large due to my mistakes, we lost a fairly strong player in our team who could be of great benefit to the company, but could not because it was excluded from our ranks. Since then, I have not forgotten that focusing on goals can lead to the wildest pack and ruin a team. And if this situation develops again, then I will be more prepared to resolve such a conflict.

About communications and relationships

Another case, about which I want to tell, is also about communications and relationships, but about higher relationships, rather even about love.

As soon as a clear picture of what is happening in the team develops in my head, this means that I am missing something. And in order not to commit fakapes like the previous one anymore, I just have to communicate with the whole team, with each one individually, and convey to everyone the business values ​​that we pursue, convey them as carefully as we do to our clients. .

We had ten teams from different cities, and I tried to participate in almost all the activities that were associated with them. I attended all meetings and stand-ups and talked about how the implementation of a particular feature affected the company's profitability. I told people about numbers, graphs, changes in terms of growth or decline in the number of users, showed the results of analytical reports. I also talked about the packs - how the introduction of new functions did not bring the expected result. It was important to openly admit business mistakes in setting priorities, which was also important for the team to start trusting me and the second manager who was involved in this product.

Each team was involved in the process of discussing product features based on impact, value and importance for the client and the company. At the same time, we almost completely revised the process of setting the problem in backlog, and now each feature was recorded in the backlog based on four questions: why, for whom, how and what . The usual impacts that are described in the book of Gojko Ajic .

This made it possible to involve the participants in all the processes that are taking place, and all the teams began to take a closer look at what they saw and our requirements.

But not only we changed. For the teams, it has now become absolutely wrong to keep silent either to come to us and say that our ideas or we suck, so we will not do it. There is a need to explain why we should not do some feature or why we want to do something else. In addition, the teams were offered not only to write code, but also to start using this product on their own.

Therefore, we conducted an experiment - each developer had to leave the cozy office, walk to the bank, go through all the circles of hell and sadness, finally make a money transfer, but understand what our users feel at each stage.

I must say that we worked with a complex audience. Then it was labor migrants, people from Central Asia, which very much left its imprint on user scenarios. The direct participation of the team in the processes that the user goes through, helped to understand that we lack the display of user personalities and the creation of Customer Journey Map, and we did it all.

And then they were surprised when the teams started coming with a lot of new ideas and suggestions. They wanted to talk about how uncomfortable they were at some point or, on the contrary, how well the notifications were made that the money transfer was successfully received, and so on. They carried a lot of ideas for us and each time improved our product themselves.

Therefore, if you understand that the product manager you work with every day is from the silent people, from those who don’t like to talk about the business that you do with him, then take his hand and lead him to a dark room. Tell the whole team there how the dissemination of information will help each of you to be fully involved in the development process.

Tell him that it is necessary not only to cut the features that he wants, that it is necessary to refine and legacy the code, to correct the old fragments of crutches, because sometimes the correction and such tasks open up their threads to us completely. Speak openly with him and the team about what is happening with your product. Ask him to come to each stand-up of your team and each time talk about what was achieved in the previous day. Let him show the numbers from analytical reports, the results of focus groups and so on.

This will definitely help him to see the problematics more widely, because your colleagues are probably ready to share their opinions with him, but now they do not trust him.

In general, developers do not like to say something about themselves or about a product, except for various strange words that I do not understand very well and have not learned all this time, about the code and a lot more. Each developer wants to make a high-quality product and share their opinions, but many fear that they will not be heard. If you and your product are open with the team (you are with the product), then people will tell you everything in spirit, and this will also affect the development of your project.

The Yandex.Money teams also work like this. A tight bundle of project and product allows us to develop much faster than before - we regularly clean the backlog, removing obsolete tasks that we may have, grooming, sometimes evaluating our tasks in T-shirts and storypoints in order to facilitate time and speed up processes on planning. We communicate with our team and talk about how the user behaves at each of the stages of CJM, what happens in the reports with numbers and metrics.

In conclusion, I can say that if your product does not share what is happening on the market or in your product, then it's time to ask him to do it. As soon as you tell the team what you are doing and why, the involvement of all the participants greatly increases. Tested in practice.

---

A surprise for those who read it - in this post, a promo code is hidden for a nice bonus from Yandex.Money. It will be received by the one who first finds and activates .

UPD 10:20 The first promo code was between the lines before the kata. It was activated in 17 minutes.

And if you do not have time, then do not worry - in the following posts there will also be promotional codes. Subscribe to our blog to overtake everyone the next time.

Text prepared by:
The author - Dmitry Volkov.
Editors - Evgeny Shklyar, Denis Vonsarovsky.