skip to content

Search

The PM-Engineering Relationship Most Teams Get Wrong

Less than one minute read Updated:

The adversarial dynamic between product and engineering is a design failure, misaligned incentives and thin shared context, not a personality problem, and the fix is partnership with joint ownership of outcomes.

# product-management
# strategy
# leadership
# engineering
# collaboration
Not in series

A ticket cannot carry the reason a bet is worth making. It can only carry what to build.

At Dell, I shipped supply-chain platforms as an engineer before I ever wrote a product requirement. At InMobi, I now own the system of record under a demand-side platform and an exchange that measure 200 million-plus devices’ worth of ad events every day, working inside one pod of engineers, APMs and designers, not two queues that hand work across a table. Those two vantage points taught me the same lesson from opposite sides: when product and engineering fight, the fight is rarely about people.

Most teams call the fight a communication problem and book another alignment workshop. It is a structural problem, incentives, a handoff, and thin shared context, wearing a human face. Fix the structure and the relationship changes. Blame the people and the next hire repeats the same fight within a quarter.

So that’s today’s post.

Today’s Post

Why the PM-engineering fight is a design failure, in six sections.

  • Why the fight is structural, not personal
  • The ticket writer and the order taker, and what partnership replaces them with
  • Why a handoff is a choice, not a law of nature
  • How two reasonable scorecards produce one fight
  • What respect and partnership look like on an ordinary Tuesday
  • What leadership has to change for any of this to survive contact with a deadline

1. The fight is structural, not personal

Negotiation assumes two sides and a finite pie. Give a team that mental model and every planning meeting becomes scope against time, quality against speed.

Some tradeoffs are real. The adversarial framing is still optional.

The pattern shows up when product owns “what,” engineering owns “how,” and neither owns whether the thing worked. Product wins by shipping the list. Engineering wins by defending the estimate. The customer becomes an abstraction nobody in the room is accountable to.

Partnership replaces two separate wins with one shared bet. At InMobi, finance signs the month-end revenue close, and that close is the joint scorecard: the reconciliation work that took it from 5 days to 12 hours belongs to the platform team and to me, together, on one number. Nobody on that team gets to claim a private win if the close still takes 5 days.

2. The ticket writer and the order taker deserve each other

The anti-pattern is familiar because almost every team has lived inside it.

The PM becomes a ticket writer: someone who turns ambiguity into a queue. The engineer becomes an order taker: someone who implements what is written and treats a question about the ticket as friction.

A ticket can list acceptance criteria. It cannot carry the customer segment that matters, the risk the business is willing to take, or the nine other bets that lost to this one. Feed an engineer tickets instead of context and they optimize for the ticket, not the bet.

Order-taking and partnership answer the same four questions differently Same four moments in a build. The difference is who is in the room and who owns what happens after. Grey monospace text names the evidence for each row. ORDER-TAKING PARTNERSHIP PM writes the ticket alone PM and engineer frame the problem together problem framing engineer defends the estimate engineer names the risk, PM names the tradeoff the estimate conversation pushback reads as insubordination pushback reads as information how "no" lands nobody owns whether it worked both own the metric it was built for who answers for the outcome two victories, one failed product one bet, one verdict, shared InMobi: one system of record, one pod of engineers, APMs and designers, not two queues Pixis Prism: a 15-person team that owned the same +25% trial-to-paid number, not a spec and a build lane
Same four moments in a build. Order-taking answers each one alone; partnership answers all four together. PNG ↓

Pixis Prism, the AI co-pilot I led with a 15-person team, is the partnership version of this same shape: engineers sat in the same customer calls I did, because a co-pilot’s UX and its latency budget are the same decision, not two decisions made by two people who never compare notes.

3. A handoff is a choice, not a law of nature

Handoffs feel inevitable once an org has more than one team. They are a design decision, not physics.

A handoff treats the boundary between teams as the place where responsibility transfers. Partnership treats that same boundary as the place where thinking combines. The language gives it away: product “hands off” a spec, engineering “hands back” a build. Each transfer is a chance for meaning to leak.

The wall and the shared context start the same day and end differently Same kickoff, same four moments. One lane keeps the thinking on one side of a line. Grey monospace text is what each side holds at that moment. Scroll slowly, this plays once. kickoff the spec the build the ship THE WALL SHARED CONTEXT PM writes the spec alone, at a desk engineer: not in the room PM and engineer frame the problem together both names on the doc Spec crosses the wall responsibility transfers tickets carry criteria only Constraints mapped before the estimate is asked for the "why" travels with the "how" Engineer hits a gap unstated constraint, no context optimizes for the ticket only Flags a better path early, while it is still cheap judgment, context arrived Ships, surprises both meaning leaked at the handoff blames, skips diagnosis Ships, matches the bet both sides expected this AdRoom: $0 to $10M, 5 months a step both sides can name where responsibility moves where judgment either fires or doesn't the default nobody chose
Same four stages, same kickoff. The wall spends the four stages moving a document; shared context spends them moving understanding. (animates as you scroll to it) PNG ↓

At InMobi, the reconciliation pipeline behind the month-end close never had a moment where product handed engineering a finished spec. The constraints, which fields finance would sign off on, which ones changed weekly, got mapped with engineers in the room before anyone wrote an estimate. That is the entire difference between a pipeline that ships once and one that survives finance changing its mind twice a quarter.

4. Two reasonable scorecards produce one fight

Engineers are commonly measured on output and predictability: velocity, sprint completion, incident count. PMs are commonly measured on shipping and stakeholder satisfaction: roadmap execution, feature launches, executive sign-off.

