Just between developers, we don't like Product Managers. Too often they are simply a monitor on our progress. However, these roles exist for good reasons and it's unfortunate too many bad PMs exist because they saw a tiktok about big tech and jumping ship into the industry, thanks you weird big tech lifestyle influencers... why do these people exist anyways????
Product Managers have a critical role in the company. They are the bridge between managers, C-suites and us, the little cogs in their money printer. There are a lot of abstractions between what the leaderships wants to do and the product in the end. Your typical MBA graduates doesn't even know what the hell bubble sort is (even Obama knows come on!) so there is a mountain of details to filled in between.
The best PMs I have worked with have some decent technical understanding. One can write SQL queries, which me as a primarily frontend developer can't do well :) ... Another had a QA background, which meant we were getting QAed every step of the way :(
Good PMs do attend meeting with more technical details, to the point that although they sure as hell don't know what you are talking about, they at least see 10 inches beneath the waterline.
All that said, it's important to always remember that PMs inherently speaking suffers a lot of anxiety on how the project is doing because they don't know what the progress is REALLY like and how it can go wrong. We all know how a feature develops. First few days you are flying through 80% of the progress and the sky is blue. Then the next morning you wake up finding a hidden dragon in the abyss and now you are questioning whether you are even the person to do the job! Imagine the surprise, but from someone who can even see less than you and in an hour later have to tell the CEO that the project has to be delayed and the team now don't even know where they stand. Oh my god, I can't even imagine having to speak those words out...
Back to the topic: how do you work with PMs?
1.) First and the most important thing: build trust.
this means you basically you try to be a good little boy at first. Excruciating yes, but remember that they are realistically your superior and even though they technically aren't, they will be speaking to your manager and your manager's managers and all the way up 100000x more often than you ever will. communicating with the entire chain of command is their job! So you at least want PMs, and by proxy everyone in the chain, to know that you are a decent employee at the very least.
Keep in mind they aren't responsible for the technical, just the communication. So they aren't afraid to say "the project is messed up because Joe couldn't..." and crack in your reputation. Speak your name enough times and you will be on first name basis with your CTO and pip will be your last name.
2.) When things don't go well, take ownership.
your project won't be a smooth sailing, it rarely ever does. And no one really expects it to be too! So relax when things go south. Regardless, You will want to be the one that PMs turn to. Remember you are the developer with the closest look into what's going on inside the giant black box machine that YOU maintain. When things go south, immediately let PMs know you are aware and that you will inform them what's wrong, what's the fix, and what's the ETA. If you do this repeatedly, you will become the technical rockstar in their mind and they will learn to lean on you and scrutinize you less!
Of course try your best to not mess up in the first place, bug free la la land is still the world we all want to live in.
3.) communicate!
Because that's the only thing PMs know how to get the job done. To them communicating is everything. This can be done either in person, over slack, or even through Jira updates. One way or another, your relationship with PMs are built entirely on what you say and what you write. Unlike your engineering manager who can look at your code and assess base on the quality of your code, your PMs assess you entirely on the quality of your communication. This may be a hard lesson for many engineers, because we would have never chosen this career path if we like communicating so much. However communication is sadly the best way to build a mutual a long lasting relationship with PMs.
4.) communicate concisely and precisely!
Work on your writing and speaking skills. Start with writing, because writing allows you to edit, read back what was written, and improve upon. Eventually your writing skill level will bleed into your speaking skills. This is important because PMs ain't got no time to listen to you talk about something in 50 words when it can really be said in 5. Remember they don't care about a lot of details, and they want just enough details so that they can go back and not bullshit the leadership. You aren't in high school anymore and HAVE to write a 500 words essay, lose that habit!
One thing I like to do is that I first write the most important details like what's wrong, what's the ETA, what's the one sentence describing the fix. Then I would write a "tech note below" to jog down what's going on in the best level of detail I could provide. This helps you as the person fixing it to document and brain storm, it helps the PMs to take in whatever detail they want to know if any, and it helps your engineering manager to weigh in and vouch for you that what you provided (reason, eta, and fix) is reasonable and the path forward.
5.) when conflicts happen remember: we are striving for the best product possible.
Inevitably conflicts arises and communications appear personal. However, remember that whatever comes out your mouth it should always about how the team can produce the best product and best solutions. Keep that also in mind this is what the product managers are striving for so that you can keep your cool. Feel free to vent about it afterwards with your tech coworkers of course :) I do that very often and that person's name became a verb among friends
6.) Push back reasonably and provide alternatives:
this is really the badge of mastery, which is why this is the last point. You don't want to be JUST a good little pet doing everything they ask. They won't respect you this way in the long term and will step over you like a doormat you are.
When you see a possible alternative solution, speak. PMs are communicators and solution-wannabe, but really they are just the communicators. Sorry not sorry. They don't build the product so they won't know how else the product can be built. Sure they'll do market analysis and compare what other companies do for the same feature and what other standards should be kept in mind, but in the end the creativity CAN also be coming from you as the owner and builder of the feature.
They are often so deep in their own jungle that they can't see the tree in the forest. So don't be afraid to speak, remember, all they want is the best feature to be built, and if you see another way, that's VERY welcomed!
You want to do this occasionally and just often enough so that they know that keeping you in meetings is worthwhile, because you are listening, thinking, and speaking in the meetings. You are a participant and not simply an yes-man.
This also means that when their ask is unreasonable, communicate that too. However, remember that for one push back, also provide one solution. You are the solution provider in the end so you can't just reject. Just rejecting is what your CEO does for a living!
Hopefully this was helpful, feel free to let me know I am full of shits.
Top comments (0)