If you want to know what the culture is like in a product team, you should visit one of their product meetings.
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.
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.
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.
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:
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.
Besides the topics team members bring, we have a few recurring topics we go through every week:
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.
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.
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.
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.
So to sum it up in 3 points:
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.
It's hard to find any product designers nowadays who don't use or at least don't…
As we step into 2024, the significance of investing in user experience (UX) and user…
Are you interested in how eye-tracking in UX research can be leveraged to gather reliable…
In this episode, we have a conversation with Sándor Zelenka and Benedek Göbölös as they…
Current generative AI tools can come up with videos and images within minutes. We still…
Even if you are far from being a football fan, I’m sure you’ve heard of…