I’ve never much liked the word “going along.” It sounds like two groups each finishing their own tasks and then checking in at the seams—yet the real gap between product and engineering usually shows up exactly at those seams.
I’ve worked in engineering and collaborated with product teams for a long time. My sense is this: whether product and engineering work well together usually isn’t about how much process there is, but whether both sides believe the other is solving the same problem as them. Collaboration only has a foundation when information flows both ways, difficulties are raised early, and disagreements aren’t immediately read as opposition; process merely locks that trust into place.
Bad collaboration is the opposite: treating your collaborator as an opponent, competing for resources through information asymmetry, and replacing discussion of the facts with labels, framing, or name-calling. It might let one side win once in the short term, but over the long term it only makes everyone start hiding risks and protecting themselves. Once collaboration turns into that, no perfect process chart can save it.
Don’t Make Private Promises When There’s Conflict
When goals, timelines, and resources conflict, the most dangerous move is for one side to say yes just to get past the moment, then pass the cost on to the people doing the work. Engineering has seen plenty of examples: product tells the business “no problem,” then turns around and dumps the compressed timeline on the team; the team, for the sake of a show of going along, reluctantly accepts a schedule it knows it can’t meet.
A better approach is to escalate and align: bring the facts, options, risks, and the resources you need to someone with higher decision authority and decide together.
Escalating isn’t passing the buck—the premise is that your own information channels stay consistent: make sure the people directly above and below you all know the real situation, so different levels don’t end up holding different versions of the promise. When necessary, bring in more resources, more context, and higher authority so that decision and accountability match.
Turn “Must Ship Today” into a Choice
Once, as an event was about to start, the business wanted to add an entry point that same day, and engineering found it would touch a shared dependency and couldn’t be fully verified. The easiest way out would have been for one side to give in privately—engineering gritting its teeth and shipping, or the business outwardly agreeing while quietly resenting it.
That time neither side made a private promise. Instead, together they brought the benefits, the risks, the smallest version completable that day, and the timeline for the full version up to the decision maker. In the end they first shipped a simplified entry point that didn’t touch the shared dependency, and agreed on a follow-up version. Nobody got everything they originally wanted, but nobody used information asymmetry to shift the cost onto the other side either—and that’s far more reliable than the surface agreement you get from “going along.”
Trust Doesn’t Mean Never Disagreeing
Trust doesn’t mean never disagreeing—it means that when disagreement appears, both sides are still willing to share information and bear the outcome together. I have a simple test for whether a product–engineering relationship is healthy: when disagreement happens, are the two sides discussing approaches, facts, and costs—or guessing at each other’s motives? The former means you’re standing together; the latter means you’ve already moved to opposite sides.
You can only truly discuss approaches once you first treat the other person as someone on your side. That sounds like a matter of attitude, but in practice it’s a matter of information mechanisms: share the facts, make costs transparent, and hand decision rights to the person who should own them. Trust grows out of those mechanisms—it isn’t produced by meetings.