A bit of context, I was a team lead for 15 months on my previous job so I had a lot of interface with my then product/project manager.
Usually programmers get more involved in the project and perform better when they know why they are working on said task/story/feature. A good PM always backs his/hers users stories with a solid, business oriented reason.
Communication is key, and that goes both ways. The best PM that I've worked with held pretty strong standards on deliverable quality, but was also a great listener when the team argued that something couldn't be done due to technical limitations, or when a requirement had to be changed/negotiated.
Generally speaking programmers hate when the project scope changes. If the change was big or really far down the project, they hate it even more. Shit happens, we all know that, but a good PM always does his/hers homework on project risks and keep the team aware of the risks before they turn into real problems.
A good PM trusts... Once that trust has been earned. Your team has a great record of shipping fast and with great quality? Good, lay down the requirements, stories and acceptance criteria and let the team do the job. On the other hand, if their performance is spotty you may want to pay attention to that and act if that compromises the project delivery in any way.
The best PM that I've worked with was extremely organised and always kept the team aware of current project status and clear next steps. We may not always agreed, as expected, but always respected each others opinions and decisions.
🇩🇴 I'm a Technical Program Manager and Content Strategist with an MSc in UXD. I help developers become better content creators and DevRel teams build robust content programs.
I'd also add that a BAD PO relationship could involve PO telling you WHAT to do instead of the desired outcome. We had a scenario where we were being asked to store a piece of data that has nothing to do with our other data, and isn't created by our applications. The addition of that data would create an EXTREMELY large feedback loop that would most likely create more issues than it solved. The team that generated that information and whose information was actually relevant to it ALSO had a means to be queried, and doing so on THEIR part would close all of that funky feedback loop nonsense. Business team had no clue that their 'requirement' was problematic, but they still attempted to have the dev team do that work.
A GOOD PO would have brought the desired outcome to the team/lead and asked if there was a good way to make this happen on our side.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A bit of context, I was a team lead for 15 months on my previous job so I had a lot of interface with my then product/project manager.
Usually programmers get more involved in the project and perform better when they know why they are working on said task/story/feature. A good PM always backs his/hers users stories with a solid, business oriented reason.
Communication is key, and that goes both ways. The best PM that I've worked with held pretty strong standards on deliverable quality, but was also a great listener when the team argued that something couldn't be done due to technical limitations, or when a requirement had to be changed/negotiated.
Generally speaking programmers hate when the project scope changes. If the change was big or really far down the project, they hate it even more. Shit happens, we all know that, but a good PM always does his/hers homework on project risks and keep the team aware of the risks before they turn into real problems.
A good PM trusts... Once that trust has been earned. Your team has a great record of shipping fast and with great quality? Good, lay down the requirements, stories and acceptance criteria and let the team do the job. On the other hand, if their performance is spotty you may want to pay attention to that and act if that compromises the project delivery in any way.
The best PM that I've worked with was extremely organised and always kept the team aware of current project status and clear next steps. We may not always agreed, as expected, but always respected each others opinions and decisions.
What a thorough and thoughtful response, Vitor. This is exactly the level of detail I was hoping for. Thank you!
Glad I could help 😄
I'd also add that a BAD PO relationship could involve PO telling you WHAT to do instead of the desired outcome. We had a scenario where we were being asked to store a piece of data that has nothing to do with our other data, and isn't created by our applications. The addition of that data would create an EXTREMELY large feedback loop that would most likely create more issues than it solved. The team that generated that information and whose information was actually relevant to it ALSO had a means to be queried, and doing so on THEIR part would close all of that funky feedback loop nonsense. Business team had no clue that their 'requirement' was problematic, but they still attempted to have the dev team do that work.
A GOOD PO would have brought the desired outcome to the team/lead and asked if there was a good way to make this happen on our side.