Hosting a Successful Meeting

Product teams host countless meetings, both in and out of the Agile ceremonies. There are workshops, brainstorming sessions, stakeholder read-outs, initiative discussions, user feedback sessions, and many more. Product leaders bring people together to share ideas and create results. Being able to host an effective meeting is a skill any product manager should be adept at.

Purpose
The most important part of a meeting is knowing why you are there. Every gathering should have a crystal-clear purpose, more than the general category of meeting. For example, “one-on-one” is not a purpose.

Effective naming of the meeting can be one way to communicate its purpose. By naming the gathering on the invitation and repeating the name in reminder emails, you create a sense of belonging before anyone enters the (virtual) room. Names can create social contracts. The best names help us understand our role at the event and help us to understand that we’re a part of something.

Even small nuances in naming are noticeable and important: Update is different than discussion; Workshop is more structured than brainstorm; Catch-up is more casual than one-on-one.

Think through your naming – how can you convey the most information, have the attendees feel not only that they belong but that they are true participants in the purpose.

Attendees
Priya Parker, in The Art of Gathering: How We Meet and Why It Matters, states: “Thoughtful, considered exclusion is vital to any gathering.” 

Think through who will help fulfill and forward the purpose, and who will not. Who are you inviting out of obligation? Different organizations have different cultural norms around meeting attendees - learn your organization’s unwritten (or written) rules here, but also be willing to stretch them make it work for your gathering. My current organization is a consensus organization that loves to share information, so often invites will get forwarded to additional attendees. For more structured or meaningful gatherings, it might be a good idea to turn off this feature in Outlook or put a note in the invite to not do so.

Format
The attendees should be prepared for the format of the meeting. Are you sharing materials in advance that they need to read / prepare comments on? Should they come prepared to engage or will they be mostly listening and then walking away with homework? Are multiple people hosting or presenting materials?

Think through the before, during, and after. Will you need tools like whiteboards if in person, or a prepped Miro template if virtual? Do you want to do a poll or survey during the meeting? How will you follow up on any ideas or action items after the meeting?

During the Meeting
Priya Parker is adamant to resist the urge to start your meeting with logistics or reminders. Instead launch in a way that sets the tone for the rest of your time together. If this is a team that meets often or a meeting that occurs at a regular cadence, consider creating a ritual that sets the stage. This is why radio shows and podcasts have theme songs - it alerts listeners that the content is starting and cues them to listen more attentively. (For one of my recurring meetings, this is as simple as sharing a Miro board link in the chat. As soon as I do that, the chitchat ceases and we are down to business.)

Involve participants in the meeting by asking for help. When you help contribute to something, you feel a part of it - so even though we are afraid to burden folks by asking for help, this can be beneficial for all involved. The asks can be very low stakes - ask someone to record the meeting, or share a link, or pass out sticky notes if you are in person. These micro-moments help move us toward belonging.

Throughout the meeting, promote debate and meaningful interactions. Look for a healthy tension as people discuss ideas. If you shy away from difficult topics, you might not arrive at the best solution, or let all diverse perspectives be heard. Parker says, “Good controversy can make a gathering mattering more,” and it can certainly make it more memorable.

Ending
Just as you begin intentionally, end intentionally. What can a deliberate conclusion look like? One way is to simply plan enough time for attendees to reflect on the meeting and what happened.

Part of leaving the meeting space, especially for longer gatherings or workshops, is prepping to reenter the world. Ideally you made a new space, and it will feel like a departure to leave it. So how can we connect this gathering to the day-to-day? How can a part of this event or these learnings stay with attendees? Parker states: “Part of preparing guests for reentry is helping them find a thread to connect the world of the gathering to the world outside.”

After the meeting, be sure to follow up on any action items and distribute artifacts that were created. Depending on the meeting, these actions could happen once, soon after conclusion, or multiple times over the course of days or weeks.

The only way to improve your meeting hosting / leading skills is to practice. Luckily, product teams provide many opportunities to do just that. Trainings and reflection activities can also help bolster this skill. See below for a stand-up activity that does just that.

---

STAND-UP EXERCISE

In preparation, have your team review Priya Parker’s blog, or even better, read her book: The Art of Gathering: How We Meet and Why It Matters

Ask the team to reflect on intentional and meaningful gatherings they have been a part of, whether virtually, hybrid, or in-person. Look for similarities of these events, and what can be learned or replicated. How can they take these elements back to their own meetings?

