How can you be Engineering’s Favorite PM

Published in

Product Coalition

4 min readJun 19, 2019

Being a software engineer in my past life, I always wished that I had more context on why I was building something. This information doesn't easily trickle down into core developer team, it is usually the technical team lead explaining what we need to build by drawing a solution and all the components we need to build. Even though the Product Manager role existed at that time, PMs used to be very closely knit with the business managers and less with the development team. Now that I wear the product management shoes, I want to make sure that I am listening to my engineering teams wants/hates and how I can help them be successful.

Go to meetings unprepared, without clear objectives/end goals or at least identify action items at the end of the meeting.
Don’t drive the conversation or stop someone if they are going off track in meetings.
As a newly joined PM try to drive some projects without syncing with the engineers ahead, caused confusion within both internal/external teams.
As a Junior PM, you didn’t know how to fight for ownership and left engineers no space to argue back.
Never invite the whole dev team to a meeting, failing to identify the correct person who can give you the right context and technical expertise.
Instead of saying “I should have included you…”, “I could have invited you to that meeting”, do it!
Not giving engineers context of the full problem, and which customers/users it affects.

Include them in the Product Roadmap planning

As a Product Manager, you are responsible to do market research, competitor analysis, customer requests and distill the right problems to be solving to align with the company’s goals.
Even though the Product Managers own the roadmap and planning, to be successful and get an accurate timeline. Its key to include or at least get buy-in from the dev team leads on the effort taken in terms of T-shirt sizing (S, M, L) and identify all the cross-team dependencies. Even when you are planning the 2–3-year roadmap.

Never dictate solutions

Always start with the market/user problem, give them as much explanation as possible.
Engineers appreciate having the context of the problem before solving for the solution.
Do not go to the meeting with preconceived solutions and list them out for them to pick one.
Give them time to digest and get back to you with proposals.
Discuss the benefits and how this would align with your company goals.
Always let them add some buffer time to each feature in case some edge cases come up during development.

Have frequent check-ins

Keep them updated on the user/customer feedback.
Publish a team dashboard with analytics on your product features.
Keep the team aware of the success/fail metrics, so that they understand why a feature failed and it's not their fault.
Do constant 1–1s to keep maintain the relationship and understand how they are feeling.
Don't just hand off the feature to be delivered and expect it to be done. Be there all the way and guide them to achieve it.

Celebrate the wins and failures

Give the team full credit on the features that exceeded expectations/ KPIs.
Let the engineer’s present during the Demo’s days and company town halls, it motivates them.
Idea Funerals, this sends a very strong and public message to all employees that failing is OK and actually welcomed. Make sure you document the lessons learned and discuss this during sprint Retro’s so that everyone understands why this happened and engineers do not get demotivated.

Actively Kill Ideas

Deciding what not to do is as important as deciding what to do. so that we don’t end up with a lengthy roadmap with 100s of features.
Focusing on fewer things allows developers to do them well, and is a critical success factor.
Having developers time blocked off for innovation projects is also important.
Constantly evaluating the problems on the prioritized list if they are still valid before even business or other stakeholders question if the team is really adding value.

If you all have any other ideas and processes you follow at your organization, I’d love to chat.

Connect with me on LinkedIn.