Treat roles as accountabilities
I use “role” to mean an accountability in a product-development system, while a job title describes how an organization names a position. The two can overlap, but they are not interchangeable. A person with a product manager title may take on several team accountabilities, and a scrum role may be shared or supported without appearing in anyone's title.
That distinction helps me avoid arguing from labels.
Clarify who does what
I would make product direction, backlog ordering, technical design, quality, facilitation, and people leadership explicit. In Scrum, accountabilities describe how the team creates value; they do not automatically define a reporting line or a complete career ladder.
I would ask what the organization expects in practice. Does the “scrum master” facilitate and coach, or is the person being asked to assign tasks? Does the “product owner” make product decisions, or only maintain a ticket queue? The answers matter more than the words.
Use titles carefully
When writing a job description or designing a team, I would describe outcomes, decisions, collaboration, and success signals. I would avoid importing responsibilities from a title without checking the product context.
Make the operating agreement visible
I would turn the practice into a lightweight agreement: who owns the next decision, what evidence is needed, which risk is being watched, and when the team will review what it learned. That makes the work easier to coordinate without pretending the process is the outcome.
I would invite the people doing the work to challenge the setup. Their experience can expose a hidden dependency or a safer way to improve the system before a small issue becomes a delivery surprise.
My bottom line
Clear accountabilities reduce role confusion and make collaboration easier. The Product HQ technical product manager certification can help build delivery fluency. I also share practical lessons in the Product HQ newsletter.