Each scorecard is defensible on its own. Read together, they cancel out.

Two scorecards, measured separately, produce one fight Each column is a reasonable metric on its own. Read together, they cancel each other out. Grey monospace text names where each figure comes from. PM measured on shipping roadmap execution, stakeholder happiness produces: says yes to everything Engineer measured on output velocity, sprint completion, incident count produces: says no to everything busy conflict, no shared verdict Dell: engineer, then PM shipped supply-chain platforms first read the code before the roadmap InMobi: one pod, one system engineers, APMs and designers, one team 200M+ devices' ad events daily same reporting line, same close Both measured on: did the bet work Pixis Prism, a 15-person team, one shared number +25% trial-to-paid, minus 40% onboarding time, both names on it measured, produces the fight the credibility that makes shared measures possible the fix: one scorecard
Two honest scorecards, read separately, produce a fight neither side asked for. One shared scorecard, on the outcome, ends it. PNG ↓

If a PM is rewarded for saying yes, they say yes. If an engineer is rewarded for saying no, they say no. Fixing the relationship without fixing the scorecards is theater; the org will drag both sides back to their survival behavior within a sprint.

5. What partnership looks like on an ordinary Tuesday

Good partnership is boring, and that is the point.

It looks like a shared definition of success before the build starts, and an explicit list of what the team is deliberately not building this quarter. It looks like a spike run when uncertainty is high, as a cheap way to kill a bad bet before it is expensive to kill.

It looks like pushback framed as options: ship thin by the date, or move the window for depth, with the tradeoff named out loud instead of discovered in week eight. It looks like an engineer who can hear urgency without treating it as an attack, and a PM who can hear “no” without escalating it into a loyalty test.

At Pixis, the AdRoom editor’s brand-guideline enforcement was an engineering call, made with product in the room, that let marketers self-serve without a manual QA gate. Cutting that gate removed 80% of the designer workload behind AdRoom, and the decision only held because engineering and product had already agreed, before the build, on what “safe to self-serve” meant. Respect between the two disciplines showed up as a joint definition, not a vote.

6. What leadership has to change for the loop to survive

A team can build a good partnership on its own for one launch. It does not survive without the organization designed for it.

Executives want predictability and innovation, speed and zero incidents, empowered teams and personal approval on anything visible. Those contradictions never resolve on a slide. They resolve as pressure, pushed downward, where product becomes the mouthpiece for urgency and engineering becomes the shield for feasibility.

When leadership treats a date as a commitment and discovery as optional, product passes the squeeze to engineering. When leadership treats reliability as non-negotiable but funds no time for remediation, engineering passes the squeeze back as process. The PM-engineering relationship becomes the pressure valve for a decision leadership never made out loud.

Four changes fix the design, not the deck: ask “did it work” at every review, alongside “did it ship.” Put an outcome review on the calendar the day a feature ships. Reward the person, PM or engineer, who kills a bet the data condemned. Tolerate “we were wrong” in front of the room.

At Pixis, 15-plus voice-of-customer interviews per launch turned into exactly five roadmap features most quarters. The discipline was declining the other forty, in front of both teams, with the interview notes as the evidence. That only works when a killed idea counts as a win for whoever killed it.

Takeaways

The PM-engineering fight is a design failure Six sections on why the fight is structural, and what replaces it Hoshank Ailani · hoshank.vercel.app 1. Structural, not personal Product owns "what," ships the list Engineering owns "how," defends the number Nobody owns whether it worked InMobi close: 5 days to 12 hours, one shared number, one pod 200M+ devices' ad events daily measured by one system of record 2. Order-taking vs partnership ORDER-TAKING PARTNERSHIP solo ticket, alone framed together estimate defended risk and tradeoff named pushback: insubordination pushback: information no outcome owner shared metric, shared owner Pixis Prism: 15-person team, one shared +25% trial-to-paid number 3. The wall vs shared context 1 Kickoff: alone, or both names on it 2 Spec crosses the wall, or maps constraints 3 Judgment fires only where context arrived 4 Ships surprised, or ships matched to the bet AdRoom: $0 to $10M ARR in 5 months, no spec ever crossed a wall alone 4. Two scorecards, one fight PM: roadmap, stakeholder happiness produces: says yes to everything Engineer: velocity, incident count produces: says no to everything Fix: both measured on did it work Pixis Prism GTM: +25% trial-to-paid, minus 40% onboarding time, one shared metric 5. Partnership on a Tuesday Shared success definition before the build A spike run to kill a bad bet cheaply Pushback framed as named tradeoffs "No" heard as information, not a threat AdRoom: brand rules enforced at generation, agreed with product before the build, cut designer workload 80% 6. Leadership's four changes Ask "did it work" beside "did it ship" Book the outcome review on ship day Reward whoever kills a condemned bet Tolerate "we were wrong" in the room Pixis: 15+ interviews per launch, 5 features kept, 40 declined in the open A ticket cannot carry the reason a bet is worth making. The test to run on the last feature your team argued about: which of the six sections was missing. Full post: hoshank.vercel.app/posts/the-pm-engineering-relationship Takeaways
The whole post on one card. Save it, share it, argue with it. PNG ↓

Six panels, one per section. The callout is the thesis and the test to run on your own team’s next planning meeting.

Final Words

Most teams have smart PMs and strong engineers, and still run the two like opposing counsel. The design, not the people, is what needs the fix: one scorecard, one shared context before commitments harden, and one leadership team willing to reward a killed bet as evidence instead of failure.

Pick the last feature your team argued about, and ask which of the four sections above was actually missing.

Reply and tell me which one it was.

Cheers, Hoshank