"This isn't what we asked for."
Five words that strike dread into every engineering team. And here's the uncomfortable truth: usually, it's the PM's fault.
Not always. But usually.
Let me paint you a picture of what happens in most organizations:
Product managers spend weeks gathering requirements, conducting user interviews, and crafting the perfect specification document. They hand it off to engineering with pride, confident they've thought of everything. Then engineering builds exactly what was specified—and it's wrong. The PM blames engineering for "not understanding the vision." Engineering blames the PM for "changing requirements."
Sound familiar? Here's what's actually happening: PMs are making technical decisions without technical input, then calling the inevitable mess a "collaboration problem."
The Real Root Cause
Yes, handoffs are broken. But let's be honest about why they're broken: most product managers treat engineering as an execution function rather than a strategic partner.
The specification document isn't a collaboration artifact—it's a power move. It establishes that product "figured it out" and engineering's job is to implement. When that power dynamic exists, failure is inevitable.
Here's the power dynamic in practice:
What PMs Think Happens:
Research → Perfect Spec → Engineering Executes → Success
What Actually Happens:
PM makes assumptions → Spec has hidden dependencies →
Engineering discovers problems → "Why didn't you speak up earlier?" →
Blame game → Technical debt
What SHOULD Happen:
Problem identified → Eng + Product explore together →
Constraints inform solutions → Spec emerges from collaboration
The Lunch That Changed Everything
The best product-engineering partnership I ever witnessed started with an engineering lead who refused to accept specs.
Not "pushed back on specs." Refused them entirely. He told the PM: "Don't tell me what to build. Tell me what problem you're solving, and let's figure it out together."
The PM was furious initially. "That's my job," she said. "Finding the solution is what I was hired for."
But here's what happened when they worked together: the first three solutions the PM had been about to spec were all wrong. The engineer understood technical constraints that made each one either impossible or unnecessarily complex. Together, they found an approach that was simpler, faster to build, and more effective.
The shift wasn't just tactical—it was philosophical. The PM stopped asking "How fast can you build X?" and started asking "What could we build to solve Y?"
What Real Partnership Looks Like
I recently chatted with a startup where the engineering lead joined every user interview. Not just the technical ones—all of them.
Most PMs would see this as an intrusion. "That's my domain," they'd think. But this PM understood something crucial: engineers who hear user pain firsthand make better technical decisions than engineers who read about it in a doc.
The payoff was immediate. The PM was about to spec a complex reporting dashboard based on user requests for "better analytics." But the engineer had heard what users actually said—and it wasn't about dashboards. They wanted three specific metrics delivered reliably. He suggested an automated email with those three numbers, built in two days instead of two months.
The PM who would've spent weeks speccing the wrong thing instead shipped the right thing in a week. That's not collaboration—that's competitive advantage.
Stop Playing Defense
Most eng-product "collaboration" is actually conflict avoidance. PMs don't want engineers second-guessing their specs. Engineers don't want to "get involved in the politics." So both sides stay in their lanes, and the product suffers.
Real partnership requires uncomfortable honesty:
Engineers must challenge specs. Not to block or complain, but to genuinely understand: "What problem does this solve? What if we approached it differently?" PMs who get defensive about this are the problem.
PMs must admit uncertainty. The spec isn't a finished document—it's a hypothesis. Treat it like one. When engineers raise concerns, don't defend. Explore.
Both sides must kill their darlings. That feature you've been championing for months? If the other side has genuine concerns, maybe it's wrong. The goal is building something good, not winning internal debates.
How to Know It's Working
Forget the kumbaya metrics like "team satisfaction scores." Here's what actual partnership looks like:
Engineers say no to PMs—and PMs thank them for it. If engineers are always agreeable, they're not being honest. If PMs react defensively to pushback, the power dynamic is still broken.
Specs get shorter, not longer. When engineers are in the room early, you don't need to document every edge case. The team understands the problem together.
Features ship differently than planned—and nobody's upset. The best indicator of true collaboration is when the final product looks different from the original spec because someone had a better idea mid-stream.
PMs brag about their engineers, not their ideas. When a PM's proudest moment is "my engineer figured out a way to do this 10x faster," you've arrived.
The Uncomfortable Truth
Most eng-product dysfunction isn't a process problem. It's a respect problem.
PMs who don't value technical input will never collaborate authentically. Engineers who treat product work as "not my job" will never contribute strategically. No process fixes that. No framework overcomes it.
Real change requires PMs who genuinely believe engineers should shape product direction—not just implement it. It requires engineers who care about user outcomes, not just clean code.
If you don't have that mutual respect, fix that first. Everything else is theater.
The wall between engineering and product isn't real. We built it by treating each other as functions instead of partners. Tear it down—or keep building products that miss the mark.