Supporting Introverts on Product Teams

Extroversion is praised within American (and similar) society. People who speak the most, process thoughts out loud, or are very social often get a lot of attention, and it is typically positive. They often appear more confident or assertive. Extroversion can be a proxy for competency.

But it wasn’t always this way. In Susan Cain’s book “Quiet: The Power of Introverts in a World that Can’t Stop Talking,” she traces the history of valuing extroversion to the changing society of the industrial revolution. American values shifted when we moved from distributed agricultural communities and migrated into larger metropolitan areas. As members of small, close-knit communities centered around farming and family, society placed value on inward traits like work ethic, integrity, and kindness. But the new industrial cities created more anonymous environments, and the ability to stand out or have your individual ideas heard became more important. Extroversion was realized as a positive trait. (Susan Cain also has an excellent TED Talk on the power of introversion.)

Introversion and extroversion may be opposites, but most people fall somewhere on the spectrum between them. The exact middle would be defined as an ambivert, a true balance of either end. Introversion or extroversion also may depend on a person’s environment or familiarity with a group.

Regardless, the goal of a product team is to empower all members of the team to actively contribute. We are also always looking for team members bringing a variety opinions and outlooks, and having a diverse team in terms of personalities is beneficial. Having introverts on the team can balance the more outspoken personalities. Introverts can also bring a level of thoughtful deliberation and depth of perspective, where extroverts may be quicker to act.

However, just having diverse personalities on the team is not enough - you must accommodate everyone’s communication styles to encourage their participation. In addition to psychological safety, there are other ways to create a more inclusive experience for all personalities, especially in our meeting-centric business environment. Generally these accommodations lead to more thorough and thoughtful discussions and decision-making.

• Collaboration Tools - I am a huge proponent of Miro, but any collaborative virtual space can do the trick if it provides real-time commenting in multiple modes. Polling during a meeting can also be helpful here.

• Collective Brainstorm prior to discussion - Many of my stand-up prompts follow a similar format of asking a question of the team, providing an opportunity to answer individually (usually through stickies on a board) and then coming back together to discuss. Even if all ideas don’t get discussed, they are usually all read, and will be recorded in meeting artifacts.

• Agendas! - Letting meeting attendees know what topics will be discussed or what decisions will be made provide those people who need a longer deliberation time to do so prior to the meeting starting.

• Asynchronous “meetings” - Beginning a dedicated discussion thread via Teams or Slack allows team members to answer once they are confident, or to decide on the correct wording before sharing.

• What else? Brainstorm more accommodations with your team through the stand-up exercise below.

And, perhaps one of the best considerations of all personalities is simply making space for them. Paying attention to the different needs and preferences of everyone - and valuing those individual differences - creates a culture of respect and acceptance within the team. That leads to better team health, and happier team members - regardless of personality.

---

STAND-UP EXERCISE

Ask your team to take an introversion/extroversion quiz to see where they might fall on the scale. I had my team use this one from TED.

In our stand-up, we discussed results by polling based on the quiz result. Then, they answered the question of their own accord, placing a dot on a spectrum of where they felt they landed between extrovert and introvert both in their professional life and their personal life. Discussing how these roles flipped for folks between the two environments was very interesting.

We ended with a brainstorm and discussion prompted by the question “How can we better accommodate team members along all points on the scale in meetings / ceremonies / work streams?” The goal is to incorporate those ideas into our product team meetings.

Control versus Accomplishment

Employee burnout continues to be on the rise, with more than 50% of US workers experiencing at least moderate burnout. As a product leader, keeping a pulse check on your team members can help you spot burnout tendencies before they arise.

There are several risk factors to burnout:

1. Workload - everything you are responsible for, along with the access to the resources and support you need to meet those responsibilities

2. Control - your ability to direct or change your own work, setting your own goals and boundaries (can you say no to a request)

3. Reward - are you receiving recognition, opportunities, a sense of accomplishment, or simply positive feedback for your work

4. Community - a psychologically-safe environment, where you feel supported and connected, unafraid to show up authentically. Additionally, is the community consistent and fair, or reflect your values.

Three symptoms characterize workplace burnout:

• Exhaustion

• Cynicism (including distancing yourself from work)

• Inefficacy (or feelings of incompetence / lack of achievement)

