EM/PM Relationships Aren’t About Luck: 5 Tips for Product/Tech Teams
Introduction
As my probation period at HelloBetter was coming to an end, my team’s Senior Product Manager Tanja Lembcke remarked, “It’s great working with an EM who cares so much about product.”
I could easily have said the same back to her, because it’s just as valuable working with a PM who cares deeply about technology, something at which she truly excels.
Together, we’ve become a strong team. Much of that relationship has developed naturally, but I’ve also noticed a few intentional practices that have helped us along the way. I want to share them here for all the product managers, engineering managers, and whoever else happens to like reading my sporadic blog posts.
In the end, Tanja and I didn’t just “luck out” working together. There are some tried-and-true strategies we both employ to make the most out of our work and get the results we need.
If you prefer LinkedIn, you can view the short-form version of this post as a summary and carousel here.
Tip 1: Purposefully be the intersection of business, team, and product
As a Team Lead or Engineering Manager, it’s important to operate at the intersection of business goals, the engineering team, and product. This means not only using the product but also critiquing it, asking thoughtful questions, and continually returning to the core “Why.”
It is all too easy to sit back and just wait for features to drop in your lap, estimate them, deliver them, and then dust off your hands with a “job well done” attitude that allows you to add a nice dot-point to your CV about value creation.
What is much harder, is to actually focus on quality: that hard-to-measure, hard-to-prove value that is constantly competing with your time.
For EMs, we tend to see the word “quality” and jump to the concept of code quality, or architectural quality, or latency, or memory management. But I want to challenge you to also think about quality in terms of this question:
How much value am I, personally, delivering to our product?
This means challenging assumptions that your PM makes, seeing opportunities from your team’s expertise (we are rarely using the full capabilities of our team members), but also personally taking ownership of quality improvements that sit awkwardly between tech and product.
A key example here is compliance.Most recently, I took on the initiative to deliver what’s called a “UDI-PI” version identifier for our product to improve compliance with ISO 13485. This has provided a great opportunity for me to drive our business forward meaningfully while acting as a ‘translator’ between the different parts of the business.
Compliance is often in the ‘grey zone’ between product and tech, and it has the following added benefits to your career:
- It is mission-critical to product success, especially if it’s part of legislation, auditing, or certification.
- Nobody wants to do it.
In my book You Belong in Tech, I make the argument that junior engineers can get ahead by specialising in the “unloved” parts of engineering (documentation and testing, specifically) to give them the upper hand in a job search or in career development.
Similarly, I would argue that compliance (including security) is the perfect intersection of product, tech, business, and the team for EMs and PMs to form a strong bond and move forward quality metrics in a way that is meaningful to their company.
Tip 2: PMs should insist on clear explanations of value… and EMs should insist that PMs insist on it
As a Product Owner or Product Manager, it’s crucial to require clear explanations of the value behind technical initiatives. Pushing engineers or the EM to walk through exactly what’s happening (and why) helps avoid relying on technical jargon and ensures everything is explained in understandable terms.
To hark back to my work with Tanja: part of what I enjoy is seeing her really comprehend technical explanations that the engineers give. Sometimes they explain things too vaguely, and sometimes far too specifically.
The stereotype of incommunicable engineers lingers on for a reason: as with any technical or scientific profession, developers tend to underestimate the base level of knowledge that a casual, non-technical audience has.
Of course, EMs can take some initiative here and also offer explanations to the PM. That’s all fine and good I guess…
BUT (you knew it was coming!) I think what is more productive is having the PM and the engineer figure it out together, and to encourage the PM to ask directly in group settings.
Not only does this help improve the PMs connection to the rest of the team, but it also means other engineers who might not have understood the explanation the first time have a chance to ‘get it’ the second time around.
Additionally, the engineer also has a chance to receive immediate feedback that their explanation was insufficient for a non-engineer, which is far more powerful than hearing it days or weeks later in a one-on-one.
Tip 3: Build in space for technical initiatives
No tech stack is perfect, and no codebase lasts forever. Packages evolve, browsers and devices change, user needs shift, and business priorities move.
While structured planning is essential, it’s just as important to leave significant space , at least 20 percent , for technical initiatives, even after accounting for bug fixes.
What this means in practical terms is that EMs and PMs need to be on the same page as to the importance of tech initiatives, but also in terms of sprint planning (if you’re working in sprints) or epic planning (if you’re working across quarters, for example).
My general rule of thumb is 70% product initiatives, 20% technical initiatives, and 10% bugs. How this is divided amongst the engineers, the sprints, the quarters, the year, etc. is totally up to you and your team.
Do you disagree or have a different system for creating balance? I’d love to hear about it in the comments!
Tip 4: Keep timing and priorities in constant conversation
Priorities can change rapidly, especially in industries like healthcare and digital therapeutics, where regulatory requirements or market opportunities can shift overnight. Weekly conversations to review what’s coming up, what’s planned, what’s changing, and what needs to be adjusted are vital, not just for personal goals but for aligning with the broader objectives of the company.
Tanja and I catch up every week for half an hour. In a good week with only one leading priority, these meetings can be quite short or quite casual. However, as soon as the team is more full or the initiatives start piling up, we often find we need more time or additional meetings.
This is because we are ruthless on prioritisation.
Furthermore, in standups after we run through any upcoming release topics, triage issues, etc. I will end with “Is anyone unclear on their priorities?”. My QA Engineer and my senior engineers are often working on multiple topics simultaneously, and this one question has saved us many times.
Tip 5: Be upfront about what you don’t know
If you and your EM/PM have the feeling of needing to pretend to know everything with each other, then the partnership isn’t as strong as it could be.
Being willing to reveal gaps and bridge them together leads to healthier collaboration and faster team progress.
For example, if my PM uses an acronym I don’t know, I really have three options before continuing the conversation:
- Google it quickly.
- Ask her.
- Nod and say “Mmm, yeah”.
Too many people choose option 3 because they are lazy, or because their EM/PM uses too many terms they don’t know and they don’t want to interrupt all the time.
The next group chooses option 1 because it allows them to follow the conversation without seeming ignorant.
But I would argue that 100% of people, 100% of the time, should choose option 2: even if it is annoying; even if it is breaking the flow of conversation; and even if other meeting attendees are rolling their eyes.
Why? Let me give a non-exhaustive list:
- You’re probably not the only one confused, so asking helps others in the room to also learn.
- Your EM/PM will learn that they’re not explaining it clearly.
- You don’t lose track of the conversation thread because you’re trying to multitask: the meeting stops and waits for you.
- You might learn more nuance/detail about how it applies to your company/industry by opening up a conversation around it than by just looking up a definition.
- You model vulnerability which will help your EM/PM to do the same in future (hence applying all of the other benefits outlined above to them and you as well): in other words, you establish psychological safety.
Closing Reflections
As you can see, there are some common threads to how I view a productive working relationship between Engineering Managers and Product Managers.
They rotate around:
- Understanding what and why
- Giving space for the code to breathe and grow
- Pushing for clear prioritisation
If you can challenge yourself to take these three things seriously, then the above 5 tips should naturally fall into place.
