The Separation of Powers
In any team building a product, two fundamental questions must be answered: "What should we build?" and "How should we build it?" These questions are owned by different people, and confusing the ownership creates dysfunction. Think of it like a restaurant: the head chef (PM) decides the menu based on what customers want and what will sell, while the kitchen manager (EM) decides how to organize the kitchen, hire cooks, and maintain quality standards. Both roles are essential; neither can succeed without the other.
The Product Manager (PM):
- Owns: The "Why" and the "What."
- Focus: Understanding customer problems, market dynamics, revenue impact, and competitive landscape.
- Output: The Roadmap (what we'll build over the next quarter/year) and the PRD (Product Requirements Document — a detailed description of a specific feature including user stories, acceptance criteria, success metrics, and edge cases).
- Key skill: Saying "no." A PM who says yes to everything produces a roadmap that's impossible to deliver. Every "yes" to one thing is an implicit "no" to something else — a good PM makes those trade-offs explicit.
The Engineering Manager (EM):
- Owns: The "Who" and the "How."
- Focus: Team composition, hiring, career development, technical quality, architecture decisions, and managing technical debt.
- Output: A healthy, productive team and a codebase that can sustain velocity over time.
- Key skill: Shielding the team. An EM who lets every stakeholder request bypass prioritization creates chaos. An EM who never pushes back on unrealistic timelines destroys team morale and quality.
The Negotiation Zone: "The When"
The PM wants features delivered fast because business value decays over time — a feature shipped next month is worth more than the same feature shipped next year. The EM wants features built right because technical debt compounds — shortcuts taken today slow down every feature built tomorrow. This tension is healthy and necessary. The resolution happens through scope negotiation:
- "We can ship the full feature in 8 weeks, or an MVP (Minimum Viable Product) in 3 weeks. Which do you prefer?"
- "We can add this feature, but we need to spend 2 weeks on infrastructure work first, or it will be fragile."
This negotiation is often called the Iron Triangle (also known as the Project Management Triangle): Scope, Time, and Quality. You can fix two, but the third must flex. If the PM fixes scope and time ("I need all these features by March"), quality will suffer. If the EM fixes quality and time, scope must shrink. The Iron Triangle doesn't tell you what to choose — it tells you that pretending you can fix all three simultaneously is a lie.
Scope
/\
/ \
/ \
/ \
/________\
Time Quality
"Fix any two. The third is a consequence."
Where Senior Engineers Fit:
Senior engineers sit at the intersection of PM and EM concerns. They translate PM requirements into technical plans, surface hidden complexity ("this 'simple' feature requires migrating the database schema"), and propose creative alternatives ("instead of building a custom solution, we could integrate with this existing service and ship in half the time"). They also push back on technical decisions made by PMs who don't understand the implementation, and push back on business decisions made by EMs who don't understand the customer. This translation and mediation ability is one of the most valuable skills a senior engineer can develop — and one of the clearest signals that distinguishes a senior from a mid-level engineer.
When asked "How do you handle disagreements with Product about priorities?", avoid answers that position engineering as either subservient ("we just build what they ask") or adversarial ("we push back on everything"). The strong answer: "I make the trade-offs visible. I present options with their costs — 'Option A ships faster but creates tech debt we'll pay for in Q3. Option B takes longer but sets us up for the next three features.' Then the PM can make an informed decision with full context. My job is to ensure they understand the engineering implications, not to override their business judgment."
Key Point: Dysfunction occurs when roles blur. A PM who dictates technical architecture ("just use microservices") or an EM who overrides business prioritization ("we need to refactor first, customers can wait") are both stepping outside their domain. The healthiest teams have clear ownership with structured negotiation at the boundaries — and a shared understanding that both the "what" and the "how" must be excellent for the product to succeed.