Check out a free preview of the full Complete Intro to Product Management course

The "Meetings Overview" Lesson is part of the full, Complete Intro to Product Management course featured in this preview video. Here's what you'd learn in this lesson:

Brian introduces a few fundamental principles for successful meetings. For example, understanding who is in the room and the context required to communicate the desired message.


Transcript from the "Meetings Overview" Lesson

>> So, we've already talked about technical communication. We've talked about how to apply technical communication principles to technical writing. And now we're gonna apply those kinda same sort of principles to how to hold a good meeting. Now, I'm not gonna talk too much about how to be a good participant in a meeting.

I'm gonna hope that most of you can kind of intuit what to do there, right? Participate, don't dominate the meeting when it's not your meeting. It's helpful for you to go into a meeting with a goal of what you want out of a meeting. The other small piece of advice I'll give you is.

If you're attending a recurring meeting, and it's not something helpful to you, find a way to stop attending that recurring meeting. There's a certain amount of, I don't know, internal pressure, at least for me, to attend every meeting and to want to be in every meeting. And it's because it feels productive to have like a full calendar of meetings.

I love that PMs love to show each other their calendars, like look how busy I am, and I was like, neat, I don't care, [LAUGH], right? It's a humble brag but in reality is like you probably are just not managing your calendar well enough if you're going to that many meetings.

There's no way all of those are useful. So, that's my advice for you, it's maybe consider cutting down on your recurring meetings. I have one of my co-workers that says that I have no recurring one-on-ones. They're all totally ad hoc scheduled when we have something to talk about.

And, to his credit, he actually does schedule a lot of one on ones, but he has nothing recurring on his calendar. And I was like, that's kind of an interesting idea, I don't know if I have the discipline to maintain that. But, anyway, so that's kinda my spiel.

Go to meetings that you find useful, schedule meetings that are useful, and cancel meetings that are not useful. So, most of the rest of this section is going to be about how to run a good meeting. Because I think that's actually the more unique skillset to keep in here.

So, let's talk about some previously-learned principles that we learned previously, I said that. Maybe, say it again, previously, [LAUGH], and apply them to meetings. So, the first one is people, people, people, right? Audience, and, in this case, it is who is in the room. I think there's a strong temptation to like reuse slide decks, there's a strong temptation to reuse old rhetoric.

But it's always good to cater your message to whoever is listening to it. And it's also look around with who's engaged with the meeting, right? Cause you're gonna get a bunch of people that just attend every meeting on their calendar. They're going to be on their phone, they're gonna be doing other things.

And if they're not paying attention to you, don't cater the meeting to them or make sure that they're paying attention, right? Whatever that is. Yeah, and if someone's not paying attention to you, it might be a context clue that maybe you're not talking about the thing that they want to be talking about.

So, whatever you can do to wrangle guests or whoever's in your meeting towards the goal that you're trying to get to, do that. The right amount of context, it's the same thing here. At the beginning of meetings, all of us like to set up a lot of context, and I'm just gonna say, say less here, right?

To say only the amount that you need to get to your point, unbury the lead. In this particular case, you can do executive summaries at the beginning of your meetings. And just say, hey everyone, for context this is our point, that's good, now let's dive into the point, that's an effective strategy.

If you can't do that, just try and get through the context fast enough, so that you keep people's attention for as long as you can. But meeting goals are always a good idea. I said this previously, prepare for 100% to say 5%, this is extra applies to meetings, as opposed to documents.

So, you certainly don't want to say everything that you've learned in a meeting. You'll spend the entire meeting just talking about who you talk to when. Don't do that, that's not very useful. But you do want to be really prepared that if someone asks a question, that you are prepared and ready to answer it, right?

So, this is where I'm saying, these meetings where I would meet at Microsoft with senior executives, I would probably prepare 100% to say 0.1%. And I don't think I'm even really that much exaggerating. That I had to have so much context and have to cover all of my bases.

So, that when they asked me the questions, that I was really prepared for those meetings. And you're gonna kind of find out as I go on here, there's different levels here, right? There's the casual one-on-one, where you don't have to prepare a lot. And there's the ultra important meetings, where you have a million dollars of salary going out the window for just one meeting.

