Published on 12 February 2020 Tweet
I know that feel bro, cuz I’m also a software engineer. With years of experience, I have met some great Product Managers (PM) and a couple of bad ones. It is difficult to work closely with a bad PM every day, a bad relationship guarantees you feel resentful at your job. That’s why I would like to share a few tips in this article on how to work with PM as a software engineer.
It can be very hard to work with product managers for two reasons:
Therefore, you will need soft skills and communication skills that help you fit into the software development team.
Common Mistake 1: PM don’t understand the technical challenges
It is the worst thing to hear PM say “it’s just a simple button, can’t you finish it in one hour?” Those words imply the work is easy, you are not capable, that’s why it feels so humiliating that he can’t appreciate the complexity of your work.
A button is not simple. It has different states to consider: on hover, on click, on double click submission, on different screen sizes, internationalization of text, accessibility for blind people etc. A search button could fire an API call from front-end to back-end, query a database with millions of records, going through the machine learning algorithm… not to mention authentication and security concerns. Think of Google homepage search button, it’s not “just a button” that can be done in one day.
Engineering is more than just typing code. Programming is art with creativity to build something from scratch, with intelligence to deal with the complexity and with grit to solve technical challenges. At the same time, you need to learn how to communicate to the PM with your best estimation of how hard a task might be. You need empathy to see that the PM has no clue with the limitations and make wrong assumptions on the task complexity. You are the only one who can tell how technically feasible something is and provide an estimate for how difficult it will be to build.
Common Mistake 2: PM is managing the product, and also try to manage you.
It is important to emphasis that just because the PM gives the requirements, doesn’t mean he is the boss. You are not reporting to him. You are not coding monkeys to do everything he told you to do. This is particular true if you are in Asia countries with hierarchical organizational structure, or if you are working as an outsourced vendor dealing with the client in-house PM. It would not be a flat organization that you have enough bargaining power to negotiate.
Following software development methodologies, such as scrum, is a good practice, not just because it protects you from burning out, it also set the PM with the realistic expectations on what could be delivered. Just that PM can say no to end customers in prioritization, you can also say no to change of requirements at the middle of the sprint. A daily change of requirements is not agile, but a receipt for failure product. Inconsistent requirements lead to an inconsistent design with non-reusable code. Ultimately everyone suffers from bugs and technical debts.
You need to avoid being micro-managed with constant interruption by PM, so that you can focus on solving hard problems that requires deep concentration. A context switch via email, slack or long hours meetings can be very frustrating and tough to recover mentally. To make things worse, open office space and co-working space, such as WeWork, is so noisy with many distractions that you can’t focus on work in this crowded marketplace. You need to get control of your time and energy around communication, so that you can focus on getting work done, instead of being constantly bombarded with non-urgent questions and never-ending status update.
When the sprint ends, the product ships to market, feature launches and customers happy, you need to take some credits instead of being over humble. A lot of software engineers suffer from imposter syndrome and worry about your capability. Instead, take that positive feedback and savor the praise that you deserved from hard work. Don’t just let the PM takes all the credits and leaves you with all the bug fixes.
Common Mistake 3: PM has no clue what to build and no clear requirements
Not every PM has a big picture in mind and a deeper understanding of the market better than you do. He may be living in his mind, masturbating that he has the best idea in the world, but in reality, nobody gives a fuck what he wants to build. He pitches to the world that he is building a rocket, but the requirement he gives to engineer is also one line: go “build a rocket”.
It is frustrating that the PM doesn’t know what to build nor given a clear requirement. You are intelligent, you are motivated to solve hard problems and you love learning something new. You prefer to work independently and get things done. Engineering is hard and the team needs you. You need to collaborate with others, instead of being slavery. If you don’t collaborate with PM to get better requirements, all those beautify lines of code are going to be wasted. Either the product not being shipped or the product launched with nobody use. Your success are measured by the impact you can make to the end users.
At the end of the day, a bad quality product makes everyone suffer. You wasted all your time fixing those bugs due to the stupid decisions made by PM before. It would be so painful to work on a project with a lot of technical debts. That’s why you need to engage early and clarify any unclear requirements that don’t make sense.
To summarize, my 3 tips for you as a software engineer to work with PM:
Think of software development as a team sport. PM is just a role of the team, such as gatekeeper, who can’t survive without the left guard, center, running back etc in the football field. It is a team sport, so you need the mindset of a team with communication, collaboration and leadership to drive towards the common goal.
Originally published at https://victorleungtw.com on February 12, 2020.