Working with Product Managers: Advice from PMs
Discover more from The Pragmatic Engineer
Working with Product Managers: Advice from PMs
Product managers and founders share tips for engineering managers and engineers to work better with them.
As a follow-up to this week’s post, 🔒 Working with Product Managers as an Engineering Manager or Engineer, I asked product managers for a few pieces of advice they’d give engineering managers (EMs) and engineers, to work better with product.
Below is a collection of several of the answers.
Ebi Atawodi was my product counterpart for years at Uber. She is now director of product at Netflix and her advice is this:
You are also “product”. There’s no “waiting for product” or “product said this or that”. Understand that you’re a partner in this setup. You own the product and outcomes just as much as the PM, the designer, and the data folks do.
Care about the business outcomes and the customers. It isn’t just the job of the PM to be customer obsessed and to care about impact. What is the business context? Why are these business and customer problems important? What are the outcomes? What key metrics do our products impact, move, or improve? How are we tracking to those goals? How could we build a more magical experience for customers? All of engineering should be thinking about these questions.
Develop a shared North Star vision. Build the vision together and be excited about it. The storyboards should include engineering North Stars as well. (Note from Gergely: building the shared North Star vision, writing it down and iterating on it, has been some of the best time I spent working with Ebi.)
Make sure hiring, performance, and headcount discussions are collaborative. This also goes for staffing and scope changes. Don’t forget that this is a partnership.
Ross McNairn was my product manager when I worked at Skyscanner, in London. He is now chief product and engineering officer at business travel management platform TravelPerk.
There is no distinction between technical and product roadmaps. It’s a question of how directly and over what time frame something affects a user. If you refer to parts of the roadmap as “engineering only”, this creates a wall. For example, removing tech debt indirectly benefits users as it reduces bugs and increases development speed, so make this product impact clear as well. It’s lazy to draw a straight line between product and engineering as it creates unhelpful silos.
Own the how. Don’t step back and wait for your PM to fill the operational space. Lean in! Run as much of the planning, estimation and project management process you can get your hands on. Partnerships all find their own equilibrium. The more you own the operation of building the feature, the more time your PM will spend on users and analysis. You’ll also be closer to the problem space. If you step off it leaves your engineers with less space to think about the “why”.
Read and engage with the strategy. Even though the PM is ultimately responsible for putting the strategy in writing, you are a critical participant and stakeholder. Challenge your PM and the strategy, and build your own views. The more context you share and the more you are involved in the definition of strategy, the closer your alignment and the better your output.
Juan Pablo, formerly head of product at Albo reiterates the importance of “why”:
He also shares:
“Communicate to make clear the debt: what is tech debt that the product has and how it impacts the team performance or the user experience.
In the past, I used this framework to frame technical debt.
It helped the team easily prioritize technical debt equal to the new product ideas.
Lizzie Matusov, cofounder at Pathlight, makes the same point:
Dipti Desai, formerly product at Uber suggests leveraging your PM:
Shreef, product manager at Ankorstore and formerly at Booking.com talks about investing in each other’s success:
Krishna Nandakumar, product manager at Deliveroo shares three pieces of advice:
Martijn Visser, product manager at Ververica, working on Apache Flink advises how to go about surfacing tech debt:
Kyle Johnson, VP Product at Plate IQ shares a simple way to ensure product and engineering truly understand one another:
Robert Stuttaford, CTO at Cognician emphasizes that transparency in decision-making is critical:
Willem Spruijt was an engineer I worked with at Uber for four years. He is now the cofounder and CTO at Rise Calendar (I’m an investor). He highlights that product has much to balance:
‘Understand that product needs to balance more than just the engineering aspects. Product is often an intersection between business/sales, design, and engineering, all of which it needs to take all into account when prioritizing the direction of travel, or what to build. For example, deprioritizing a migration might not make sense to an engineer at all, because they are not aware of the sales impact when a new feature ships later.’
Finally, Deani Hansen, Engineering Manager at Productboard - previously at Slack for six years - summarizes the product / engineering relationship like this:
