top of page

A new way of thinking about product team roles 

Updated: Jul 1




Teams need clear roles but people want to be heard and be creative. Teams need to balance collaboration and execution. Some teams have found this balance and others are stuck in debates about ownership and that is stopping them from getting things done.

Some of the conflict we’re experiencing is because teams haven’t established roles and norms or individuals on the team are not following the norms. Product, UX and engineering roles are different everywhere I go. The folks filling those roles are individuals with different strengths.


An old-school RACI (RACI – responsible, accountable, consulted and informed) matrix feels complicated, overly formal and not flexible or personalized enough. For some time I’ve been thinking about this problem and trying to come up with a new tool to help teams create clarity and flexibility.


What the research tells us

Roles are norms that tell us how to behave

“Clear and explicit specification of the basic norms of conduct for team behavior, the handful of “must do” and “must never do” behaviors that allow members to pursue their objectives without having to continuously discuss what kinds of behaviors are and are not acceptable.” (Hackman)


Roles need to be understood and defined

“Collaboration improves when the roles of individual team members are clearly defined and well understood — in fact, when individuals feel their role is bounded in ways that allow them to do a significant portion of their work independently. Without such clarity, team members are likely to waste energy negotiating roles or protecting turf, rather than focusing on the task.” (Erickson)


Roles don’t have to be fixed and permanent

“Within a team, individual roles need to be clarified and understood by all. However, role construction can be influenced by personal expectations, and by organisational and interpersonal factors (Maple 1987). Therefore, roles need to be flexible enough to accommodate individual differences, personal development needs and membership changes (Blechert et al. 1987).


A proposed new framework 

Focus

Where should you put your energy and attention? A designer may have an idea about how to build something but if they put all their energy and attention into solving a technical problem they aren’t going to be thinking about flows, needs and how the experience should be.


Prominence

Where should my voice have a greater impact? An engineer may have great ideas about how to solve a user experience problem and the team should consider it but the designer’s perspective should carry more weight.


Contribution

The combination of focus and prominence represents your contribution to the team and it should align to what the team needs from you.


How you could use this

This is a developing idea and I haven’t had too much practical experience yet but I’ve used it as a way to open up conversations between team members and function leaders. I think it’s useful to do this at the functional/department level and for teams. It may also be useful if there are two designers or more than one product person. I welcome feedback and ideas.

Comentarios


bottom of page