Check out a free preview of the full Complete Intro to Product Management course
The "Communication Preparation" 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 explains that Product Managers spend a lot of time preparing for all the questions they might receive while only communicating 5% of the information they prepared. This is because communications shouldn't be longer than necessary. The importance of technical writing is also discussed in this lesson.
Transcript from the "Communication Preparation" Lesson
[00:00:00]
>> Would it be fair to say the messaging around this point falls in the frame of due diligence? It's not possible to be prepared for everything. It's not possible to think through every case. But I can come reasonably prepared, and I can come prepared with more than I say.
[00:00:19]
So I have the ability to say no, well, we're not talking about where secrets could start. We have some people who will talk to us about that, so let's keep going. That's almost more of a due diligence practice to your projects, to your own goals. Then some sort of magic if I'm understanding correctly.
[00:00:40]
>> I mean you say my next point here, right? Which is you prepare for 100% so you can say 5%,coming into those meetings to prepared with all those various different answers so that. My favorite tactic and all these things is like, we are not talking about that now, here is the one sentence answer to your question.
[00:00:58]
If you need more, here is stack or put time on my calendar, right? Because it shows that like, you are prepared, you do know the answer to that and you do not want to derail what you are talking about, right? The one sentence answer and the acknowledgement is like I understand you here's your most of your answer you need more come find me.
[00:01:19]
Generally it was really successful for me at Microsoft which was the most contentious meeting culture that I was a part of. I don't mean that in the positive way. There's just a lot of competing interests at Microsoft cuz it's so big, right? This isn't another way for me to harp on this point up here, which is that just because you know the answer and you know, and like you did a bunch of work to find out the answer.
[00:01:40]
You don't have to share that. Results will speak way longer or way louder for your, like, how good you are as a PM than just talking a lot in meetings, right? So, be aware that you're gonna do a bunch of work to get ready for meetings or to get ready for docs that you're just never gonna share with anybody, right?
[00:02:03]
But you know the answer those questions when they pop up like you're gonna be well prepared for those things. Last thing here is this is not high school English class or a secondary language school for whatever country you're from. In my high school English class I was very encouraged to use a wide vocabulary to have varied structures to have different paragraphs to really engage with the pros, right?
[00:02:30]
And make people feel things because of you know the pros I was writing, right? Don't do that, this is technical writing this is wildly different I don't need poetry in mice product specs, right? Technical writing is an entirely different skill set than what you know writing essays three SATs are you should use very direct language, very plain language.
[00:02:56]
Don't use acronyms that you don't have to, don't use initialisms that you don't have to, don't use just silly vocabulary that's not pertinent. Your goal here is to drive understanding not to self-aggrandize, right? So it's a virtue to have very easy to read writing. It's a virtue to have a appropriate reading level of vocabulary for whoever you're speaking to.
[00:03:22]
These are all really good things and I'm encouraging you to write plainer English. Try and use direct voice, use less indirect voice, make your things actions that you are following through on, make things goals are things that are true or false if don't try and dry these Grant analogies.
[00:03:41]
Analogies and metaphors are ,unless they are driving understand them, just leave them out, right again, this is me just picking a bone that I've had with previous PMS before. It's like I feel I'm reading like a novella, right? And there's like a beginning middle middle and end, right?
[00:03:56]
And anyway, don't do that I don't I don't need a romance story in my product spec or maybe I do I guess I'd be entertaining so if you're gonna do it at least make it entertaining
>> How do you go about giving feedback to maybe one of your peers or your co workers That is breaking a Brian rule.
[00:04:12]
>> [LAUGH] I just tell them as you're making breaking Brian rules.
>> So that's it, you got it.
>> Move on.
>> That could be a whole course in itself. It's like how do you influence peers? It depends, right? It's a tricky balanced to strike. Because it's very easy to go cross over from here's honest, earnest feedback that I'm trying to help you with to I feel attacked and you're attacking the way that I pm which is attacking me as a human, right?
[00:04:49]
So it's gonna be I try in general like, if I feel like I can influence someone and help them to like, be better either to themselves or to me or work better. I will engage in that kind of behavior and if I just know it's gonna fall on deaf ears I'm just I'm spending social capital for no reason I just don't give it to honestly, that might be too honest of an answer.
[00:05:11]
Hopefully snowflakes not watching this. No, I try and give feedback to people that I think will will take it and use it, and I try and do it in a way that that's useful to them. So and that's going to be highly contextual to whomever you're giving that feedback to.
[00:05:26]
But I have given feedback to to us, particularly a junior PM that I used to work with, I was like. Your technical writing is too flowery, right? You're using too many, this feels like an essay to me. Just tell me what you want from me and use a quarter of the language that you're doing it with.
[00:05:41]
And she did, and it was awesome, and she's fantastic PM now. Still what she was anyway, but her writing was much better to read.
>> Have you, do you find yourself in circumstances where you have to get technical material or technical writing from engineers or other folks outside?
[00:06:01]
How do you manage that? I'll put myself on the table. Most common feedback I get is, this is terse, but it has way too much math in it. So two pages is too short 'cause it should be five or 10, right? Because it's dense, that doesn't work any better than long descriptions.
[00:06:20]
But when you are working with folks who don't regularly communicate with the outside world. How do you approach that?
>> I just keep them locked in the basement. Yeah, well, I don't let out.
>> That's a good idea.
>> [LAUGH]. [INAUDIBLE].
>> Yeah, I have done this before is particularly with technical architects that are like you know on Mount Olympus right that l are communing with the gods of the cosmos of like how do I organize containers right?
[00:06:50]
[COUGH] And I just harp on them continually is like who are you writing to? And if you gave me a doc full of math and I'm, this is not for me. You did not write a bunch of math for me or you don't know me whether it's one of the two things there right.
[00:07:08]
You are writing down something so that I can understand something and I am not getting there. And so I'm gonna ask you continually is like write this for me what am I getting out of this, right? And I'll just keep sending it back to us I don't get it, until eventually they're gonna write something is like what I'm trying to tell you here's enough math.
[00:07:27]
That's written in such a way that it's understandable, and here's what that actually means to you.That usually ends up with something understandable in the middle.
>> More of an editing process, you have to be actively engaged.
>> I'm just letting him know, I'm an idiot. Please speak to the idiots, right?
[00:07:46]
Don't speak to the smart person behind the idiots, talk to the idiot, right? So, audience, it's just reminding them over and over and over again, it's like, who is this for? Yeah. And like, I told you, I think I told many of you, I'm a college dropout, right?
[00:08:06]
So the only class I think I reference frequently, and I hate it, because it was like my least favorite class in college was technical writing, but I, use it all the time. It's so important to being a good PM, your power as a PM is in your ability to communicate, to drive understanding, and to drive alignment.
[00:08:24]
And so unfortunately, the advice I have to give all of you and I don't want to, is that a technical writing course will serve you so well. Even reading a book, reading a blog post, but really focusing in is how can I improve my ability to communicate makes you a powerful contributor at your company.
[00:08:46]
My ability, when I was at Microsoft to move the company like this trillion dollar company, was my ability to write slide decks because everything's a slide deck at Microsoft. That's how I was able to, like make hundreds of millions of dollars for Microsoft, which is cool, right? It's cool to say that, like, I pointed out, like, I worked on that and I got that through and it was this stock that I wrote that got a bunch of people working on the same thing.
[00:09:12]
So do that. I'm sorry. I truly am.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops