A “PM/PO relationship” is not a thing that needs to exist, because these roles do not need to exist as separate entities.
Complicated relationships is exactly what your company deserves for making up a job titles based on scrum a scrum process that isn’t even a full-time job. Of course there’s going to be unclear roles and responsibilities.
Forget the titles PO/PM because they are irrelevant for a second.
Are you arguing that the day-to-day scrum team interactions and strategy mapping/PRD’s… should be managed solely by the same person?
Or are you arguing that the structure of two people to this product is fine, they just need a different titling mechanism (maybe PM/ Sr. PM)?
Yes.
It’s one role, no need to make it two roles.
Managing a software across iOS/droid. Planning calls, daily stand-up, compliance, stakeholder calls and all the other calls take up the majority of my days. When do you get time to actually create a strategy, review data and make data based decisions?
That’s what I’m struggling with, hence the likelihood we’re gonna hire a PO.
Yes, the job is demanding and comes with a lot of responsibility. So, not only in your product development efforts but also in the rest of your work, it’s critical to prioritize what truly adds value.
However, a PM doesn’t necessarily have to handle all of the duties associated with leading the team. You should collaborate with staff+ engineers and engineering managers to take on some of that. Also, engineers ought to be in charge of their own projects.
When the PM is overloaded with daily tasks such as dependency mapping, co-designing, technical stakeholder communications, project planning, effort estimating, etc., program/delivery management roles are also fantastic additions to the team.
If so, the PO is at fault and has obviously gone above what is expected of them. The PO is not required to decide if designs are valid, nor is it necessary for their judgment to be the ultimate word.
They are creating a poisonous and disrespectful atmosphere while undermining the PM and their capacity to fulfill the requirements of the PM function.
It’s past the point of waiting for them to work things out, and it really ought to have been settled after the initial altercation. If it were up to you, I would be extremely clear about where the line between the two tasks should be drawn.
I previously had a job where all of the titles were PM, but the CPO divided the roles into PO and MO. Market and product owners.
Market owners strategically controlled the roadmap, the packaging, the GTM, the marketing and sales enablement, the engineering (management, architecture), and essentially anything that could possibly go wrong.
The tactical responsibilities of product owners included managing the backlog, the MO’s expectations, and collaborating with support, IT, engineering (more tactical development on an ongoing basis), architecture, agile events, etc.
Many teams fell short. Some were successful. Everything was based on compatibility and personality.
As a MO, I was. With one product and one PO, I began. finished with a number of products and the corresponding POs. They were pleasant times.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.