The way they do the meeting will tell you everything.

Who speaks at the meeting? How do they make decisions? What do they talk about? Is it technical details, customer insights or revenue and money? Do they talk about tasks and deadlines or blurry visions about the future? Are there debates or ideation sessions?

None of these are good or bad, but these signs can help you evaluate the culture of the team.

If you are the leader of a product team, running your regular product meeting is one of your most important responsibilities. The way you run these meetings will go a long way, it will define the culture of your team.

The topics you discuss will tell your team what’s important, and people will naturally pay more attention to those things. The way you discuss different topics will set the tone about how people will work together and solve problems when you are not there.

Run great product meetings and your culture will thrive.

Advice from the legendary Bill Campbell

Bill Campbell was a legendary coach who worked with some of the biggest product leaders in the tech industry. He coached people like Google CEO Eric Schmidt. 

In the book Billion Dollar Coach, his coachees pay tribute to him by sharing their experience working with Bill. I was super excited to read this book, as it gives you a little look inside how these great teams work.

The biggest surprise reading this book was how much attention Bill paid to seemingly mundane details like running a meeting. He often visited the meetings run by these super-powerful tech executives and spent time making sure they become better at running them.

“To Bill, being an executive of a successful company is all about management, about creating operational excellence. … You have to think about how you’re going to run a meeting — he told a group of Googlers in management. … So when we met Bill in our weekly coaching sessions, his first coaching questions were related to management: operations and tactics…. What were the current crises? How quickly were we going to manage our way out of them? How was hiring going? How were we developing our teams? How were our staff meetings going? Were we getting input from everyone? What was being said, what wasn’t being said? He cared that the company was well run, and that we were improving as managers.”

It was the Bill Campbell book that inspired me to start tweaking our product team’s meeting structure. I tried out many things until I found what works best for us.

In this blogpost I will share how we run product meetings at UXfolio. We are a team of a designer, two developers, a marketer and me as a product manager. It is a cross-functional product team responsible for one single product together.

What I share here is not suitable for everyone and I strongly encourage you to experiment and come up with what works best for you, instead of copying everything blindly. I hope this piece will give you some inspiration.

Check-in: my favorite social flavor 

Like it or not, meetings are social gatherings. Obviously, we don’t like to have too many meetings, and we hate it when they last waaaay too long, but we need them not just to sort out operational issues, but to build social connections.

Great leaders usually keep a tight schedule during product meetings, so the best social moments usually happen organically before or after the official meeting time. That doesn’t mean you can’t spend a great 5-10 minutes of your meeting to socialize.

The best time to do that is at the beginning, as it will set a friendly mood, and help everyone to arrive.

We have our product meetings on Monday and we start these meetings with a round of weekend fun facts. We go around one by one and everyone shares a fun fact about their weekend. This helps us to get to know each other better, and we often laugh a lot during this part of the meeting.

With our leadership team of UX studio, we meet every Wednesday, so I modified this question to “What was the best thing that happened to you since last Wednesday?”. To this question, people can share work-related and personal stories as well, and we frequently hear examples of both.

I heard from other leaders who ask their team what was the biggest win as check-in and with this question, they provide a well-earned brag time for everyone. For me, it’s a bit too much about performance, but I can imagine it works well in certain teams, where it’s more difficult to get people talking about their personal life.

Don’t waste time with reporting and task management

Many people imagine meetings as an occasion to share progress and discuss tasks. Everyone should tell what they did and discuss what to do next. I couldn’t disagree more with this structure.

I think the precious meeting time should be kept for things you can do online asynchronously. I want to spend time with deep discussions about the most important topics, and not with listening to someone’s todo list from last week.

To avoid reporting during the meetings we do it on Slack. Everyone should send a short list to our common channel a few hours before the meeting.

The structure:

• What did you do last week?
• What do you plan to do this week?
• Topics you want to discuss with the team

Before the meeting we read these short reports so everyone arrives prepared and we know what’s going on. During the meeting we only go through the topics people suggested. We have more time for topic discussions, as we don’t spend time with reporting and task management.

It’s super important that any team member can suggest topics to discuss, so in a product meeting many things come up from engineering topics to design and marketing. People are actively encouraged to bring up topics on product meetings.