And in those meetings, you damn well better be super prepared, it's basically public speaking at that point, right? You need to be that prepared for him. Yeah, and you can see here, at Microsoft, no joke, I would spend a month preparing for a meeting. That was actually most of my job, it was preparing for one meeting every month.

It was the most important thing I did at Microsoft. And you might say, well, that's really unnecessary, you're paying one person a lot of money to prepare once a month for a meeting. And I would argue that's actually one of the most effective things that Microsoft knows how to do.

My entire job was to brief executives on what it was like to be a JavaScript developer on Microsoft Azure. And we were able to make a lot of changes, but it was that meeting that was the lever of change. So, I know people love to say, how much money is going out the window by having this many people in a meeting right now?

How much salary is being paid out for this 30-minute block? And that is a valid consideration, but it also is a useful point for product managers and people to leverage change. Some meetings don't need to happen, but some meetings definitely need to happen, I think it's my point.

And then don't spend a bunch of time convincing who don't need convincing. I think there's a big temptation with product managers that are like, I made all these slides and I'm going to show you all of the slides that I prepared. If you're going through slides and you're realizing that I actually don't need to talk about this, skip slides.

Just do it and then make sure you send out those slide decks later, you don't have to go in order, you don't have to show all your slides. Be adaptive to the message that you're trying to convey in the room.
>> When you gave the example about that one meeting at Microsoft, which represented a reasonable swath of the organization.

Would you talk a little bit about how you selected or listened for the things that you would talk about or that you would bring up? Because I think the implicit point here is that the preparation for that one meeting covered a lot of work that needed to be done.

And if that work got done, there could be some good benefit to it. So, how did you go about weighing out objectives or at least farming them to bring them up?
>> Sure. So, I had an hour with people that were able to affect change in the company.

And so I went in there with usually two to three objectives, usually one major objective and two to three smaller ones. And then they usually expected a little bit of informational reporting, which I always threw at the end. Cuz if that was something to cut, that was the stuff to cut for me.

So, I would make sure that we would cover particularly my major point upfront first. And I would prepare a ton of things of basically what was the problem, what was our solution, what kind of solutions did we look at, and who was involved. I think that's more or less the major points of that.

And then I would come in really strong and just say, this was a problem and we fixed this, what do you wanna know more about? Because typically they had something that they would get really interested in that we would follow their tangents, right? So, I'd have to prepare all of those answers because they might ask me, right?

Usually, they weren't really questioning my solutions, and that was actually the part that I cared most about. They wanted to know some context, so it was kind of like, all right, if you let me have my solution, I'll let you know anything that you wanna know about it.

That was kind of the agreements that I had with those people. And sometimes they'd be like, okay, I don't actually like your solution, let's go talk more about that. And then I'd talk about alternative solutions, why we didn't choose those, those kinds of things. So, I mean, it's kinda like I showed them the tip of the iceberg and it's like, okay, what part of everything underneath that do you want to talk about, right?

Do you wanna talk about all the way at the bottom of this or do you want to talk about how did we get here? Those kinds of things, so does that answer your question?
>> Yeah, that does. The difficulty is making those summaries.
>> Yeah.
>> And remaining focused, but also not allowing the discussion to get so far out of your objective that it just is-

>> Yeah, I'll talk about how to wrangle here in just a second. Something that I didn't put in here, and in several places I should have put this. Never be afraid to say I don't know, because if you don't know, don't make it up, right? Because then you get into a real trouble either by someone who will take you at your word, when in reality you actually didn't know what you were talking about.

Or you'll get called out of it and you'll lose credibility. But it's always better to say, I don't know, let me get back to you, I don't know, this person might know. Get used to saying I don't know a lot. Because frequently they're just saying these questions like, hey, did we think about this?

And it's okay to say, you know what, we didn't think about this, right? It's okay for other people to also be professionals and smart in their fields as well, right? So, embrace the fact that you don't know everything. And, yeah, that's another important thing about being a PM, it's that you're not expected to know everything.

I'll even go as far as to say that sometimes you'll prepare 90% to say 5%. And they'll ask you something in that 10%, something that you should have done and you should have known. And it's really okay to say, you know what, I probably should have had the answer to that and I don't, let me get back to you by this point.

And then please follow up if you get asked a question that you don't know.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now