One builds castles in the sky.
The other worries if the foundation has continuous integration.
One dreams of dragons.
The other estimates customer impact.
Welcome to the greatest saga in tech: Product Manager and Engineering Manager trying to build something together without burning down the roadmap.
Over the past 2 quarters, I’ve been lucky to work with Gur Shafriri — my PM, my co-conspirator, my partner-in-shipping. And now, as Gur is away due to a beautiful family milestone (mazal tov, king!), I’m realizing just how much I relied on him.
This is a story about trust, chaos, and collaboration. About how Product and Engineering can stop playing PvP and finally team up for co-op mode. About how we built a high-velocity, low-politics, joyful working relationship — and how it made our team better.
TL;DR: It’s not a Horde VS Alliance scenario, even Thrall figured that out.
The War of Misalignment
Before we teamed up, like many others, I’d experienced the classic EM–PM dysfunction:
- Product throws a spec over the wall
- Engineering throws estimates back like flaming arrows
- Roadmaps feel like royal decrees — unchangeable, disconnected
- Engineers feel like feature factories
- PMs feel like project managers, not problem solvers
- Feelings of Suspect and Suspect instead of even Suspect and Respect
It’s not malicious. It’s just the result of misaligned incentives, different success metrics, and two teams speaking different dialects of the same language.
The Treaty of Small Experiments
We didn’t fix things with a grand re-org or a manifesto. We started small — with lightweight experiments that invited more trust and less ceremony.
🧪 Experiment: Kill the fixed roadmap
🎯 Hypothesis: Empower engineers to influence direction
✅ Result: More buy-in, less thrash
🧪 Experiment: Co-own sprint goals
🎯 Hypothesis: Align output with outcomes
✅ Result: Better discussions, fewer surprises
🧪 Experiment: Async feedback channels
🎯 Hypothesis: Reduce meeting load and increase clarity
💥 Result: Overused at first — we had to recalibrate
🧪 Experiment: Prefer creating building blocks
🎯 Hypothesis: Do go for all or nothing solutions, re-iterate over and over, create the foundation
💥 Result: As we went deeper into the iterations, solutions felt “easier” and more leaning on previous efforts
We learned to treat process itself like a product — always in beta, always open to iteration.
Dual Ownership, Shared Victory
We found our groove in an unexpected place: the space between our roles. Gur didn’t just prioritize — he championed problems worth solving. I didn’t just lead execution — I helped shape the strategy.
It looked like:
- Roadmaps built with engineers, not for them
- Technical constraints informing product trade-offs
- Product participating in architectural debates
- Shared rituals — like team demos and blameless reviews — co-led by both of us
- Having fun together - PM taking part in code catas, the entire team doing a “Port Fantasy” product session
In the best moments, it stopped being “PM vs. EM” and became “What are we building together, and why?”
Knowing When to Lead — and When to Lift
One of the quiet superpowers in our partnership was how deeply we understood each other’s responsibilities — not to blur them, but to support them.
We each owned our craft: I led engineering, Gur led product. But we were always in sync, always close enough to cover for each other when needed. Whether it was a vacation or a surprise absence, we could step in and keep things moving — without scrambling or playing broken telephone with the team.
We weren’t just aligned — we were interchangeable by design. Not because we did the same things, but because we invested the time to understand the why behind each other’s choices.
The Quiet When One Voice Is Missing
Right now, Gur is away — for the happiest of reasons. But his absence has been loud.
Every roadmap clarification, every alignment tug-of-war, every murky decision suddenly feels heavier. Because I’m missing that other half of the equation — the one who challenges, supports, reframes, and amplifies.
The relationship between EM and PM isn’t just about syncing calendars and tracking progress. It’s about having a thought partner in the trenches. Someone who sees blind spots you missed. Who catches your over-engineered ideas with a smile and a “…but do we really need that now?”
His absence made the value of our collaboration louder than any success metric ever could.
What We Learned (So Far)
- Trust is the fastest path to alignment
- Shared ownership beats divided responsibilities
- Process is not a religion — it’s a sandbox
- A good EM–PM duo can make or break a team’s culture
- The F in SPOF is Real, always strive to share knowledge and tasks across your team
- FUN FUN FUN, Have lunches, share bad jokes
Three Rituals Worth Trying
- Co-author sprint goals instead of reviewing them
- Hold roadmap reviews where everyone can suggest edits
- Regular EM–PM 1:1s with zero agenda, just gut checks
The Real Endgame
We didn’t win the Game of Roadmaps. We just stopped playing it like it was zero-sum.
We built something better: a partnership rooted in honesty, laughter, feedback, and mutual care for the team. One that made us — and our people — more effective, more resilient, and more excited to build.
We weren’t just aligned — we were interchangeable. Not because we mirrored each other’s skills, but because we both invested in understanding the why behind the what.
We both cared about our team — deeply. But we also cared about the whole org.
Together, we pushed initiatives that reached far beyond our squad: cross-team tooling efforts, onboarding flows, dev experience improvements, process changes. Sometimes I’d lead the charge, sometimes Gur would. But the energy was always there — the shared drive to level up the system around us, not just the sprint in front of us.
Shining the Spotlight, Not Just the Ship
We made it a habit to shine a light on the people doing the building. In our weekly demos to all of R&D, we showcased not just features — but the people and the stories behind them. We didn’t just say “it shipped” — we explained why it mattered.
We also used data — from deployment frequency to bug volume, customer usage to cycle time — to steer our decisions over time. Not to pressure the team, but to reveal patterns and opportunities. Numbers weren’t the truth — but they started conversations that led us to truth.
And when something went sideways? We talked about that, too. Openly, with the team, without shame. We made “what could we have done better?” a standard slide, not a post-mortem obligation.
These rituals built pride, built trust — and most importantly, built momentum.
Conclusions:
EM <3 | TEAM | Ɛ> PM
(It’s not a roadmap. It’s a co-op mode.)
And if you’re an EM or PM reading this, wondering if such a dynamic is possible — it is. Start small. Share context. Invite feedback. Let go of being right.
You might just find your other half in the chaos.