This month we’re focusing on all things Product Leadership. Keep an eye out for events, podcasts, blogs, and more!
After years of experiencing good teams, bad teams, and everything in between, Christine Luc, a Principal Product Manager knows what makes product teams tick and how you as a Product Leader can make your team as harmonious and productive as possible.
In this article, she’ll point you in the right direction on why communication matters, how communication looks like (in bad teams and good teams), facilitating team meetings, giving constructive feedback, and mediating conflict.
Christine Luc is a Product Manager with a background in Product Design and Product Marketing across enterprise and consumer startups. Christine has worked in companies of various sizes, ranging from small startups to large billion-dollar companies.
She is a former Senior Product Manager at Pivotal Software, and is currently a Principal Product Manager at San Francisco Digital Services. She has held many positions in Product across various companies such as Tradecraft, Rodan+Fields, MediaMobz, Gainfully, and Google. Christine is skilled at rallying teams towards a compelling product vision and strategy through to implementation, and implementing agile frameworks for design and engineering teams.
Leading A Team
Where does my expertise on team building come from? It comes from a career as a Product Marketer, a designer, and Product Manager in a diverse set of Product areas. Through this I’ve learned that cultivation of leadership skills is a lifelong practice. I highly encourage you to invest in learning about leadership and communication on an ongoing basis, and practice the skills you learn with your team.
Though there are many different audiences that a Product Manager faces, today we are focusing on your team, loosely defined as anyone building the product with you. This could include designers, engineers, data scientists.
Why Communication Matters
The role of a Product Manager is designed for a team context. Because by design, Product Managers do not build everything themselves. And when more than one human being is involved, communication is the preferred way to interact — it’s a much better alternative to violence. And because (as of today) mind reading hasn’t been invented yet, communication skills are critical in order to interact productively with other human beings.
What happens when communication skills aren’t a priority? I surveyed nine working professionals and asked them to tell me signals of a bad team. Answers included:
- Lack of constructive feedback
- Fear of information sharing, or
- Lack of guidance or direction.
A theme that I observed in their answers was poor (or even antagonistic) communication. How can you get anything accomplished in this type of environment?
Check this out: Characteristics of Exceptional Product Managers
And what might good team communication look like? In that same survey, I asked people to tell me signals of a good team and here’s what they said. Answers included:
- Knowledge sharing
- People feeling safe to speak up
- A safe space for feedback, and
- High levels of collaboration.
In other words, good communication is fundamental to creating good teams. Why should a Product Manager specifically care about cultivating and leading a good team? Because it has a huge impact on the quality of the product itself. For example, engineers and designers can feel empowered to communicate problems with a feature or strategy early on — versus a Product Manager hearing it for the first time in a high stakes situation with an executive or high profile customer.
Another example is that roadblocks can be identified and cleared sooner if people communicate those roadblocks to you and one another. Team members can focus on the product work instead of any lingering frustration from interactions inside a bad team, or negative energy from secrecy or thoughts being misinterpreted. It will also reduce the amount of stress coming from the actual team.
You might also be interested in: Empowering Your Offshore Team is a Part of a Diversity-by-Default Approach
Of course, we know that in this discipline there’s stress in many different directions: focusing on strategy, customers, the competitive landscape, etc. In terms of that day-to-day impact, not having the team be a source of stress for you will create a night-and-day difference.
So how do we lead a team? A fundamental principle in order to move in that direction comes from this famous quote: seek first to understand, then to be understood. If you have this core principle underlying everything you do, you’ll go far.
In practice, this involves active listening. Active listening is defined as the ability to focus completely on a speaker, understand their message, comprehend the information, and respond thoughtfully. To be explicit, this means to listen to what’s being conveyed by people talking to you. People such as your team, your designer, or your engineer. It’s important to focus on the things that they’re saying rather than using the time that they’re speaking to rehearse your own ideas and think through what you want to tell them.
How can you start to understand your team? It’s important to start fresh and get to know them as professionals. Create a forum for getting to know them so you can explicitly learn about who they are. And not just who they are, but what matters to them in work and in their work environment. This is the fastest way to get to know them. And otherwise, if you don’t create space for that discussion, they’ll have their own assumptions about how things should operate and you’ll have your own assumptions. And there might not be an opportunity to get on the same page.
You could facilitate a team norming session as a group or host one-on-ones to learn about each individual. There are many templates out there that you can Google for team norms and workshops, but make sure to cover at least the following areas:
- How will the team communicate with one another? For example, do they prefer asynchronous communication over Slack, or do they prefer to talk in real time vs over a Zoom call?
- What does collaboration look like? Are there preferences for when people want to collaborate versus when they don’t want to? Maybe designers prefer to run through a prototype with an engineer before creating the user stories. What happens at the implementation stage? How are we handling error states for UI? How do we want to talk about that? Do we want to talk about it in advance, or during the process? When you get in the weeds of that collaboration, there can be many different expectations. And it’s good to talk about it as a group
- Roles and responsibilities. I like to call this out because everyone has a unique interpretation of what a Product Manager does, and it’s important to be on the same page with your team. Some Product Managers like to create all the wireframes themselves; others expect to be present for a handful or the majority of qualitative research interviews. It’s important to have this discussion with a design or engineer team so that everyone has a shared understanding of what we expect, rather than finding it out in a live situation where a misunderstanding has occurred.
- How do people prefer to give and receive feedback? What medium works for them? What’s the timing of it? Do they prefer one-on-one, or written, or to talk about it face-to-face? I highly encourage you to research and really articulate what those preferences are, and practice level-setting with one another how you want this team to operate as a collective.
In your day-to-day experience, leading a team often shows up in the meetings that you have with that team. You’re not going to have a team norms meeting every day. Hopefully you will build that shared understanding and try to adhere to one another’s preferences as you work together. But what does working together look like?
With regards to meetings, I like to start with some foundational basics: be sure to have an agenda for each of your meetings. Define what you want to discuss and accomplish together, and stick to that agenda. Ideally shared it in advance if you can, or cover it when you kick off the meeting. If people raise topics that aren’t tied to the agenda, record those topics. Jot them down somewhere, maybe have it visible, share it out afterward. Find a different forum for that topic so that the team can stay focused on the original agenda.
Without an explicit agenda, it’s really hard to negotiate what the goal of the meeting should be. So when you have the agenda everyone agrees on what is valuable to discuss, and then it’s easier to focus all of the group in a particular direction. But if you don’t define the agenda, when you begin the meeting the team could pull it in many different directions, and maybe even switch gears midway through. And it can be hard to see any creative or valuable output at the end of that timeframe.
Giving Constructive Feedback
There are times when you may need to give feedback to another member of the team, say, if a design isn’t solving for the user story. Consider using a feedback framework to prepare your feedback, particularly for high stakes situations. These are some examples of feedback frameworks that you can research, though there are multiple types out there. There’s:
- Situation, behavior, impact, (SBI)
- Observations, feelings, needs, actions, (OFNA)
- Actionable, specific, kind (ASK).
Let’s work through how we might actually use a feedback framework. In this case, I’ve pulled one for the Situation, Behavior, Impact framework (or SBI framework). In this situation, I’m a Product Manager and I’m trying to give feedback to one of the engineers on the team, and I talk them through the process.
- Situation: we are encountering an increase in critical bugs reported our customers.
- Behavior: I’m observing that opportunities to discuss how to resolve this are being ignored. If it’s brought up during standup or during a retrospective, the claims are dismissed. Although there are suggestions to work together to bring up ways to solve it, they’re not being prioritized in your calendar.
- Impact: there’s no clear path forward and I need your engineering expertise in order to identify next steps.
The Impact will cover the impact to the team, or it could apply to the impact to you as the individual giving the feedback. It’s pretty broad in terms of how you can think about it, but what is important when communicating feedback is creating a forum to identify what the resolution could be. In marketing terms, we’ve heard this as a call to action. Essentially: when the feedback lands, what happens next? You don’t necessarily have to define what that is. I would encourage you to work with the other party to come up with what you can do together going forward.
What’s important for giving constructive feedback is to practice giving the feedback. Jot down what you want to communicate, or if there’s a risk to the relationship if the feedback is poorly phrased. Think it through. Consider running it by a neutral party to see if the points you’re articulating are understood, or if it’s coming off in a much more negative light than you intended.
Another great article: Product Leadership Skills: Influence Without Authority
So for example, with the SBI we did, I might take those notes and run it by a peer. Let’s say, a Product Manager who’s not involved with this team at all, and see if the messaging resonates. Or if I could include additional clarity or detail, any concrete information to really flesh it out. Or if I could word a particular phrase more diplomatically, etc, etc. Consider it as an iterative feedback loop.
What’s important though, is that because these are working relationships with your team—this is the team that you are with for the duration of the product that you’re leading—don’t wing it. Don’t say something half-baked or poorly phrased on the fly, especially if it could hurt their feelings. It’s important to treat these relationships with respect and put in the time and attention that you would want them to do when they’re giving you feedback.
Whenever possible, see if you can take conflict outside of a team meeting. A common scenario I’ve seen is: there’s a team meeting just to go over daily stand ups, a retrospective, or a particular line item that’s starting to take up much more time than we intended.
It’s starting to cover a lot of different facets that maybe an engineer or designer wasn’t prepared to elaborate on in the timeframe for that meeting. Emotions are getting high, and the conversation is starting to get heated. See if you can take that item out of that meeting. Take a time out and find another time to have a proper dedicated discussion where the goal is to understand what’s going on, rather than derailing from the goal of the original meeting.
Let’s say you’re in that session. You’ve set aside a meeting, and this is the time to really talk through it. Make sure to start with a shared goal between designers, engineers, data scientists, whoever. Maybe the goal is: we’d like to successfully release this feature. Or we’d like to improve code quality. Articulate what the goal is, and get agreement from all parties that that is indeed the goal. Give people the chance to clarify and state their perspective. Find alignment so that we know that we have the intent to move in the same direction.
Next, seek to understand. Assume positive intent when facilitating a discussion like this in order to encourage positive intent from other individuals. You might even want to say that out loud or set some ground rules on how you want to communicate with one another. For example: we’ll focus only on X topic, we’re not going to bring up past issues. Discuss how you will communicate about that topic. Then, use a feedback framework like the ones discussed above! These are helpful even in a conflict setting because it will help you talk through the Situation, the Behavior, and the Impact as a collective.
If it’s a conflict between more than two individuals, it could be important for everybody to get on the same page about that situation. Maybe there are some aspects of the situation that are visible to some members of the team versus other members of the team. And creating a forum to seek to understand, and hear about it so that everyone is on the same page.
Be honest about the Behaviors—not just negative, but positive. In this situation, what we liked was that people were so responsive and people put aside their work in order to troubleshoot the situation, and I appreciate that. It’s critical to really level set and look at the situation in order to help the team understand that the negative within this broader context maybe isn’t that negative. Maybe it’s only a small portion of the overall situation.
Talk through the Impact, similarly to how you would in a one-on-one conversation. Every party involved in this conflict should really talk through the Impact from their perspective. And for this, I recommend having them represent their own experiences. It’s tempting to represent someone else’s experience—for example, if you’re on a team where one member is highly trusted, they’ve heard the venting/complaints/problems from other members of the team, and they have a broader perspective. But try putting aside broad generalizations about perspectives, and represent your own perspective.
And potentially as a ground rule when facilitating this conversation, ask all members of the team to do the same. Ask them to please relate or relay their direct experiences so that the situation is most accurately and fully presented. That will make it easier to ask clarifying questions in order to get to the root of a particular conflict.
In any kind of situation, getting to know your team, facilitating day-to-day meetings, and handling conflict are important. Hopefully this article gave you some vocabulary to start practicing these different techniques to get better over time. You can always ask for feedback on your feedback, to see if the way you conveyed it or mediated the conflict was successful. And as a reminder: this is a lifelong practice, so don’t get too discouraged! We’re all growing.