Being transparent with your product team about what contributes to burnout and if your team is feeling any of the symptoms can help identify where changes might need to be made. It is important to note that while personal factors may complicate or compound burnout, it is by definition a workplace phenomenon. It is about the systems, structures, and demands of the workplace, not the individual employees.

There are many ways to pulse check with your team. The below is based on a weekly survey by Boston Consulting Group that they instituted while experimenting with predictable/mandatory time off. Awhile back I wrote about a tool called Care that provides a questionnaire as well as actionable insights. Regardless of how you do it, these discussions with your team should be a regular part of product team health check-ins.

---

STAND-UP EXERCISE

Using a survey or the matrix below, ask your team a series of questions based on two factors - control and accomplishment. These are two of the major risk factors when it comes to employee burnout. For control, ask how much predictability or stability team members might have regarding their workload and their schedules. For accomplishment, ask how much value they feel they are providing or if they’ve learned something useful lately. Understanding where team members fall on these axes can provide some insight to their potential levels of burnout.

To push the exercise further, ask team members what type of activities or interactions provide them the largest sense of accomplishment. Potentially think about answers on a timescale of daily, weekly (or by sprint), quarterly, etc. Are there ways you can facilitate or cultivate more of those types of activities?

Product Team Roles

Books are written, podcasts are produced, TedTalks are given, all about product and product teams. So much so that it can seem like there is only one correct way to build a product team. However, a more encompassing approach might be to take an Agile mindset to building a product team. At its root, a product team is a cross functional team (a team with members from different functional areas) who are united to design, develop, and ship a product that fulfills the target user's needs.

How that team is comprised can vary. The core components of responsibility can be met by specialists or generalists. You can have just a couple folks on the team or enough to eat two pizzas. Your organization may have both a product and a project structure, which introduces a new set of players.

Regardless of who is on the team, responsibilities should be defined. Everyone on the product team should know their role. This chart is generally what we shoot for within the teams I manage - from a product perspective. This chart does not include engineering roles. In a different organization, you might also want to add a product marketing role, or more.

Note that the headers of these columns denote a role on the team, not necessarily a job title. The team just needs to agree on who is performing what role.

The idea is that with agreement on who does what within the team, there is more empowerment for that person to take responsibility for the items within their jurisdiction. There is more individual autonomy and accountability, which leads to better team autonomy and accountability. The visibility into each other’s roles also allows for more communication within the team.

Teams evolve over time. New roles are needed as the team matures; folks leave and don’t get replaced; the product changes and requires a different setup. Periodically, the team should evaluate what is working and what might be missing. Iterating on the team construction is also part of the Agile process.

If you are a director or portfolio manager, you may also need to consider how you structure your product teams within the larger organization. There are just as many options here, which we can perhaps cover in the future.

---

STAND-UP EXERCISE

A product team should all agree on roles and responsibilities. If you do not have a responsibilities chart like the one above for your team, you should construct it. An Agile coach or a manager can help bring an unbiased eye if there are any questions or discrepancies in jurisdiction.

One you know who is doing what, a good discussion can be “who are we missing”? If another person could be added to the team, which role would be most beneficial to add them into? Portfolio managers, this is a great exercise to see if your organization is under-emphasizing certain areas of product management.

Supporting Users with Micro Interactions

Any product should not only provide utility or interest for users, but also support them in their interactions. One way to do that is through the use of micro-interactions - small indicators or animations used to communicate meaningful feedback to the user. This supports the user in a more intuitive, engaging, and efficient experience with the product.

Also, it is just a human tendency to expect something to happen when you click a button, scroll a page, add an item to the cart, swipe left on a card, etc.

To be defined as a micro interaction, it should be triggered by the user or the system AND give feedback on an action. A simple gif or animation is not a micro interaction because it is not triggered by the user. A button by itself is not a micro interaction, unless it provides feedback when the user clicks/taps. A video player is a feature, but the volume control slider within it would be a micro interaction.

For more examples of micro interactions, and a brief explainer on Dan Saffer’s triggers and rules, check out this article by UserPilot.

---

STAND-UP EXERCISE

After learning about micro interactions, ask your team to come up with examples from the products they use (or competitor’s products, potentially). Are these delightful? Do they make the product more intuitive or efficient? Are any of them exceptionally on-brand (or maybe off-brand)?

Then think about your own product. Are there areas where a user could feel more supported in their interactions with the interface or process? Is there information that could be better or more holistically communicated? Is there an area where you can reinforce the natural desire for feedback?