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 properly build communication between development and business, and what should never be done. Today I will tell two such stories.

    I made some fakaps even before moving to Yandex.Money. Today I’ll tell you how in one Siberian company we lost a strong PM due to mutual misunderstandings of 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 well-coordinated work of all process participants come with it. And a little more about how such things work in Yandex.Money.

    Editor’s Note: this text is the result of a report by Dmitry Volkov at the Piemnaya rally on February 28, 2019. The editorial opinion 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 online money transfers. At that moment I worked with five teams, each of them had its own project manager, and it helped me a lot, because then it was quite difficult for me to communicate with all these introvert brothers. One of the teams was assembled recently and appointed there PM with a very strong background. Before that, she worked for several years as an analyst in a large bank, and it was difficult to find someone more suitable for a financial product.

    I must say that this PM was indeed a faceted diamond - it was 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, therefore we constantly arranged planning, grooming, retrospectives, and at almost every meeting the PM crushed authority, its 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 assessment of the team and doubted the adequacy of other products. At times, such disagreement reached the sabotage of the company. How did this manifest?

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

    But PM found our idea absurd. She did not agree that the nonsense that we are now offering is generally worth doing. At that moment, I realized that we can’t interact, it is not clear what we are doing, why and how the interests of clients are taken into account.

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


    Businesses have such a formulation 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 have to do it." And every time we were asked the question: “Why are we implementing this feature?”, My colleague and I answered alike: “Just because it is necessary, because for the sake of money.” Our whole business was for the money. Sending money transfers - this 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 administrators, administrators quarreled with us because something didn’t work for us, we ran into them, but it didn’t work again, we ran into again. Complete bedlam was going on. It was not clear what to do, and to resolve the conflict, we had to attract a team of HR and the technical director of the company. After some time, we decided that the team should be dissolved.

    I was damn ashamed, but the decision was made - we disbanded the team, distributed colleagues to the remaining teams. The project was offered to switch to another product, which was not connected with money transfers, so as not to intersect anymore with such fellows, like me. Unfortunately, she took this situation very close to her heart and quit that day.


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

    About communications and relations


    Another case that I want to talk about is also about communication and relationships, but about higher relationships, more likely even about love.

    As soon as a clear picture is formed in my head of what is happening in the team, this means that I am losing sight of something. And in order to no longer make fakaps similar to the previous one, I just have to communicate with the whole team, each individually, and convey to everyone the business values ​​that we pursue, convey them with such thoroughness as we do for 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, about changes in terms of growth or decrease in the number of users, showed the results of analytical reports. I also talked about fakap - how the introduction of new functions did not bring the expected result. It was important to openly acknowledge the mistakes of business 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 the backlog, and now each feature was recorded in the backlog based on four questions: why, for whom, how and what . The usual impacts described in the book by Goiko Adzic .

    This made it possible to involve participants in all ongoing processes, and all teams began to be more attentive to what they saw and to our requirements.

    But not only we were changing. It has become completely wrong for the teams to remain silent or come to us and say that our ideas or we ourselves suck, so we will not do this. There was a need to explain why we should not do some feature or why we want to do something else. In addition, the teams were invited 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 a cozy office, go to the bank, go through all the circles of hell and sadness, eventually make a money transfer, but understand how our users feel at each stage.

    I must say that we worked with a complex audience. Then they were labor migrants, immigrants from Central Asia, which very much left its mark on user scenarios. The direct participation of the team in the processes that the user goes through helped to understand that we are not enough to display user personalities and create a Customer Journey Map, and we did all this.

    And then they were surprised when the teams began to come with many new ideas and suggestions. They wanted to talk about how they were uncomfortable at some point or, conversely, 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 with whom you work daily is from the silent people, from those who do not like to talk about the business that you do with it, then take his hand and lead him into a dark room. Tell him there as a team how the dissemination of information will help each of you to be fully involved in the development process.


    Tell him that it is necessary to saw not only the features that he wants, that it is necessary to modify and legacy code, to correct old fragments of crutches, because sometimes the correction of such tasks opens its flows to us completely. Talk openly with him and the team about what is happening with your product. Ask him to come to every standup of your team and each time tell about what you managed to achieve 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 problem more broadly, because your colleagues are probably ready to share their opinions with him, but now they do not trust him.

    In general, developers do not really like to say anything about themselves or about a product, except for various strange words that I still don’t understand very well and haven’t learned in all this time, about the code and much more. Each developer wants to make a quality product and share their opinion, but many are afraid 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 good faith, and this will also affect the development of your project.


    Teams in Yandex.Money also work like this. The close connection of the project and the product allows us to develop much faster than before - we regularly clean the backlog, removing obsolete tasks that we may have, being rude, sometimes evaluating our tasks in T-shirts and story points in order to facilitate time and speed up the processes planning. We communicate with our team and talk about how the user behaves at each stage 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 exactly you are doing and why, the involvement of all participants increases greatly. Proven in practice.


    Surprise for those who read it - in this post there is a promotional code for a nice bonus from Yandex.Money. He will receive the one who first finds and activates .

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

    And if you do not have time, then do not be discouraged - there will be promotional codes in the next posts too. Subscribe to our blog to get ahead of everyone next time.

    Text prepared by:
    Dmitry Volkov.
    Editors - Eugene Shklyar, Denis Vonsarovsky.

    Also popular now: