When it comes to creating a valuable product, there is no way to avoid cross-functional team interactions.
The product team works with a team of engineers, they work with designers, and the chain continues and gets more complex the deeper we get into the interpersonal interplay within each team… A legitimate question arises here: how to organize the interaction between each department so both process and result are successful?
I am Mikhail Gordeev – currently a Technical Product Owner at CloudMTS, a company under the auspices of MTS developing cloud solutions for the creation and development of digital products. Here, I have led a cross-functional team to develop and implement cutting-edge solutions.
Prior to that, I have been training my skills as a software developer at Ozon (an e-commerce company) and a number of other companies and institutions. It encompasses over 12 years of my experience.
In this article, I will be discussing how to bridge the gap between engineering and product teams.
Having been on both sides at various stages of my career, I have accumulated a wealth of experience regarding the reconciliation of both parties interests. This guide leans more towards a philosophical approach, rather than a specific methodology.
Agile also adopts a similar stance, and thanks to this approach, numerous companies have achieved peak effectiveness and productivity without diminishing each team's enthusiasm to work towards the shared goal of value creation.
To base my advice on real experience, it is worth mentioning that the crucial part of being a product owner means that one has to oversee not only whether the product matches the needs of customers and users, but also regulate the way the work is built within the teams.
However, it is sometimes hard to tune in and streamline the process as there appear to be completely different mindsets between the engineering team and the product team.
And it’s no wonder: the product side is a business perspective, whether the engineering side is all about technicalities.
The product team’s hot topics include a clear understanding of what is the problem the end product is designed to solve, what is the socio-economic context for that, and what is exactly the user of the product wants to see it as.
In their turn, the engineering team is usually immersed in solving the problem of building the most suitable and efficient technology architecture that would be delivered as high-performing and compliant as possible.
The common ground here is that one cannot work without the other and that there is still a shared goal — the product.
So, let us go deeper into possible reasons for misunderstanding between the teams.
The universal thing among the teams who have differing focuses is not clearly knowing what is the other team doing and what are their responsibilities. The first wise step here is to gather answers to simple questions from both sides.
For the engineering team, it would be “What are the main things the product owner is in charge of?” or “What does the role of a marketing manager?”
Likewise, for the products, it would be “What do developers usually do within their competency?” or “What are the responsibilities of engineers besides taking care of the results of technology audits?”
From this perspective, there are much more instances when the engineers are not involved in the overall product context.
Working with a technical part, they usually are not aware of the meanings put in the product on the “product” side, and no one should underestimate the possible limitations of such an overlook.
Cooperation is inevitably the best way to solve this issue. It helps make sure the work that needs to be carried out is not missed if we know what each team's responsibilities are.
The discussions give teams insight into what they're going to need from each other, anticipating dependencies and the needed management.
Besides that, it allows for avoiding reworking: the effectiveness grows when nobody tries to do the work they are not supposed to do, do the work of others, or even worse — start shifting responsibilities.
Moreover, making sure every participant knows and understands the common goal is essential, so there are plenty of ways of agreeing on how to achieve it.
Both within each team and against the general background knowing how the mechanism works gives room for new approaches to solving the problem, and vice versa.
Multiple perspectives during iterations empower future innovations. Here, the difference between focuses and work approach paradigms is definitely an advantage: discussion and sometimes conflicts are fruitful for further development and opening new aspects.
To put it shortly, a collaborative approach to product development means making sure that members of each team are embroiled in each stage of the process, taking leading positions at various stages from ideation to launch.
Aside from shared goals and team bonding, it is crucial to be supportive and understanding toward yourself and each participant in the process of product creation. Tolerance of individual differences and learning how to cooperate effectively is an essential part of cognitive empathy.
The myths that if everyone does their job without regard to others, the mechanism will work without interruption have long sunk into oblivion.
The experience of recent years, both in established tech giants and startups, shows that the ability to listen to others and to try to take notice of their ideas and concerns about your overall process increases the bond between teammates which is necessary to maintain trust and motivation to work together.
As mentioned in the beginning, the first step to understanding how to close the gap between engineers and products is to try setting a moral system that allows working in an atmosphere of trust.
If there are teams full of energy to work, but they have no idea of how to tune it in, failure is highly likely.
But when the energy meets the clear cooperation and interaction between all chain links, success is inevitable.