4 Meetings to Master as a Product Manager
How to excel in the meetings you dread the most
Monday morning meetings, recurring 1-1 meetings, team meetings and weekly company all hands. You might sometimes feel like you’d rather disappear into a black hole for a few months than spend a single additional minute of your time on the planet in meetings, but the unfortunate truth is that meetings are a necessary part of getting things done in product teams. So it’s probably a good idea, then, to invest some time in conducting meetings effectively so that you can ultimately spend less time in them.
Here’s a little guide we’ve put together to help you to optimize the meetings product teams have the most. Each meeting guide has a bunch of resources included which we hope you’ll find useful.
The meetings we dread the most
If you’re anything like the product folks I know, it’s likely that your calendar looks something like this, with a diary packed full of meetings with various stakeholders, team members and third parties:
Whilst there are a number of different meetings we have to deal with on a day to day basis, some meetings tend to be more stressful than others. Here’s a selection of some of the meetings you probably look forward to least:
Before we dig deep into each of these, let’s get explore a few bits and pieces.
Guiding principles
“How can you achieve your 10 year plan in the next 6 months?” – Peter Thiel
Here are some guiding principles to follow which can be applied across all types of meetings, not just the most difficult or common ones:
- Introduce timebox mechanics – Mr Peter Thiel suggests you practice asking yourself the blunt question “how can you achieve your 10 year plan in the next 6 months?’. Apply this to your meeting etiquette and force yourself to trim your meetings down to the most essential components within an aggressive time frame. Google’s browser timer is a quick, practical way to introduce a timebox mechanic to your meetings.
- Be disciplined – how many times have you arrived at a meeting someone else invited you to, only to discover that nobody has bothered to come prepared, including the person who invited you? Be disciplined and come prepared – particularly for your own meetings!
- Agree actions and outcomes – have you ever left a meeting and thought to yourself ‘so… what did we actually agree to in that meeting’? This often happens when there’s a difficult decision to be made and nobody wants to make it. Aim to agree on the outcome of a meeting – even if the outcome is that you haven’t yet reached full agreement.
3 Unconventional persuasion tools and tactics
Perhaps one of the most difficult types of meetings are the ones where you know beforehand that you and someone else completely disagree on a particular problem, solution or decision. You know you disagree because you may have had an email exchange beforehand or a disagreement in a prior meeting. In fact, you’ve called this meeting to resolve your disagreement.
In these situations and indeed other meetings, it helps to arm yourself with a couple of powerful, practical persuasion tools and tactics so that you can influence the other person.
Here’s some unconventional ways to persuade people in your meetings:
- Attention hijacking – introducing a change in environmental circumstances hijacks human attention and acts as a jolt which can make your message more persuasive. Try having your meeting in a completely different environment out of the office, presenting information via an unexpected medium (whiteboard only vs. powerpoint) or using concepts from completely unrelated and unexpected industries to jolt your attendees attention.
- Shared birthdays – merely creating a positive association with someone’s birthday can help you to get them on side. If you’re presenting to a team and 1 person is the decision maker, try searching your internal HR systems for their birthday and using that strategically in your presentation. For example, if you’re presenting mockups, you might include the birthday as your example in the mockup.
- Implicit egoism – Coca Cola produced 100 million cans of coke in the UK with your name written on it for a reason. And the reason is known as ‘implicit egoism’ where your ego takes control over your decision making. This can work in your favour if you’re aware of it. One way to do this in a meetings context is to personalise your materials to your audience by carefully using the name of the attendee(s) you want to influence. For example, if you’ve put together a deck, including the other person’s name on the opening slide next to yours will work in your favour. A simple line such as ‘Prepared by [Your name] for [Their name]’ will do the trick.
Yes, I know, some of those do seem a little machiavellian and borderline evil, but they are fun concepts to know about nonetheless.
By now you’re probably thinking, ‘OK, that’s enough of the waffle, where are these meetings?’. Fair enough. Let’s dive in.
Podcast
Product Stacks Podcast by the Department of Product. A deep dive into the tools, frameworks and processes used by product managers from top companies.
Meeting 1 – Stakeholder Requirements Gathering
We talk of users being paramount and the importance of being user-centric, however, it’s easy to forget that in some companies – particularly larger corporates – product teams are responsible not only for delivering an exceptional experience to external users, but also to support the needs of internal users of products.
Product managers and product teams more broadly, play an important role in the value chain; defining and delivering value to the end users. However, an essential part of value delivery, in larger companies in particular, is in building the tools that underpin the supporting activities of the value chain:
- Reporting tools for sales teams
- Backend admin systems for content management
- Internal analytics tools for marketers
These unsexy parts of product management are largely downplayed or ignored by the mainstream product industry since they’re simply not as exciting as the latest features you might be working on for your end-users. Who wants to hear about a new reporting dashboard for a corporate finance team when Snapchat is working on a new pair of glasses? Not me.
As unsexy as they may be, these tools for supporting activities are still a major part of the product management role.
The allure of unsexy products
Whilst discovering and defining requirements for consumers typically involves experimentation and testing strategic hypotheses until you find product market fit, in the context of internal products, your users are often sat in the same building. It’s a common task, then, for internal-facing product folks to host requirements gathering sessions with stakeholders to uncover product requirements. This can be fun and rewarding, particularly if you’re an extreme empath, since you’ll get to see the impact of your products in real time and not through the filter of user feedback sessions and comments on forums. I often find that building products to support dull, unsexy business activities is a strangely satisfying experience. Or maybe that’s just me.
Here’s a few guidelines on how to run effective requirements gathering sessions with your internal stakeholders when developing your internal products.
Objectives
- Problem identification – what problems are your stakeholders facing today and what might they face tomorrow?
- Context – why is this problem important?
- Solutions – what might a solution for this problem look like?
Problem identification
Stakeholder requirements gathering sessions can often start with solutions. In fact, the meeting itself might be named as the proposed solution. So for example, you may find yourself invited to a ‘Marketing Intelligence Platform’ meeting or a ‘Sales Report Dashboard’ meeting, which assumes that the solution is to build a marketing intelligence platform or reporting dashboard before you fully understand the nature of the problems and opportunities available to you.
Try to keep your requirements gathering meeting names broad enough to avoid jumping to a solution – at least in the early stages. Try ‘Product and [DepartmentName] – Requirements Session’ or something similarly objective to avoid any upfront bias.
The best way to understand a problem is to see an example of it first hand. This may mean paying a visit to your call centre, your data analysis team or whoever the stakeholders impacted are. Spending just an hour with the team in their environment can be an invaluable experience since problems are far more real when you see them in real life.
In your requirements gathering meeting, ask your stakeholders to list the problems they are trying to solve by building the feature they have requested. Your stakeholders will want to jump straight into solutions, but always try to bring everyone’s focus back to the problems and challenges.
How to understand stakeholder problems deeply
- Step 1 – ask your stakeholders perform a review of the relevant problems faced by a particular team or part of the business. This typically involves writing the problems on separate pieces of paper or post it notes.
- Step 2 – ensure you fully understand the problem. To do this, repeat back the problem to your stakeholders and explain it to them as you would to a child (note: we’re not suggesting your stakeholders are children, but rather than explaining things simply demonstrates a deeper level of understanding!). Encourage your stakeholders to draw the problems faced on a whiteboard if you’re struggling to grapple with it.
- Step 3 – group the problems thematically. If the problems listed span across multiple different parts of the business, group them together thematically so that everyone can visibly see how the problems relate to each other.
Digging deep into the problems generated by your stakeholders will give you a shared, deeper understanding of the problems so that you can start to contextualise them.
Problem contexualisation
Contextualisation involves taking your problems and processing them through multiple filters so that you can start to decide which problems are the ones you might want to focus on:
How to make sense of all your problems
- Goal filter – what problem, if solved, helps the team and / or the business achieve its goals? For example, if your goal is to increase your NPS and your customer service team are asking for an NPS automation tool which sends text messages, this directly links back to your NPS goal. If a problem has no impact on any goal, consider carefully the benefits of solving it.
- Revenue filter – is the problem having a material impact on revenues? Are you losing money as a result of this problem not being solved? Ask yourself and your stakeholders to question whether there is a direct – or indirect – impact on revenue by solving or not solving the problem.
- Customer filter – what impact, if any does this problem have on the customer?
- Future filter – is this problem likely to be a problem in a year’s time? Travelling into the future can be a useful tool when assessing problems. For example, if your customer service would like to invest product effort in upgrading their call centre phone systems, consider whether your call centre telephones are likely to be replaced by live chat and powerful CRMs in the future.
- Metrics filter – which metrics best communicate this problem? If you are to build solutions you’ll need to agree on a metric which represents the problem today and the metric to measure your solutions by.
Filtering involves practicing the rare ability to zoom out of the details and to take a wider look at the overall business. You might struggle to do this at first, but zooming is an essential part product. Encourage your stakeholders to think in a similar way.
With your problems filtered, you’ll end up with a list of problems which need solving. It’s at this point that you can start to finally move onto the moment everyone’s been itching to get to…
Potential solutions
We are wired to prefer jumping to solutions. Now is your chance to ideate your way to potential solutions for the problems you’ve uncovered. What you’ll often find is that if you have a deep enough understanding of the problems, your solutions will likely be different – and seemingly more creative – than what you may have originally had in mind.
Use a problem / solution diagramming tool to make it explicitly clear how your solutions might solve the problems. 1 solution may solve 1 problem or multiple problems.
How to agree the scope of your MVP solutions
Ultimately, you don’t know if your solution is in fact a solution, until you ship it and see how it gets used. De-scoping your solution and distilling it into an MVP allows you to reduce the risk of shipping something nobody wants. This means agreeing with your stakeholders what the scope of the first version of the product will be. This can often be a difficult discussion to have.
Start by analysing the proposed solutions by considering technical complexity vs. impact where impact is shifting the needle on the metrics you identified during problem contextualising. Technical complexity can be kept to T shirt sizes at this stage so that you have a rough idea of the work involved.
Teresa Torres, a leading product thinker, suggests using a neat tool called an opportunity tree to prioritise your potential solutions and here’s a little video which explains this concept in more detail:
Agreeing the scope of your MVP will also involve communicating to your stakeholders what has been agreed and here’s a few way to do that:
Tables
2 columned, simple tables outlining what’s coming up in the MVP and what may or may not come at a later date:
Annotated mockups
If you’re releasing a solution in stages, as you iterate and incorporate feedback, using a mockup to clearly articulate this can often help. Tools like Invision allow you to easily add interactive annotations so that your stakeholders are clear on what is and what is not included in the first version of your product.
Useful resources
- Product development models – a selection of the most useful product development models
- Value proposition canvas – analysing value propositions by Strategyzer
- Opportunity tree – Teresa Torres’ solution for identifying and prioritising opportunities and solutions
- Invision – useful for communicating wireframes and the scope of solutions
Meeting 2 – Planning
If you’re working in 2 weekly sprints or some other form of scrum team set up it’s likely that you’ll need a planning session with your team. Planning can be a tricky meeting, especially if you’re a product manager who has just joined a new team as the engineering team will look at you for answers to often complex problems.
Preparation before planning is key. Yes, you’re drowning in 23 other things on a Tuesday afternoon but this needs to be a priority. Aim to cover as much ground as possible before your planning session so that you can have a crack at anticipating potential questions that are likely to get raised, but don’t give yourself a hard time if you don’t know the answer to a specific question on the spot. If you’re not sure, rather than giving an answer you’ve just made up to avoid looking foolish, be honest and say you’ll look into it instead. It’ll be easier for everyone in the long run.
The objectives of planning
If you’ve ever missed a planning session you’ll start to feel it. It feels a lot like eating bad food or being sat on the sofa scrolling through Instagram Stories for 3 hours; you’ll start to feel a little lethargic, miserable and lacking in focus. A planning session helps you and your team to get yourself back on track.
- Goal setting – set the goals for the upcoming development period so that the team understand what exactly it is you’re aiming to achieve.
- Focus – keep your development teams focused and aligned. Missing 2 planning sessions in a row is the quickest way to introduce unfocused lethargy into a team.
- Big picture – use your planning sessions to express how the work on the short term is helping to achieve your strategic goals in the bigger picture. Link the work explicitly back to the overall goals.
- Clarify ambiguity – ideally, you’ll have had a separate backlog grooming session prior to your planning session, which gives you and the team the opportunity to clarify questions ahead of time. However, backlog grooming and planning can often happen at the same time if you’re pushed for time. Try your best to eliminate as much known ambiguity before planning so that everyone is clear about what you’re looking to build but also be comfortable with knowing that ambiguity is an essential part of the process and that unknown things will pop up during planning which may need to be revisited separately.
Product strategy overview
At the start of the session, re-engage with your overall product strategy. If you’re using the OKR framework, revisit your most important Key Results and re-assess how you’re tracking against those goals. Planning is a time when you’ll get stuck into the details of specific user stories, yes, however, those stories can appear irrelevant without the broader context of why you’re building them in the first place. Try labelling stories with the relevant OKRs to link them specifically back to the key result they relate to.
If you have any relevant feedback from the business, users or anyone else that might add a little flavour to your strategic goals, share them with a team. As sexy as OKRs are, humans do and always will, prefer stories, so if you have any stories of interest that may have been shared with you but not your engineering team, share the love with the rest of the team too.
User stories / requirements
If you’re lucky enough to have a business analyst on your team, user stories and BDD scenarios may be written by them or they might be written by you.
How much detail should you include on user stories?
Adding too much detail to user stories can have the paradoxical effect of making the development team less engaged and obsessive over the wrong things.
In teams where the requirements are fleshed out in every last detail, the team expects the story to do the thinking for them, absolving them of any duty to think for themselves. Adding too little detail, on the other hand, can lead to rambling conversations which descend into chaos.
Try your best to strike a balance between adding enough details on your user stories so that your engineers get the gist of what you’re trying to do and not overburdening the team with such detailed specs that any deeper thinking is outsourced to the product manager.
Q&A
Give your team time to clarify anything which needs clarifying. Try and keep the Q&A focused on the specifics of your planning session; what it is you’re looking to achieve (user stories) and why (product strategies).
Useful resources
- Sample planning meeting deck – an example of a deck with diagrams you might find useful to use in your meeting
- Strategy / OKR Trello template – a trello board for measuring your OKRs / assessing your strategy, particularly useful if you need to share it with remote teams or stakeholders
Meeting 3 – Retrospectives
The retrospective is a chance for everyone to have a good old fashioned whinge.
It’s group therapy with benefits. The benefits mostly being that as a result of the problems surfaced during your retros you’re more likely to improve over time. Sounds wonderful.
However, you’re only likely to improve if you have both the willingness and governance to actually implement your own recommended improvements. Without implementing your suggested improvements and continually measuring your performance, retros are mostly a tool for spewing out pent-up emotion. Fun in the moment but fruitless in the long run.
Objectives
The retro is designed to focus the team on a few key objectives:
- Problem identification – what problems are you facing as a team? Ask the ‘5 whys’ to uncover the root causes of these problems.
- Problem solution ideation – in what specific, creative ways could you potentially these problems?
- Performance measurement – how will you measure whether your solutions are working? The difference between your anticipated outcomes and your actual achievements since your last retro work as a good gauge for overall performance measurement.
Recap on last retro
If you’re having retros with a regular cadence, you’ll have things to catch up with since you’re last retrospective. Revisit your agreed action steps from your last meeting and spend a few minutes understanding what has and has not been achieved. Some action items might be things you set out to achieve before this retro whilst others might take longer than just a week or so.
If an action item hasn’t been completed, try to understand why. If it still needs to be completed, leave it in place until the next retro. If something has changed and it’s no longer relevant, bin it.
What’s going well
For co-located teams, use post it notes to list the things which are going well. For remote teams, use a Trello board template or something similar. Whilst it’s easy to be cynical about focusing on the good stuff, it can often be all too easy to focus on all the stuff that’s going wrong at any given moment. Forcing yourself and your team to focus on the positive things that have been achieved over the past few weeks will make you feel good, and give you all an (albeit temporary) boost of morale before the next challenge.
What’s not going well
Equally important and what often forms the crux of retros is to uncover what is not going so well and why.
Traditionally the sequence of a retro suggests to start with what’s going well and to then subsequently dive into what’s not going well. There’s a good reason for this: by focusing on the items which need work you can leave the meeting with a pile of actions. This clearly demonstrates that something will be done before the next retro to tackle the problems raised. However, there’s a also second, less-desired byproduct of this approach and that is that people will leave the meeting feeling like poo.
Actions
Finally, put together a list of agreed actions. These may be things you commit to completing before the next retro or they may be things which require further investigation / development over time. Be explicit about why you’re committing to the action in the first place. The action should link clearly back to an objective or an improvement that you’ve identified that can be made in your process.
If possible, quantify the improvement you’re looking to make and measure this over time.
Useful Resources
- Trello board for retrospectives – a digital version of the retrospective, used for remote teams, when you can’t all be in the same building
Meeting 4 – Product Demos
Few things strike fear into the heart of a PM more than an impending product demo. Product demos are an excellent opportunity to show off all of the delightful things you and the team have been building over the past few weeks and are an essential part of building a sense of shared purpose. However, often times at the end of your demo you’re either met with blank stares of apathy or a series of difficult questions:
- So how does the user do X?
- Right… so we’re not building X?
- Where’s X feature? In a later version? *eye roll*
Product management can often be a thankless role. Your stakeholders shuffle off to their next meeting and you spend a few minutes dismantling the apparatus you set up for the demo.
One option at this point is to jump out of the nearest window. Another is to commit to giving more engaging product demos in the future.
Here’s a few suggestions on how to do just that.
Objectives
- Engage – the primary purpose of your demo is to engage your audience and to make them genuinely interested in what you’re demoing. Sure, this can be difficult if you’re demoing changes to your API documentation but that may be your fault for choosing to demo something so banal or not bringing it to life in an engaging way. More on this later.
- Inform – your stakeholders will wonder if the ping pong team – as the product / engineering team are often affectionately known – actually do anything. This is your chance to demo exactly what you’ve been up to and the direct impact you’re having on the business.
- Morale boost – even if the response from stakeholders isn’t one of joyous delight, the process of working on a demo with your team will give you a much-needed boost of morale.
Little tip: always prepare a recorded version of your product demo to avoid any embarrassing mishaps. Occasionally, if you’re demoing freshly released software, you’ll run into production / pre-production issues which means the thing you’re demoing no longer works. Prepare for these kinds of scenarios by pre-recording your product demo ahead of time so that you have a backup if things go wrong.
The context
Give the audience a little bit of context before you dive into the product demo. Try to avoid explaining every single aspect of what you’ve been working on over the past 2 weeks and instead aim to give your audience a peppering of what has led you to this point.
Use creative techniques such as mystery and storytelling to your maximise audience engagement (see below for more guidance on this). Some contextual tidbits of info you could include in your product demo are:
- The problem you’re solving
- The metric you’re trying to shift
- The reason you’re building it (the why)
- How this solutions compares with the older version of your solution
- How your existing solution compares with your competitors
- How your new solution compares with your competitors
The demos
The demos should be concise, snappy and where appropriate, focused on the user’s perspective i.e. what the user sees (unless this is a technical demo for a technical audience where the primary focus is on the technology).
Get your team involved in the demo process, including UX / engineering. This may be a little nerve wracking for some of the less experienced or shy members of the team but you can interject to help things move along the way.
Keep your demos limited to 1 or 2 features, with 10 minutes for each. If your demo is part of a larger meeting – a weekly all hands or something similar – then shorten your demo length accordingly.
5 creative ways to make your demos more engaging
- Use mystery – mystery deepens curiosity and keeps your audience suspended in a state of awareness. Presenting a mystery at the start of your presentation opens a mental loop which your audience will feel compelled to close. Studies show that if you start a presentation or a talk by presenting a problem or a mystery which needs to be resolved and you leave the question unanswered until the last minute, your audience are more likely to be engaged throughout since they’re desperate to close the loop you opened by presenting the problem or mystery at the beginning.
- Tell stories – ‘users’ means nothing. Jane from Ohio and Ted from Manchester means something. Bring your user’s problems to life by telling stories about them as people and who they are. If you have any usability test data, share it – but do so on an individual user basis so that a human is shown to be directly impacted by what you’re demoing.
- Music – as your audience wait for the demo, playing some uplifting music can wake people up and create a positive association with you and your team. Aretha Franklyn’s version of Rolling in the Deep might be a good place to start.
- Lighting – try dimming / switching the lights off when you’re presenting your demo. This will make your audience feel as though they’re about to watch a show or a movie which will have the strange effect of making them more engaged. Note that this only seems to work for a short period of time. Any longer than 15 mins or so may send people off to sleep.
- Interactivity – incorporating elements of interactivity can help keep your audience engaged. Try using tools like Kahoot to add a little interactivity. Start your demo with a little quiz, asking your audience questions relating to the context such as ‘How many people use mobile on landing page X’ or ‘What % of our users use Chrome?’. You can then present your demo by answering these questions and addressing how your solutions answer these questions.
Questions on a postcard
You may be surprised to find a formal Q&A omitted from this suggested demo list. The truth is it isn’t omitted, just modified slightly. Rather than taking direct questions in front of everyone, tell your audience that if they have any questions relating to anything regarding what you’ve demoed they can either speak to you immediately after the meeting or that they can drop you a note with some thoughts on.
Stakeholder feedback is important but an open forum is not necessarily the best place to get into the intricacies of whether your user flow is likely to remove enough friction to increase conversion by 5%. Having a separate, deep discussion will allow you the necessary time to articulate your thoughts clearly and deeply, which is far better than giving sub optimal answers to questions in a rushed format whilst everyone else is staring the clock and wondering whether they can go home now.
Resources
- Kahoot – fun tool for adding interactivity
- Screenflow – nifty tool for pre-recording your demos
- Your demo sucks because it’s focused on your product – alternative perspectives on giving product demos
Product launches, news and analysis delivered to your inbox. Weekly.
