 Hi everyone, I'm presenting this webinar on writing and reading for PMSuccess, my name is KB Vibhuti, I'm a Senior Product Manager at PayPal working on their developer experience. Just a little bit about me, I'm an engineer who turned into PM2 just like many of you. Customer interviews, research and a lot of empathy towards our customers needs is what turned me into a PM. I like to think of myself as a versatile PM and I really try hard to be that one. I do this by testing my product skills in new domains frequently. The reason I do this is I believe the art of product is best practiced when applied to multiple domains and if your success comes from being a good product practitioner and not just a domain expert. The several products I have had the opportunity to launch in the past including a lot of apps for NBC like eOnline, NASCAR. I also had the opportunity to work on DFW and Toronto Airport applications. Later, when I turned into a PM full-time, I also worked on underarmors digital products like Map My Fitness, My Fitness Pal and their shopping experience. I also had the benefit of working at Amazon on the B2B franchisee product which we managed to launch during the pandemic and later I went back to working on Alexa Smart Home which was a pet project on the side I had had for many years. Like I said, currently I work on PayPal's developer tools wherein we try hard to improve the developer experience on developer.paypal.com. So the agenda for today focuses on writing and reading and how to do better at each of these. Although this webinar focuses specifically on writing and reading skills for PMs, I highly encourage considering these aspects of writing and reading and the benefits for any other role that also supports a PM or in a product team whether it's an engineer, an engineering manager, a designer, a data analyst or a business intelligence person, a researcher or any other role for that matter, you can always get a lot of advantages by writing well and learning to read at work. So what do PMs usually write? I think this list will look familiar to a lot of you. However, the entire scope of things that you may actually had to write something for expands as you have different experiences in your PM career. For example, I didn't really write a patent proposal until two years ago and that was the first time I had to learn how to do that. I also learned how to write annual operational plans in a lot of thorough detail within the last two years. Meanwhile, research reports and comparative studies are something that I have always done throughout my career. Just the quality of my writing has improved and contributed to better outcomes. A three-year plan is also something of an artifact that helps a PM prove that they are a strategic PM and there's many other documents that a PM might end up writing. One thing to note is that just writing a document is not equivalent to checking a box and being done. The document by itself may be as short as one paragraph or two paragraphs or it could be as long as a six-pager popularized by Amazon and also referenced to as a PR FAQ, which stands for a press release and frequently asked questions. So why should PMs write after all? Here are some of my key reasons for championing the art of writing for PMs. It really forces you to prepare. Imagine you walking into a meeting and blabbering out a lot of your unstructured thoughts in the heat of the moment. Now, there's definitely a lot of good speakers among all of us and I'm not necessarily saying that speaking is completely unstructured. However, speaking doesn't really allow you to follow a script in a conversation, especially when the audience starts interrupting you with multiple questions. Somebody might ask your question that you may have answered 15 minutes later in that meeting. Instead, when you take a written document, since it has forced you to prepare, you have put a lot of thought and created a structure, you can expect the reader to walk through it patiently with you. Thus, the art of writing helps achieve frugality in communication. You not only put structure, but you also try to make sure you have the fewest words possible required to convey your points. It helps put your audience in control, which is one of the things I like the most, not just the writer, but also the audience if I may repeat. A lot of times during meetings, the audience may feel like they had to wait too long to get their specific questions answered. If you present a certain document, the audience also has the opportunity to jump ahead and look at specific sections of the document that interest them the most. I don't absolutely recommend that. If I were a reader, I would rather recommend they patiently go through the document, but then the reality of the situation may dictate that they have to actually jump through the document fast. And thus, they can still be in control, where they can pace themselves effectively. Writing actually supports flexibility and asynchronicity a lot more than speaking does. And we have all learned this, I think, during the pandemic and working remotely across multiple time zones. You don't have to wait for a meeting to be scheduled anymore, because you have the ability to send a detailed written document a friend, get somebody to read it, and ask them to respond back to it. Now, you may think this is the same as writing an email, but I disagree. Writing a document provides a lot more structure. And if you use the right tools, example, Confluence, or a shared document that's hosted online through Google Drive or through Microsoft SharePoint, you get the opportunity to actually collaborate in real time, but at your own convenience. And thus, you're not bound to necessarily a meeting to get communication moving along. Last but not the least, I think writing instills commitment and accountability. Imagine if every person around you was expected to write something before they come to a meeting. Then you can always almost guarantee that they have put in some thought and structure as a prerequisite to having that meeting. So how should PMs write? Number one, think start with an existing template. Don't try too hard to reinvent it every single time. Everybody loves their own templates, but see what your organization, your team, your manager, or your peers are already using. Try your best to use the same for consistency. Then think about opportunities to improve on top of them. Next, if you do indeed start with your own template or a document from scratch, or even if you're building on top of an existing template, you want to draft your key points. And the simplest way to draft your key points is to answer the what, why, hows, who, where, right away in your first draft. Once you have the main content, you have the bulk of it when you answer these questions, you can start setting up your structure and think about the common elements that you want to put into a document. Most documents, whether it's a research report or it's an operational plan or it's a roadmap review, we'll talk about the vision, mission, and the background. You will also want to have an executive summary because there's always going to be a section of your audience that wants to do a fast read, know what is happening in the document upfront through the executive summary. Then you talk about the current situation which sets the reader's context. You talk about your specific goals, your dependencies, your FAQs, which are the frequently asked questions, key takeaways, action items, and an appendix to host anything else that is extra reference content. Now you start thinking about the specific elements. There may be categories of investment if it's a roadmap or a proposal to invest in a new customer segment. You may want to talk about competitive benchmarks if you're doing the research report. You may want to talk about a technical system design if it's a highly technical document where you're proposing your solution. And then there's others like highlights and lowlights if you're reporting on your program on a weekly or a monthly basis. You can also have UX design marks if it's a UX specific document. But then UX design marks always add more visual delight, so I highly recommend having something to show off. FAQ driven writing, we are going to talk a lot more about this in the next few slides. The last few quick things to clean up your draft and your document are going to be grammar and language checks. And almost every editor you use these days offers an opportunity to correct your phrases, your sentences, shorten your sentences, change out your words, and do grammar checks. Make full use of them. There's grammarly, there's something called pro writing aid which I used a lot in the past. And even outlook for that matter has embedded grammar and language correction in real time now. Start shortening your sentences, use very simple words, explain acronyms the first time they are referenced. Most importantly, start awarding non-specific fluff words. Let me try to give you an example. If I were to say a sentence like the team achieved an extraordinary amount of progress in the last print, can you catch the fluff words? I would say extraordinary. You don't want to say such things. You want to talk about the specifics. I would rephrase it as the team achieved XYZ number of story points in the last sprint, which is greater than the average number of story points delivered in all of our past sprints this year. You suddenly made the objective extraordinary a lot more specific by quantifying it and got rid of a fluff word which lends itself to the last point, which is always stick to facts, numbers, dates, and outcomes. That is the meat of your content. Now what are some of the advantages of FAQ led writing which I referenced earlier? FAQs, which again stand for frequently asked questions, is a way of thinking about the content you are going to put down. Instead of having section titles where you said things like current situation, customer segment, opportunity size. Now imagine you spun them into a very specific question and said, what is the customer opportunity size that we are looking to address? Or what is the specific customer problem we are looking to solve? Any time you try to intentionally change your section header into a very specific question, you're guiding the reader and making them laser focused on the response that you're about to provide to them. You will also notice using FAQs eradicates less relevant content, because if you just did a section header, you're probably going to end up putting in a lot of words that are related, maybe somewhat related, and you're tempted to leave them in there, but they don't necessarily directly answer the question you're trying to ask, answer for the reader. FAQs also give you the opportunity to break up your content into multiple questions, and by doing this, you go at it one question at a time. It helps command and facilitate the attention of the reader. I'll talk about how to create a very natural and an optimized flow in an upcoming slide. Another advantage of FAQ-led writing is that it reduces open-ended chatter and vague questions, because you have probably already covered a majority of the questions in their mind. You have also phrased them for the reader in a very specific, pointed, and precise language. Thus, you'll save precious meeting time, because generally you will walk into a meeting with a document that everybody reads or has pre-read before the meeting, and you have answered 80% of the questions that they had in the mind. And like I said previously, it allows asynchronous collaboration. Imagine somebody who couldn't attend the meeting, they could still have something to read and catch up really quickly, sometimes in as little as 5 to 10 to 15 minutes. FAQs are definitely teamwork. This is a habit that PMs have to encourage within the team. By writing the FAQ, you are working backwards from the customer's problem, and doing it together as a team, where you invite everybody's inputs into answering that question. Everyone, every single role on your team can write and contribute. The PM can then take the pen and draft the final response by reviewing all the inputs they have gathered from the collaborators. Document iteration is actually a very fun activity if made a recurring activity. I remember the last time I wrote a PR FAQ, which is a six-pager, as popularized by Amazon, where you talk about a product's launch and its proposal in a lot of detail, and cover every single aspect of it. I met my peers from engineering and project management and design pretty much every single day until I had answered all the questions that we had asked ourselves of friend in very specific words with an extreme amount of evidence that you may not usually see in a lot of documentation. By meeting regularly, you build trust within the team as well and make it a democratic process. The other beauty of having FAQs is that you can coach and jump-start new PMs really quickly. Just imagine a new PM joined your team. You handed them a templated set of FAQs that they should probably be answering for every single product discussion. You probably saved them two hours of preparation already, and I have such a template in the examples at the end of this presentation. The last thing I'll say is it builds stakeholders trust in the entire team. When stakeholders start seeing the same kinds of questions being asked thoughtfully in the same language and then getting all the responses, they can walk into a meeting knowing that this entire team has a unified way of thinking and approaching problems and then solving them for your customers. Half the battle is already won when you have that trust from your stakeholders. Isn't that true? So here are some tips for FAQ-led writing. You want to brutally simplify, shorten, and decouple. And there's an example. You might be tempted to ask a question like, what customer problem are we solving, and why should we solve this now? I do this myself a lot and I do remind myself that it can be changed to two specific questions. What customer problem are we solving? Maybe it's a two-line answer. And then what happens if we do not solve this problem? These are two separate questions that deserve their own responses clearly separated out. Next, after you write all your FAQs, sequence them really well to build a very natural flow for your reader. In your final iterations, try to cut down on the FAQs. You stick to the fewest FAQs that cover the most amount of information, especially as you start seeing repetitive information across a lot of the FAQs, which is fine. You start with several FAQs and then you take a razor and slice through all the extra. Ask the hard root questions for yourself upfront. And some good examples of this are, what is your plan to mitigate risks? What will customers not like about this solution? Let's move on to a little bit about reading. How should PMs read? By reading well, you are setting a good example and encouraging the habit of writing in the presenter or the meeting host. So start with being patient and allocate enough time for it. If they ask you to pre-read, try your best to spend 10 minutes on it in advance before the meeting. If you still don't make time, then make sure you come to the meeting, be transparent that you have not read, and then ask for 10 minutes to go to the document during the meeting. Look for the key points, the what's, the why, the how, the who and the where, and that will start helping you quickly figure out what this document is all about. Look for the common elements that we talked about previously and then also for the specific elements depending on the nature of the meeting or the agenda. Demand simple words and explanations of acronyms. Don't assume anything by asking for simplifying words and explanation of the acronyms. You might be doing the rest of the audience a huge favor. Demand facts, numbers and dates. Provide written comments, questions, clarifications and your own knowledge. An important thing that I look forward to from a meeting when I take a written document is I want to sometimes write the wrong things or put out the wrong assumptions that I may have as the fastest way of eliciting the right information. And now I'm heavily leaning on the reader when I go to the meeting with this perspective. So, I expect the reader and I always tell them feel free to put in your comments directly on the document because most tools like confluence or shared editors allow real-time communication through comments and questions. Some important things to remember are to discuss and speak about only what is not addressed already. Awarding plus ones and low value comments saves time and resources during the meeting. Take one-on-one conversations offline. If you don't need the entire group, then save your thoughts for later. Some final thoughts because there's a lot I can say about writing and reading but it comes down to these following. Writing and reading definitely go hand in hand. Both of these practices need to happen for a balanced ecosystem of communication. However, don't let that stop you if the audience around you is not used to reading a certain type of document. Keep writing, keep presenting and it will come to them eventually. And it's also the other way around because if you are with an organization or a team that does not write as much, asking for reading material will force them to start writing more and put their thoughts down on paper. Writing is definitely a great equalizer. It democratizes the entire process and also levels the playing field. Not all of us come from native English-speaking backgrounds or are the most confident ones if handed a microphone but instead we can write and present and expect that everybody is going to patiently read through it. There is of course always going to be discussion time after you have taken a stab at reading during a meeting. Written communication is timeless, enough said. Write for yourself, invite reviews and adapt to your audience. The last thought I have here is meant for yourself practice. Even if you don't need to present a document and you would rather do it as a slide deck or presentation, write a couple of paragraphs for yourself at first, trim the sentences, refine your thoughts and then copy paste them onto your presentation. Invite a lot of critical reviews, get your buddies at work to start reading what you write and ask them to not hold back any of their honest feedback. But most importantly, adapt to your audience. Even though I stress on writing and reading, there's always a section of your audience that will respond well to visuals, to power points and spoken presentation. And you want to be mindful of this audience because your success depends on meeting your customer's need, which applies to your audience too. Here are some example FAQs for all of you to refer in the future. I hope this gives everybody a jumpstart because if you follow some of these customer FAQs and these internal FAQs, half of your job will be done by writing crisp responses with the right amount of details like the dates, the estimates, the plans and the artifacts that go along with it. You will have a solid project plan and you will have no problems convincing your stakeholders and your team. Good luck and thank you so much.