Deploying Product Managers and Enterprise Architects side by side can sometimes be a complicated process. There are often tensions between product management and architecture because they’re ostensibly working towards different objectives. Regardless of how great each employee is in their own field, it can sometimes be tricky to navigate a harmonious work flow between the two disciplines.
A product manager’s role includes maximising value and opportunity in the market of product delivery for clients, looking after user centred needs, focusing on user centred design and fixing broken processes. In modern digital ecosystems, an Enterprise Architect is a business discipline converting business outcomes and priority into executable digital roadmaps. Their main role is to produce implementation blueprints prioritised and interlocked with organisational strategy.
Here are some antipatterns you might have seen before:
Product Managers look into the business and customer needs, whereas Enterprise Architects are always looking at what it looks like in the context of deploying technical capability. Enterprise Architects can also spend a lot of time reworking specific architecture models.
On the other hand, Product Managers will typically create three month roadmaps that lead to misalignment with Enterprise Architects, as they look to design for long term strategies and efficiency across the whole ecosystem.
However, in reality, the objectives of the two functions are more similar than you think. The goal is to have product and architecture working together hand-in-glove. Both Product Managers and Enterprise Architects are responsible for tackling ambiguity creatively and assessing how each function should best collaborate.
Here’s 7 steps to creating an entirely collaborative operating model:
1. Product Managers must always take responsibility for both technical and business elements of their products and should always communicate with technical architects at every opportunity.
2. Any restrictions from Enterprise Architects must always be communicated immediately and fed into product priorities and roadmaps by Product Managers.
3. Technical debt is business debt, not Enterprise Architect debt, and should be prioritised by Product Managers valued in such a way it can be assessed against further product releases.
4. Find a way to remove technical/business barriers from both sides. Limiting architects to ‘technical’ conversations removes critical context needed to make complex decisions within architectural strategies.
5. Security, interoperability, observability should no longer be considered non-functional requirements owned by Enterprise Architects; these product features are as important to product quality as functional features.
6. Issues will arise: utilise retrospectives and psychological safety to ensure open and transparent communication between Enterprise Architects and Product Managers.
7. Remember you’re working as a team. Ensure Product Managers have the support of the skills needed throughout the product life cycle, even the best Product Manager cannot be an expert on every topic all of the time.
Adam Cockburn, Head of the Architecture Practice at Axiologik said: “Overall, we are both working together on clients, and we are trying to work for the same outcome. Although sometimes we might be looking at it from a different lens, it was important for us to work out what the crossovers were and create an operating model that suits everyone’s needs. Both disciplines need to work together on a functional and effective architectural roadmap that supports the product goals and objectives.”
Polly Price, Product Manager at Axiologik said: “Here at Axiologik, we have realised that through working together, to have a functioning collaborative operating model, there are certain needs and compromises that are needed to be made from both Product Managers and Enterprise Architects. With this, not only will it be extremely beneficial and create a more efficient way of working for both teams, but it’s also work for our clients and the business.”
