There is a disconnect classic in the corporate world, a geological fault that separates those who define the business strategy of those who build the technology solutions. On the one hand, there is talk of ROI, market share and EBITDA. On the other, microservicios, technical debt, and kubernetes. When these two worlds are not understood, the result is always the same: products that nobody wants, projects that exceed the budget and widespread frustration.
As a Business Analyst, Global Product Manager, my career has focused on dwell, and to close that gap. There is a role that is simple; it requires to be a diplomat, a translator and, sometimes, a therapist teams. Here I share how to achieve that vital connection.
1. Become the ‘Rosetta Stone’ of your Organization
The first step is to recognize that we are facing a problem of language. The business often calls for ‘a faster car’ when what they really need is ‘to arrive prior to the meetings.’ Technology, for their part, can become obsessed with the engineering of the engine without understanding the destination of the trip.
Your job is to translate the intention. When you talk to business, avoiding the technical jargon. Don’t talk to them of the complexity of the database, tell them of the risk of loss of critical data to the client. When you talk to the technical team, explain the why behind the what. Not to give them just a list of the requirements; give them the business context and the expected impact on revenue or customer satisfaction.
2. Aligns the Incentives and the Definition of Success
The gap widens when the goals are contradictory. If the computer business is measured by the rate of release of new functionality and the technology team is measured by the stability of the system and the reduction of incidents, the conflict is guaranteed.
As a Product Manager, you must work to create a shared vision of success. What metrics really matter? Defined KPIs of product that combine business results (e.g. conversion rate) with indicators of health technical (e.g. response time of the API). When both sides understand that they are in the same boat and row to the same port, the collaboration flows in a natural way.
3. Encourages Empathy Radical Through Immersion
The documentation does not generate empathy; the shared experience itself. Breaks down the silos physical and mental. Invites you to the key developers to listen to sales calls, or to see evidence of the actual user. There is nothing more revealing for an engineer to see an actual user to fight with the interface that you just programmed.
In the same way, invites the stakeholders of the business to the Sprint Reviews and, better still, the sessions of refining the backlog. Do you understand the complexity of what they ask for. When you see the effort that involves a ‘small request’, your priorities tend to become more realistic.
Conclusion
Close the gap between business and technology is not a project of a single time; it is a discipline of continuous communication, translation and alignment. It requires leaders who feel comfortable in ambiguity, and be able to earn the trust of both sides. At the end of the day, it’s not that the engineers think like executives or vice versa, but rather that both of you understand and respect the value that the other brings to the table.
