At previous places Arnau Giró and I have worked as Product Designers and Managers, there have been a number of different team-related meetings. They are really helpful for disseminating information across the team. Whether you all work in the same building or different countries around the world. They’re also great for team morale, as you have a chance to catch up with the wider team.
At AZA Finance this is no different. We mainly work across Africa, Europe and the UK. Apart from the obvious logistical problems this creates, we’ve also found issues with time zones and occasional personality clashes due to differing expectations. Having regular product team meetings has helped to dispel a lot of these issues, as it gives us a chance to reflect and improve as a team. In this post, we’ll go through different types of meetings to benefit your overall product strategy.
Read Product dynamics, explained
Scrum retrospectives
Like many other companies, we use the scrum framework. This in itself gives the team the chance to have retrospectives. Allowing the team some time every sprint to look back and assess. If this isn’t something you’re doing in your teams, I would seriously think about starting. This regular time to reflect is great at weaning out issues, allowing the whole team to talk and then continually improve their process.
To facilitate this we run some gatherings on top of the regular scrum ceremonies. This gives us regular, protected time to do work on ourselves as a team. We’ve also found carving out this time on a regular basis means we can work on larger problems over a number of sessions. It also gives the whole team numerous platforms to bring ideas and problems to light. The following team gatherings are what we’ve found helped to foster these behaviours:
Monthly product team meeting (Product pints)
We regularly hold a meeting we call Product Pints. We run this with the whole Product and Product Design teams (PAD). This is a two-hour monthly gathering, where we discuss:
- Upcoming product work, what large projects are coming up and what you need to know about them.
- Previous work we’ve completed and its successes/failures. A chance to look back at successes and shortcomings.
- Processes we’ve recently learned or tried out that have worked well or haven’t gone as expected and why.
This gives us the opportunity to share work across our distinct teams. Meaning that any learnings we’ve made get shared amongst the whole Product team. This is great for removing silos of knowledge as information is disseminated across the wider group.
Fortnightly roles specific meeting (Product half-pints)
We also run shorter, smaller meetings in our functional teams. These are up to 15 minutes and usually have a presentation/prototype that discusses a particular product or area. We’ve used this in the past to:
- Discuss new techniques and processes we’ve been using. For example, we’ve shared any updates that have happened with Figma and Figjam. We’ve also used it to showcase different whiteboard sessions in Miro.
- We’ve also used this to showcase studies and present new components in our design system to the wider team. This way everyone is aware of new developments and the relevant use cases.
These are great for keeping the team aligned. As we’re all working on different objectives and need to retain consistency across our work.
Product shorts/shots
These aren’t often meetings, they might form part of one occasionally. Usually, these will be shared over Slack for a quick hit of knowledge. How we’ve used these in the past:
- Sharing prototypes to show functionality, a new pattern or part of a journey. With the team being in different time zones this allows us to catch up asynchronously. It also helps try out new ideas before they go to the wider organisation or customers for testing.
- Quicktime videos to show how motion might work with a component. This is much easier than trying to explain it and can be shared with engineers during refinement to get accurate estimations.
- Gyazo (screen capture software) to show micro-interactions at work. We tend to use this when referencing an interaction from another site. So mainly used during research to share multiple ways of achieving a goal.
Cross-functional guild meetings
You will probably be aware of guild meetings from companies like Spotify. They are cross-functional teams that work towards a common goal. We’ve put them to good use as weekly meetings for our design system, Mint (think currency press rather than herb). This meeting has a number of regulars from Design, Product, Engineering and QA. The advantages of these meetings are:
- Engineers and QA get early eyes on any design work that’s happening. So when it comes to refinement, this isn’t the first time something has been seen. This cuts down on questions, rework and the time taken to refine each component.
- It also gives these teams earlier opportunities to suggest improvements or seek further clarification on how something will work.
- The teams work together much more closely together. As they have regular meetings and get to know each other properly, this opens up the lines of communication so things aren’t happening in silos.
Read A case study: Cross-departmental communication as a product
An extra: “working with me” document
An idea that came from the Monzo team via Linkedin. This dovetailed nicely with a practice our HR team implemented. When anyone starts at AZA Finance, we ask them to fill out questionnaires on Crystal Knows (a suite of products for personality insights). This gives us a good idea of what they are like and how best to work with them. The “working with me” document helped expand on this:
What I’m good at
- What does this person see as their strengths?
- What work do they enjoy doing?
- What traits in others help them do their best work?
What I’m not good at
- What does this person see as their weaknesses?
- What work don’t they enjoy doing?
- What traits in others stop them from being able to do their best work?
How to work with me
- What are the best ways to work with this individual?
- What ways make it difficult for this person to do their best work?
- How do they prefer to work?
Initially, we created these in the Design team to better understand a new starter and in turn, give them understanding about us. However, on showing them to other teams, they were implemented across the wider Product and Engineering teams. My experience with them has been very positive, they’re a great way to break the ice with new team members.
Read Olivers’ and Arnaus’ previous article on Mind the Product: Scaling product and design teams is not just about hiring
Applying these ideas to your team
Firstly it’s worth saying this isn’t a definitive list. Also, some of the things that have worked well for us might not work as well for you.
So some bits of advice to end on:
- Test and learn. I mentioned this earlier about doing retrospectives, be sure to check-in and find what is working for the team and what isn’t.
- Gather opinions on what the team would like to do. The whole point of these gatherings is to increase team collaboration. Get them involved in the process. Ask for feedback and don’t be afraid to try out new ideas.
- Don’t be afraid to stop things that don’t work. Just because you’ve started doing something doesn’t mean you’re destined to continue. If you find something isn’t valuable, try something else or kill it altogether. Not everything works and that is alright.
I’d love to hear about what you’ve tried in your current or previous roles. What gatherings have you found work? What have you thought was a great idea and didn’t work out?
Discover more content on collaboration.
Comments 0