I'm a software engineer, and I understand how you feel working with a product manager. With my years of experience, I've met some fantastic Product Managers (PMs) as well as a few bad ones. Every day, I work with the Product Manager, and I understand how you feel. It's tough to continue working on a project when the two people have a strained relationship. That's why, in this essay, I'd like to offer some advice on working with PM as a software engineer.
Working with product managers might be difficult for two reasons: The first is that if he doesn't have an engineering background, he might not understand the level of complexity you're dealing with at work, leading to a lack of respect. Secondly, if he started his career as an engineer, it would be annoying to see him talk about his capacity and comprehension. In reality, he had no idea of what he’s talking about how blockchains, big data, or artificial intelligence work.
As a result, you'll require soft skills and communication abilities to integrate with the software development team.
The first common pitfall is that the PM is unaware of the technological issues. The worst thing is hearing the PM says, "It's only a simple button." "Are you sure you can't finish it in five minutes?" Those comments imply that the work is simple; you are incompetent, which is why it feels so embarrassing that he doesn't understand the depth of your work.
It's not easy to make a button. Consider the Google homepage search button: it isn't "simply a button" that can be completed in a single day. There are other states to consider: hover, click, double-click submission, multiple screen widths, text localization, accessibility for blind persons, and so on. A search button could trigger a front-end-to-back-end API call, query a database with millions of records, and run through a machine learning algorithm... not to mention authentication and security concerns.
It takes more than just writing code to be an engineer. Programming is an art that requires imagination to create something from the ground up, intelligence to deal with complexity, and grit to overcome technical obstacles. Simultaneously, you must learn how to express your best estimate of how difficult a task is to the PM. It would be beneficial to empathise that the PM is unaware of the constraints and makes incorrect assumptions about the task complexity. You're the only one who can judge if something is technically possible and estimate how difficult it will be to develop.
Common Mistake 2: The PM is in charge of the product while simultaneously managing you. It's critical to note that simply because the PM issues the requirements doesn't mean he's the boss. You're not supposed to report to him. You're not coding monkeys, and you're not going to do whatever he says. This practice is especially prevalent in Asia, where hierarchical organizational structures exist or an outsourced vendor handles in-house PM. You wouldn't have enough bargaining power to negotiate in a flat organization.
Not only is it a good habit to follow software development approaches like scrum, but it also saves you from burnout. It also gives the PM a realistic idea of what can be accomplished. You can say no to a change of requirements amid the sprint, just as you can say no to end customers in prioritization. A receipt for a failed product is not agile but a daily change of requirements. Inconsistent requirements result in an inconsistent design with non-reusable code. Bugs and technical debts affect everyone in the end.
A context switch via email, Slack, or protracted meetings can be distracting and mentally draining. To make matters worse, open offices and co-working spaces, such as WeWork, are so noisy and distracting that you can't concentrate on your work in this crowded marketplace. It would help if you avoided being micromanaged by the product manager and being constantly interrupted so that you could concentrate on solving complex challenges that require deep concentration. It will allow you to manage better your time and energy spent on communication so that you can focus on getting the job done rather than being constantly assaulted with non-urgent questions and status updates.
When you have completed the sprint and released the product to the market, new features are introduced, and customers are satisfied. Instead of being humble, you should claim some credit. Many software engineers suffer from imposter syndrome, which causes them to doubt their abilities. Instead, savour the accolades you earned through a hard effort by taking that favourable feedback. Allowing the PM to take all the glory and leave you with all the problem fixes is not a good idea.
3rd Common Error: The Product Owner has no idea what to build and no specific needs. Not every PM thinks about the broad picture, and better understands the market than you do. He may be living in his head, believing that he has the best idea ever, but no one cares what he wants to build in reality. He tells the world he's making a rocket, but the only need for engineers is to "build a rocket."
It's aggravating that the PM has no idea what to create and hasn't stated a specific request. You are intelligent, driven to overcome difficult challenges, and you enjoy learning new things. You prefer to work on your own and complete tasks. Engineering is difficult, and the team relies on you. Instead of being enslaved, it would be beneficial if you partnered with others. All those lovely lines of code will be lost if you don't work with the PM to get improved requirements. Your success is difficult to measure if the PM does not distribute the product properly or no one used the product. Therefore there is no impact on your work.
Everyone suffers when a product is of poor quality. Because of PM's previous dumb decisions, you wasted all of your time correcting those faults. Working on a project with a lot of technical debts would be excruciating. That's why you should get involved early and clarify any ambiguous or illogical requirements.
To summarize, here are my three recommendations for you as a PM software engineer: Non-technical folks who don't grasp the intricacy you work on should be treated with empathy and kindness. Instead of seeing the PM as the boss, be glad to accept credit and collaborate with him. Keep in touch with the industry and understand how to present a good tale to persuade the PM when the requirements don't make sense.
Consider software development to be a team sport. PM is just another team player on the football field, like the gatekeeper, who can't exist without the left guard, centre, running back, and so on. Because it is a team sport, you must have a team mindset that includes communication, collaboration, and leadership to achieve a common goal.