Most products are built by a group of people. Learn how to facilitate a workshop to get people to collaborate.
Individual's skills and expertise matter, but skills and expertise might not be the most important.
I’ve created various templates and guides, but four templates accounted for over 60% of download requests. They are:
I plan to revisit these templates in the coming weeks and make some updates. If you are interested in providing feedback and getting early access, drop a comment or send an email to email@example.com.
Over the last year, my thinking and writing on product management have become more theoretical. This is because, partially, I’ve reached the limits of my practical knowledge. There’s only so much I can write about processes. But there’s a bigger problem. In my attempt to share good and actionable advice, I’ve had to dig deeper and deeper in the search for product truth. Except digging for what’s true in product management often turns into a rabbit hole.
The more whys I ask, the less clear the answers. Each answer is more subject to interpretation or applicable only to a specific situation. This makes it harder to write practical advice that’s concise, clear, and applicable.
In my recent articles, I’ve discussed how different aspects outside your control will influence your PM career, such as how product teams are organized, SAFe training, and a boss. My writing is meant to help aspiring or early career PM recognize external forces, even if they aren’t able to influence change. Awareness is the first step to change.
To illustrate an example, a PM recently asked me a simple question.
How much detail should I put into my Story?
Unfortunately, not a straightforward answer. Back in 2020, I attempted to answer this question in “Using product requirement documents and user stories appropriately without creating a mess”. The TLDR is that a user story should be the starting point for the product team (product, engineers, designers, etc.) to come together and have a conversation. We use the Story to start the conversation so we can define and document the necessary requirements. The Story is not the requirement, but the start of those requirements discussion.
Yet, all too often, this context is lost. It’s lost on the PM who believes it’s their job to define all requirements. It’s lost on engineers who don’t feel they have a voice in the solution. However, telling people to “just have a conversation” isn’t very helpful.
It’s too difficult to put into practice. What makes facilitating a CONVERSATION among a group of people with different skills and expertise difficult? Not to mention then getting people to write down in a DOCUMENT so a PM isn’t the only scribe?
Why a conversation is hard work.
For each person working on a product team, whether an engineer, designer, product manager, marketer, etc. there are two areas of skills to consider. There is their individual expertise in their respective role and their teamwork skills.
To facilitate a conversation among people, members of a team must have teamwork skills. So let’s take a look at what we mean by teamwork skills, which I focus on two areas:
Communication (written and verbal)
Conflict resolution (including negotiations)
The reason these are so important is that in teamwork, people are engaged in a coordinated effort to solve a problem together (i.e., collaborating).
As Dillenbourg (1999) notes, there are several qualities that characterize truly collaborative interactions. First, collaboration is characterized by a relatively symmetrical structure, however that symmetry is accomplished. For example, in situations with symmetry of action, each participant has access to the same range of actions. This contrasts with the typical division of labor in cooperative learning structures; partners split up the work, solve sub-tasks individually, and then put their respective contributions together. Symmetry of knowledge occurs when all participants have roughly the same level of knowledge, although they may have difference perspectives. Symmetry of status involves collaboration among peers rather than interactions involving supervisor/subordinate relationships. Finally, symmetry of goals involves common group goals rather than individual goals that may conflict (Dillenbourg, 1999).
To gather the same information, people must ask questions and obtain missing information. To develop a shared group goal, individuals must communicate concerns or differing perspectives, which requires navigating and resolving conflicting points of view or information.
Again, as a PM, you don’t always have the luxury of picking and choosing who you work with. Even if you do, rarely will you evaluate people based on their teamwork skills. Instead, we typically focus on the individual skills/expertise as our primary evaluator and hope for the best when we form teams. But what if your product team doesn’t collaborate as a team?
Show not tell: Leading a one-hour workshop to bring a product team together.
So, in this situation, what’s a PM going to do? You need to lead an experimental workshop to lower people’s defenses.
What does this mean?
If the people you are working with are not collaborating, (i.e., coordinating their work to solve a problem together), then it means people are working more in silos. Silos can work for repetitive, sequential tasks. In that case, you should adopt formal waterfall and project management processes, which I can’t talk too much about.
Otherwise, to get people out of their silos, you have to lead a facilitated group conversation. Here’s how:
Write up a Story, like you normally would. Go into as much detail as is typical for you.
Gather everyone in the product team together. Tell them you’re running an experimental workshop for an hour. It’s important to highlight it’s an experiment. The terminology will often defuse defenses.
Ask everyone to read your Story. Set a time of about 2 - 3 minutes. Recognize that few will read in detail or read everything you’ve written. That’s okay and expected. Remember, your Story is the starting point of the conversation. Don’t be angry if people don’t read everything.
Pick a person to explain the main problem you’re trying to solve in your Story. The goal is to test understanding, but also to develop a shared understanding of the problem, not the solution. If the person you pick has trouble explaining, ask that person to pick another person on the team to ask for help.
Ask another person on the team if they have anything to add to the explanation. In this step, you are actively encouraging contribution to the conversation, which often is foreign to individuals working in silos. People might respond with:
I don’t know.
This isn’t my area of expertise.
I have never done this before.
It is better to ask [name] instead. They are more knowledgeable.
Note that this is common behavior, but remind the participant that this is an experiment, to encourage “coordinated effort”, not just a division of work. Ask them to take a stab or call on someone for help. Either way, they must take an action.
Offer verbal encouragement. Any time you observe a contribution to the conversation, point it out.
Ask people to start writing down what they say. You can use any shared tool (Whimsical, Mural, Jamboard, Slide). The purpose is to remove yourself as the dedicated scribe. So if they say a great point, tell them to write it down to capture it.
Congratulations, you’ve just successfully run a facilitated conversation that engaged in active collaboration.
The unspoken assumption is that for agile product teams to work, people on the team HAVE good communication (active listening, clear writing, formulating questions, framing and reframing questions) and conflict resolution skills. These teamwork skills enable successful collaboration.
As obvious as this statement, too frequently, the communication skills are missing in practice, resulting in coordinated work, but in a siloed, sequential set of activities (i.e., I do step A and only know about step A, you do step B, etc.). To break out, you can run a facilitated, experiments workshop where you purposefully encourage communication. Here, participants are practicing active reading, active listening, reformulating information, and seeking help from others.
What I haven’t covered thus far is any conflict resolution skills, which often arise in such meetings for the first time. It’s also necessary for effective teamwork. But that’s for another article because until you start breaking down people’s defenses and get people to communicate, you can’t identify and resolve conflicts, which are natural parts of teamwork.
How successful is your product team at teamwork and collaboration? Does a group of experts collaborate better than a group of novices?
Good Communication That Blocks Learning | Teaching Smart People How to Learn (discussions on defensiveness, which inhibits learning)
Effects of Task Experience and Group Experience on Group Performance, Member Ability, and Recognition of Expertise
The Knowledge, Skill, and Ability Requirements for Teamwork: Revisiting the Teamwork-KSA Test's validity (a very interesting paper evaluating the KSA test, which is a test for teamwork)