To resolve conflicts, follow Marty Cagan's model: Product Managers are responsible for business outcomes, while engineering teams own the technical implementation. The architect's role is to enable both parties and facilitate the connection, not to override either domain.
Related Insights
A platform's immediate user is the developer. However, to demonstrate true value, you must also understand and solve for the developer's end customer. This "two-hop" thinking is essential for connecting platform work to tangible business outcomes, not just internal technical improvements.
Engineering often defaults to a 'project mindset,' focusing on churning out features and measuring velocity. True alignment with product requires a 'product mindset,' which prioritizes understanding the customer and tracking the value being delivered, not just the output.
To get product management buy-in for technical initiatives like refactoring or scaling, engineering leadership is responsible for translating the work into clear business or customer value. Instead of just stating the technical need, explain how it enables faster feature development or access to a larger customer base.
The 'CEO of the product' metaphor is misleading because product managers lack direct authority. A better analogy is 'the glue.' The PM's role is to connect different functions—engineering, sales, marketing—with strategy, data, and user problems to ensure the team works cohesively towards a shared goal.
Beyond speaking the same language as developers, an engineering background provides three critical PM skills: understanding architectural trade-offs to build trust, applying systems thinking to break down complex problems into achievable parts, and using root-cause analysis to look beyond user symptoms.
In AI development, trace analysis is a point of tension. Product Managers should become fluent enough to ask intelligent questions and participate in debugging. However, they should avoid owning the process or tooling, respecting it as engineering's domain to maintain a healthy division of labor.
A valuable architect enables teams by coaching them through decisions, providing self-serve documentation, and offering multiple solutions. A detrimental architect becomes a gatekeeper, creating a bottleneck where all decisions require their personal approval, stifling team autonomy and speed.
Frame the product manager not as a feature owner, but as the central communication hub. Their primary function is to connect business, stakeholders, engineering, and design, navigating complex relationships and translating needs across disparate groups.
Most conflicts between PMs and architects aren't truly technical. They stem from a lack of three crucial, vulnerability-based conversations: 1) What does success look like for you in your role? 2) What is your biggest fear? 3) How can we disagree productively?
PMs who complain about architect bottlenecks are often the cause. By failing to invite architects into the discovery phase and customer conversations, they prevent proactive collaboration. This forces architects to reactively gatekeep later, rather than co-creating solutions from the start.