The Eng-Product Relationship Isn't a Soft Skill Problem
You can communicate perfectly and still be stuck. The structure underneath is working against you.
When engineering and product aren’t working well together, you get the standard diagnosis. Communication problem. They need to listen better. Collaborate more. Assume positive intent. Leadership coaches get brought in. Workshops happen. Nothing changes.
I’ve learned something after being on the engineering side of this at multiple companies. Communication matters, but it’s not the whole story. You can communicate perfectly and still be stuck, because the structure underneath is working against you.
The incentives are opposed
Product and engineering aren’t just bad at talking to each other. They have opposite jobs.
A VP of Product gets rewarded for ambition. Identify the opportunity. Champion the bet that could change the trajectory of the business. Push the roadmap forward. A product leader who never pushes, who always hedges, doesn’t last.
A VP of Engineering gets rewarded for honesty. Surface the tradeoffs. Keep promises realistic. Make sure the system doesn’t fall apart while everyone’s chasing the next feature. An engineering leader who says yes to everything and never pushes back also doesn’t last.
Every planning cycle plays out the same way. Product brings ambition, engineering brings constraint. Product sees engineering as the obstacle. Engineering sees product as someone who doesn’t understand how any of this works. Both are right, given the jobs they’ve been asked to do.
You give them different jobs and then act surprised when they disagree.
Where the CEO tips the scales
In theory, the CEO balances product and engineering, weighs both sides, and makes the call when they can’t agree.
Most CEOs lean toward product in practice. It’s just more fun. Big ideas are exciting to sit through, technical debt is not. A roadmap presentation about possibilities beats one about hiring gaps and infrastructure needs every time.
At one startup, our CEO was a sales person at heart. The VP of Product wanted to imagine the future, pitch the vision, chase the big bets. That’s exciting at a startup. What’s not exciting is your VP of Engineering saying we need more people, more money, more infrastructure before we can do any of it. The CEO wasn’t choosing favorites. He was just naturally drawn to the conversation that felt like progress.
Over time it became a pattern. Product figured out the CEO was receptive to ambition. I figured out that constraint didn’t move the needle. Roadmaps got committed before engineering had a real voice. Once that dynamic locks in, it’s hard to reverse. Engineering stops being honest because honesty looks like resistance. Product stops listening to constraints because the CEO gave them permission to ignore them.
The product person who wants your job
At another company, I ran into a completely different version of this problem. My product counterpart thought he was technical. He liked to say he could run the engineering team. He wasn’t as technical as he believed, but it was insulting to him if you implied that.
He was constantly frustrated that he didn’t just own engineering outright. Every conversation about scope, timeline, or technical approach felt like a territory dispute. We communicated fine. The problem was structural. He fundamentally disagreed with the idea that engineering should be a separate function with its own judgment.
You can listen actively all day long and it won’t matter if the other person thinks your function shouldn’t exist independently. No amount of communication fixes that.
Sometimes it’s the CEO who accidentally sidelines engineering because product is more fun. Sometimes it’s the product leader who thinks engineering is a department they should absorb. Different dynamics, same outcome: engineering loses its voice, and then six months later everyone’s wondering why the system is falling apart.
The technical investment fight
This is where the real friction lives. How much engineering capacity goes toward things product can point at versus things that keep the system from rotting.
Product wants all of it. Every engineer working on infrastructure is an engineer not building features. Features get demoed. Features get announced. Features hit the metrics product owns. That’s reasonable.
But engineering knows something different. Deferring maintenance means everything gets slower and more fragile. The system gets harder to change. Incidents start spiking. Good engineers start leaving because they can see where this ends.
Both sides are right. There is a real tradeoff. The question is who decides and how.
Without clear rules, it defaults to product. Features are visible. Debt is invisible. Engineering falls behind on what needs doing. Then something breaks that didn’t need to break, and in retrospect everyone agrees the investment would’ve been worth it. But nobody talks about why it never happened.
This is a constant negotiation. I’ve seen it play out at every company I’ve ever worked at. There’s no permanent answer. The ratio shifts depending on where you are in a product cycle, how much debt you’ve accumulated, how stable things are. The important part is that engineering actually has a seat at the table when the ratio gets decided, not just an advisory role.
What actually helps
Answer the structural questions before you need them. Who owns the roadmap? Does engineering input on scope actually change anything, or is it just advisory? When the leaders disagree, who decides? How do you split capacity between features and technical investment?
If you haven’t answered these explicitly, they get decided by whoever has more political capital. That’s how you end up with the dynamic everyone calls a communication problem but is actually a decision-making problem.
Put it in writing. Not workshop values. Actual decision rights that both sides and the CEO sign off on.
And yeah, communicate better too. I’m not saying soft skills don’t matter. They do. But all the active listening in the world won’t fix a structure that’s designed to produce conflict. Fix the structure first, then the communication has something to work with.