Just because we don’t do task discussions on product meetings, that doesn’t mean we don’t talk about our progress or what’s next. We actually talk a lot about progress and next steps, but when we talk about progress we talk about team or product progress, and not individual progress. When we talk about what to do next we talk about product roadmaps and not individual team member’s tasks. Once we have a clear roadmap of the bigger features we want to build it’s up to each team member to figure out what they need to do to make that happen.

Highlighted recurring topics

Besides the topics team members bring, we have a few recurring topics we go through every week:

• Design of upcoming features: the designer walks us through the screens of the features she is designing and we discuss them. It’s great for the designer to get feedback and it ensures everyone sees the new designs as they evolve and not just the final version. These discussions ensure developers know why the new features are designed in a certain way.
• User test highlights: although our designers send detailed reports about the weekly user tests to our Slack channel, I think it’s super important, so they also sum it up in 1-2 minutes at our weekly product meeting. Many times it happens together with the design walk-through, so we can discuss the design and the user feedback at once.
• Usage numbers and user generated content: if we recently released a feature our designer shows us some numbers about the usage and some screenshots about the content users created with the new features. This helps the team to iterate and learn together what worked and what did not.
• Support summary: the support person of last week sums up the most frequent support requests.
• Roadmap: during all these discussions many ideas come up about what to build or change in the product. We keep track of them and at the end we review together the roadmap and decide on what to do and how to prioritize things. As a young startup product we usually have only short roadmaps fixed for the upcoming few weeks and it is reviewed every week.
• Housekeeping: at the end of the meeting we have a few recurring housekeeping topics to quickly discuss, like who will be the support person that week (yepp, we all do support time-to-time), who will attend a user test (an other thing we all do), and what will our team report to the rest of the company.

I use these recurring topics to shape the team culture, as all the team members have to participate in these discussions weekly and talk about customer insights, new designs and setting priorities. I’m super proud that these are the topics we talk about the most.

Other teams might have other culture-defining topics (a team building an API probably doesn’t want to look at UI designs that often), but it’s always useful for team leads to figure out what they want their people to talk about the most.

These recurring topics also help me to lead with context. Seeing as the new designs is born week-by-week help engineers to know why we do certain things. Getting regular updates about user tests, support requests and user generated content helps everyone in the team to emphasize with our customers. Prioritizing together also helps to make sure everyone understands what’s important and why.

Engagement boosters

I like to work in teams where people are really engaged (who doesn’t?) and I use a lot of little tactics to make this happen.

As you can see people can suggest topics, and we use most of the time on each meeting to discuss those. We also set priorities together so everyone has a seat at the table, they can have a word when we make important decisions.

Even though I’m responsible for the meeting and its structure and I attend all our meetings, I don’t run any of them. We go around and every week someone else is running the product meeting. This helps me to turn everyone into the “owners” of the meeting and feel more responsible for everything we do.

An example: our product meeting agenda

We have a doc with the general structure of our meetings which people can use as a guideline when it’s their turn to run the meeting. Here is a short summary of that doc.

• Check-in: weekend fun facts (5 mins)
• Design summary and discussion: show and discuss new designs, share user test highlights, show user generated content or analytics numbers (30 mins)
• Topics suggested by team members (30 mins)
• Roadmap (10 mins)
• Housekeeping (5 mins)

Cadence and length

We have a product meeting each week, and it usually lasts for one and a half hours.

I know, it’s long.

It’s just not long enough to break it into two, and it contains only important discussions. As I said I like our product meetings to be a place for deep discussions, and that needs time.

The length of our product meeting depends on the difficulty of the things we work on. When we have a hard problem to solve sometimes it lasts longer, when everything is simple and easy we usually finish the meeting in about an hour.

It also helps that we have been doing this meeting structure for a long time now and everyone knows how to do it well. If you would add all these topics to your agenda it would last way more than 90 mins for you, so if you start tweaking your meetings, I would advise to change one thing at a time. 

Obviously many of our challenges are not solved during one single meeting, so you can imagine that we have topics we come back to week after week. This helps to keep the meetings short, as we just have to discuss the next steps and everyone knows the context already.

I can imagine there are teams who don’t need a weekly meeting. In bigger corporations where things move slowly it might be enough to have a product meeting every other week.

Summary

So to sum it up in 3 points:

• Use your meetings for important discussions
• Use recurring topics to shape team culture
• Make sure everyone is engaged with letting people set the agenda, run the meeting and make decisions together

Meetings seem to be mundane and easy, but they can have a huge impact if you use them well. I hope this piece was useful and you got some tips you can try with your own team.