Clarity for Product Managers, Part 3: Role Clarity
I’m excited to continue my mini-series of blog posts on a topic that I feel is essential for product people: clarity. In this series, I’m sharing my tips and tricks for both individual product managers as well as product leaders. In the first post, I introduced some common reasons why it’s hard to achieve clarity, outlined the four layers of clarity, and offered my tips for PMs on how to achieve directional clarity. You can find all that here. In the second post, I introduced and defined the concept of situational clarity. Find that post here.
In this article, I want to discuss the topic of role clarity with you, so you and your coworkers and leaders know what to expect from each other. This involves both formal job roles and specific responsibilities within certain collaborative projects.
Defining role clarity
Role clarity is how well you understand what’s expected from you and what you expect from others during collaboration. This usually has some general aspects such as what’s expected from a Senior PM in your organization, but often also has context-related aspects such as how to best act as a Senior PM within a particular team given its scope, the current situation, and the other team members involved.
Clarifying roles is even more crucial in temporary collaborations such as working groups or multi-team efforts for a joint product initiative. Sometimes this is just about who will feel responsible for scheduling a follow-up meeting or informing others of the progress, but it also involves mandates for decision-making.
As a PM it’s important not to rely on your superiors to provide complete role clarity for you, but to take the initiative to create it whenever you notice ambiguity.
Assessing your ability to provide role clarity
Here are a few questions you can ask to assess how well role clarity is defined in your environment:
Are you doing things that aren't your job?
Please don't misunderstand this question: I am a strong proponent of trustful overlapping areas, such as UX stepping in for PM within product trios. However, I find it potentially problematic when Product Managers by default jump into all unresolved gaps (e.g., because they used to do project management) or interfere more than necessary in other things (e.g., because they were once programmers).
Are you disappointed by the passivity of your colleagues?
There are several dimensions to this question: Do your colleagues even know your expectations of them? And is it clear to them what their role is within the collaboration?
I observe the second phenomenon, for example, when several PMs are involved in a larger initiative, but all seem to take a back seat because it's unclear who is actually in the driver's seat.
Is it clear to you who makes which decisions?
If not, this can lead to delays in clarification and make collaboration frustrating. Often, when there is a lack of clarity in disagreements, colleagues do not necessarily insist on their point of view but need decisions to be able to move forward.
My observation is that lack of role clarity mainly arises when the expectations and mandates of those involved are not clearly discussed at the beginning of forming a team or a joint venture and things just happen because:
it's trusted that things will work out since everyone knows each other well.
it's assumed (erroneously) that role responsibilities are universal and the professionals already know what to do.
there may be a reluctance to create hierarchy among people who have similar levels of seniority within the organization (such as appointing one of several Senior PMs involved to lead a joint initiative).
As PMs and product leaders, you can, of course, actively contribute to role clarity in your team and in your collaboration, which we’ll cover in the next section.
Concrete steps for role clarity: Advice for PMs
How do you ensure role clarity as a PM? Here are a few of my recommendations.
Clarify role expectations in your team with a workshop
I have had good experiences within cross-functional teams conducting role expectation workshops.
The main "trick" here is the right framing to ensure that the workshop focuses on the ROLE and not the PERSON. This makes it significantly easier for the individuals addressed to accept expectations without going on the defensive.
Agile coaches can, of course, be a great help in conducting these workshops. In fact I first learned about this workshop framing from the first (and to this day the best) Agile coach I have worked with, Mel Lang. Since PMs are not always in the lucky position to work with great Agile coaches, the framing above allows you to take the initiative as a PM and initiate a role clarification workshop.
How to run the workshop
Invite all team members to the workshop. Tell them that you want to improve collaboration and eliminate misunderstandings by establishing shared role clarity and talking about each other’s expectations of the different team roles.
At the beginning of the workshop, clearly state that the workshop is about ROLES on your team (such as PM, Product Designer, Backend Developer, QA, etc.) and not about the specific person behind this role. And please ask everyone to be open to listening to everybody’s expectation of their role and to try not to take this discussion as criticism. It’s about good teamwork, not about them personally!
Next, ask everybody to think of every other role on the team and for each role, answer the three questions:
1. What traits would the perfect <role> have?
The first question intentionally targets the absolute best-case scenario. It's clear that no one is perfect, but discussing the characteristics of the role shows what is important to colleagues without them feeling criticized for their specific work.
2. What must <role> know to work well with you?
The second question aims to provide space for individual needs within collaboration. For example, how thoroughly does a certain developer want the edge cases described in tickets?
3. What can YOU do to help <role> do a great job?
The third question is about reversing roles and consciously emphasizing mutual responsibility for the success of the collaboration.
You can use one large Post-it per question and per role.
When it’s time for everyone to present their Post-its, I suggest that you hear everyone’s expectations of one role before moving to the next. This way you will observe interesting overlaps as well as variations or even contradictions in what different roles on your team expect from a particular role. This helps to underline that there’s no right or wrong.
You may notice that some team members may get defensive or get into justifications in response to what they hear. If that’s the case, remind them that it’s about their role, not about them as a person and invite them to ask questions to clarify what the other team members shared, but other than that, just listen and take the feedback with them.
In general I recommend that you make the first workshop only about listening and understanding each other’s expectations. Resist the urge to jump to solutions. Instead it’s better if you schedule a follow-up meeting in which you give everybody the chance to share their thoughts on how they live their role after listening to their teammates’ expectations of it.
Depending on context, it can make sense to not only clarify role expectations within a team, but also between the PM and other relevant stakeholders such as the leaders of the go-to-market teams. This is particularly relevant if either of them lack experience in how to work with the other role. For instance, a PM who has only worked in B2C organizations will benefit from clarifying role expectations with their customer success and sales colleagues to smoothen collaboration and manage expectations.
Point out unclear responsibilities
In addition to the usually more permanent role within your team, you will also find yourself involved in temporary projects or initiatives, collaborating with people from other product teams or other disciplines such as go-to-market or legal.
In these situations, you cannot rely on the role clarity you established within your team. Instead, you will need to clarify roles for the collaboration in that particular project. Otherwise you run the risk of slow decisions or you may notice that nothing is moving forward because everybody is just sitting in the backseat and nobody’s driving. If you find yourself in such a situation, it's important that you actively address it and seek clarification.
Sometimes this can be self-organized. In other cases, clarification needs to be escalated (together!) so that superiors know they need to better define responsibilities. I’ve written about joint escalation in the past. Find that article here.
Either way, I find the DACI framework (Driver, Approver, Contributor, Informed) helpful to clarify responsibilities and decision mandates. It’s not the only framework of its kind, but what I like about DACI is that the term “Driver” beautifully expresses that there should be EXACTLY ONE person ultimately responsible for moving things forward and making decisions if necessary.
Here’s an example for the four different roles in DACI:
Driver: Aligns with the Approver on goals and decision criteria, seeks input from Contributors and makes the decisions.
Example: For a synchronized go-to-market of various product releases in preparation of a larger trade-show event, one of the involved Product Managers, Mandy, is appointed the Driver.
Approver: Sets decision criteria, can approve or reject decisions by the Driver if needed.
Example: Mandy aligns with the CPO, Estelle, on the relevant decision criteria such as must-have qualities of the product that Estelle considers absolutely necessary to make sure the product’s presentation at the trade show supports the overall strategy. Once this is clear, Mandy will keep Estelle updated and Estelle will only interfere if asked for clarification (for instance if the joint group cannot agree which trade-offs to accept as the consequences of accommodating Estelle’s priorities) or unexpected problems.
Contributors: These are the different experts, collaborators, and people who are significantly impacted by the project.
Example: Mandy as the driver will make sure to collect input from relevant contributors such as PMs from other involved teams, Product Marketing, Customer Success etc., possibly run alignment workshops with them, and collect their input. Because Estelle clarified that Mandy is the driver of the initiative, the contributors understand that by default Mandy will make the necessary decisions. If they completely disagree with Mandy’s decisions they can seek joint escalation with her and involve Estelle. Of course it is in Mandy’s interest to keep the contributors updated and give them the feeling that their input has been heard and considered—even if her decision is not the contributors’ preferred approach.
Informed: People who are kept updated and informed about decisions, but don’t actively contribute. Personally I don’t find this category very important to clarify, but it’s part of the framework and the easiest bit.
Example: Once decisions have been made, Mandy will keep the rest of the organization updated as part of the organization’s regular update process or if urgent with a dedicated update.
Trigger active dialogue about your role with your manager
Last, but certainly not least, it is also important that you are clear on what’s expected of your role in your organization and by your manager in particular. This will be obvious when you first enter the company or when you start a new role or have a change of manager, but even if nothing has changed, it will make sense to make role expectations part of your dialogue with your manager. This is also a good chance for you to make sure that your interactions with your manager do not purely focus on operational daily business topics, but that some of your conversations are also about reflecting on how you are doing and identifying opportunities for your personal development.
Now, ideally this is something your product leader will consider an essential part of their role anyways and make it a natural part of your conversations. And ideally your organization has a clear competency profile for your role in your organization (I’ll write more about this in my upcoming blog post on clarity for Product Leaders). Additionally, in an ideal world, your product leader has already shared with you their “definition of good” and which aspects of your role they find particularly important (for instance by using Petra Wille’s PMWheel).
If your reality is less ideal than what I’ve described above, I strongly recommend that you trigger the necessary dialogue. You probably cannot insist on your product lead following certain frameworks, but it’s a totally fair part of “managing upwards” to ask your manager what they expect from you in your role, how well they see you fulfilling your role, and what both of you can do to close identified gaps.
If you find it difficult to create the necessary room for this kind of dialogue in your regular interactions with your manager, it’s totally okay to ask them for a dedicated meeting for this conversation. This has the advantage that your manager can also prepare and will likely be more comfortable with the conversation.
Final thoughts
To recap, we’ve covered why role clarity is important in collaboration, outlined some ways you can evaluate the current role clarity in your context, and considered some specific tips and tactics that can help you gain more role clarity.
Are there additional aspects of role clarity for PMs that you find important and that we should share? Please add them in the comments.
And for the next post in the series, we’ll be looking at the fourth (but fundamental) layer of clarity for product people: clear communication.