 Hi everyone, thanks for joining. Today Eva, Candice, and I will talk about some tools that a product manager might find helpful. Before we get started, let's go over what our agenda will be. So we know there are a lot of tools out there and we can't possibly talk about all of them today. But we have separated them into three different categories. So first, Eva will speak about tools for productivity. So these are the things that you might use day to day to help you stay on top of your to-do list. And then secondly, Candice will walk us through some tools for design. So how would you actually bring your ideas onto the paper? And then finally, I'll talk about tools for communication. So how do you actually share your projects out to different stakeholders or your future team? And then lastly, we'll end with a summary. Before I start getting to some of the details, I'd like to share a quick takeaway so we know what to expect from the talk. So first, the main point we really, really want to emphasize is that there's always going to be new tools out there. And what's more important is that you create a process for yourself so you know what to use in which situation. And then secondly, it's okay to use different mediums to express different ideas and different situations. There's no one holy grail tool that will solve everything for you, so don't forget to try out something new. Lastly, it's really important to practice your communication with a variety of different stakeholders because your audience matters. And depending on who you're talking to and what level of detail they're looking for, you might be using something else to convey your ideas. So before we begin, I thought it might be interesting to frame this in the context of the story. Or in this case, the life cycle of a project you might be assigned to. So let's imagine your manager is telling you to start a super new high priority project and an example of this could be the browser extension to make it easier to find and share gifts on the internet. So how would you use your toolkit to get this job done? And first, I'll hand it over to Eva to talk about tools for productivity. Thanks, Shirley. Before I get into productivity, I'll give a quick introduction on myself. My name is Eva Chen. I'm a program manager at Microsoft. I've been here for two years and I work on Microsoft Edge. I attended UCLA for my bachelors in bioengineering and my masters in electrical engineering. So you've been given this awesome new project, and now you actually need to execute on it. But PMs wear a lot of hats and have a lot to do. So how do you make sure that you generally stay productive so that you have time for the most important things? One way to stay productive is to stay on top of email through email triage. I used to look at my email and get so overwhelmed I would spend so much time trying to immediately respond to each and every email. My friend Jillian Kong taught me this method though and I'm so glad that I've implemented it. So the goal of email triage is to stay on top of email by treating emails almost like a bug triage. Every day quickly go through your inbox and for each email decide what to do. Either respond immediately if it's an emergency, archive it, delete it or move it to an action folder to be responded with later. Inbox rules are also your best friend to make sure that only the highest priority emails get into your inbox. And finally, I also like to prioritize the to me folder before I go into my normal inbox. Now the outcome of this is that you've spent a way shorter amount of time and you have an idea of what needs to be done and it feels way less overwhelming. So we've talked about prioritizing your email and general productivity. So now how do we prioritize the big projects? I think of this in three steps. First, I prioritize my list of projects. Second, I prioritize my time to be able to work on the project. And then third, I prioritize work within my future team in order to execute. So first we'll get into prioritizing your list of projects. Being able to know and communicate the priority order of your projects is integral in work-life balance. Your time is not infinite. There's only a certain number of hours on the day, so you have to learn to prioritize. If new projects pop up, have a conversation with your manager. I like to list out all the different projects that I'm working on and what priority I think they are. And I pencil in that new project and I tell my manager, hey, with the information you've given me, I think this project fits into my priority list here. Let me know if you think it needs to be moved higher or lower. Also, these are the things that will drop if I take on this project. This helps give more transparency to my manager and we can work together to make sure that I prioritize the most important projects. The tools that I use for this are usually notes, Excel, to-do, Asana, and Microsoft Planner. We've talked to our manager now and made sure to prioritize this new project. Now we need to prioritize time to focus on these big projects. One tool that I love using is the concept of focus time. So before every week, I protect a few chunks of my time during the week to get some heads down work done. This is usually an hour or more to be able to really get that focus time in. And I use the focus time on my analytics in order to block off that time on the calendar. So I also usually set an intention for each of these focus times. So one or two things that I really want to get done in that block of time. And this helps make incremental progress on my bigger projects and helps plan out how I'm going to get that done. As a PM, you're likely also prioritizing work for your future team. This consists of a few parts. The first is prioritizing the scenarios or projects similar to how you prioritize your own list of projects. Where does this project fit in priority relative to all the other projects that the team is working on? This can be done in your DevOps software or just a simple table or spreadsheet. Once those projects and scenarios are prioritized, what requirements need to be prioritized within the scenario? So which requirements are P0, P1, P2? This can help determine when these things need to be worked on. And same thing, this can be done in your DevOps software or a table or spreadsheet. Once you've prioritized these scenarios and requirements for your future team, you likely also need to prioritize the smaller chunks of work, so the deliverables and tasks. The bumpboards can be really helpful here. They can help you and the team visualize the big picture of the current status for each of the deliverables, and it also helps teams take on more feasible amounts of work. So now that you've prioritized you and your featured crew's time to work on this project, how do you go about designing the future? I'll hand it off now to Candace to talk about tools for design. Thanks so much, Eva. So before I dive into design tools, I want to do a short intro about myself. My name is Candace Poon, and I've been a PM at Microsoft for three years. I spent most of my time at Microsoft focused on shipping new differentiating user experiences for Microsoft Edge, and I also spent a summer as a PM intern building user experiences for the Surface Hub. I'm a graduate of Rensselaer Polytechnic Institute, where I did my undergrad in information science and human-centered design, and my master's in entrepreneurship. So like why is design important, especially to us product people? If you ask me before I attended university, the first image in my mind when I think of the word design, I would imagine myself actually walking through the MoMA, or some type of fine art institution, some type of abstraction of the discipline. But as I began to ship products and work in these product teams, I realized that design is just a really important process. It's the process of translating all these various aspects like your user need, your technical requirements, different milestones that you imagine, even aspects of the business that you incorporate. And that blue arrow is that process of translating all those things into the end product that your user gets to touch, experience, find joy in. And I'll be the first to say, as a product person, it's actually kind of difficult sometimes because you're in the intersection of multiple disciplines and requirements, between all different meetings between engineering, design, marketing, business, with your leadership. All these requirements come in and they usually manifest in different tools like the backlog, through emails, through chats, through different wireframes. And so it could really create a sense of chaos. I definitely feel that when I'm thinking about the beginning stages of what feature or product that I want to build. But I think this is where the power of using these design tools to gain clarity, not just for yourself, but for your team and for your company and for your leadership come in. Like Shirley said earlier, what I'm really emphasizing though is I'm not want to be too prescriptive about the tool. Tools come and go in the same way that oftentimes I believe software engineers are taught, that just focusing on one language makes you somewhat rigid. And so understanding the processes, being agile and learning different tools is a more important aspect. And even when I say design tools, I definitely mean things like Figma or XD or Prasamek. But there's really a power of becoming almost an expert and being able to express your ideas even through pen and paper and using paper prototypes. The tool itself doesn't really matter as much, but I will be using one as an example later on. One small pushback I normally get from PMs about embracing design tools and using it as a core part of their workflow is this whole idea that, but I'm a PM, not a designer. The walls between the disciplines are too high and I need to stay in my lane. I definitely felt that way a little bit in university where I was kind of a jack-of-all-trades master of none. And I felt a lot of that when I started my role as a full-time because I was a PM and they were professional designers actually assigned to the project or the organization. But I challenge everyone to have a curiosity and to think of this as one aspect of your tool belt as a PM. And especially with PMs being so interdisciplinary at this point, any type of skill set that you can add to your arsenal just makes you more impactful and effective. Design is super important as a PM. It's allowing you to work in the currency of design. And what I mean by that is even being able to immerse yourself in the tool, allowing and understanding their thought process as they're building designs really makes it easier for you to communicate your ideas and build empathy on what their ideas and challenges are as well. The important thing too is when you're able to actually start creating these pictures or these artifacts, you're able to bring stakeholders along and actually express things that actually feel tangible and real to people that maybe are not as immersed in your feature, what you're actually trying to solve for, what's your vision, what are the aspects in your backlog or in your user requirements that you're really emphasizing when you're thinking about building the end solution. A real big thing too is maybe as a PM, yeah, your main currency, your main artifact is actually through decks and PowerPoints. I know for me it is, it's really used as a way for me to do the storytelling and kind of the selling of the vision that I have. And one of the things is I spent a lot of time making them. And so being able to take the drawings that are created in the design tool and efficiently put them into the deck actually saves a lot of time. It seems really small and minute, but those things really add up. And so the more efficient you are, the better and the more time you can focus on the actual store a bit and not the tactical element of making the deck. The last thing I'll actually say too is I think working in the design space and creating either prototypes or mockups actually really is a great forcing function for everyone on the team to find major holes in the end to end flow. I know for myself sometimes it's really easy for me to be bought in and sold on one static frame and not do the kind of yes and problem solving around, hey, what happens when a user does click on that? What happens afterwards? Forcing myself to think through and actually draw the picture and put myself in the user's shoes when designing these flows has been really critical in making sure I don't forget anything. So I spoke earlier about how I don't be too prescriptive of which design tool to use but I do want to give examples today on features in modern day design tools that I think are really important to us as PMs. I'll be using Figma as my example. Components are super important and I actually think they're important for two main reasons. The first thing is it just saves you a lot of time. I know previously when I started learning using these tools, I would make something like a button and then I would use it multiple times and then I would change my mind either on the color or the font or something and I would spend all the time updating it to make the screens consistent and like components are the solution to prevent you from having to do that. But the bigger thing is components are actually used heavily a lot in design. Design is actually building these component systems so that way it feels consistent throughout the entire product. So I recommend actually becoming immersed in the component library that your team might already have and using that kind of as Legos as you begin bringing screens together. That way if the design team changes direction or they make updates to the design system, you're able to get all those changes automatically. The next major element is prototyping. I really think this is really, really important and I actually really, really love Figma's prototyping tools. It allows you to stitch static screens together to create an immersive flow and a lot of these modern tools have become so great that it's really easy to do it and it's actually able to adapt. So in Figma today you're actually able to prototype and actually send it to a device. So if you're designing for something like a mobile device, you're able actually to experience it with animations and other things that feel just as close to what you might be shipping with your engineering team. Prototyping also makes it really easy for you to quickly prepare for user research and so that's also a major area for us to focus on as PMs and so being really efficient and stitching together prototypes and trying to validate your hypothesis of what the solution might be is really, really important. The last important tool is the export tool and this goes back to what I was saying about how oftentimes decks, storytelling, and PowerPoints are really a lot we spend our time on and so becoming really great at understanding the export tools, being able to quickly take pictures out in the resolution or in the right format and not cluttering up your desktop is really important. So learning the keyboard shortcuts, I pretty much have Control Shift C memorized internally in my mind just because I use it so much when I'm taking screens out and moving it into a deck. So just become comfortable with it. It'll save you a lot of time. So those are my thoughts for design overall as a PM. I'll now hand it back to Shirley who will talk about communication. Awesome. Thank you, Candice. Now let's talk about some of the tools we might use to communicate your ideas with both your feature team and maybe your leadership team. For me, I've done a lot of different types of presentations and documentation for communicating ideas at different groups, whether it be during my undergraduate career at Waterloo or on the Edge team. So hopefully you find some of these tips and tricks helpful for you. For me, the first thing I like to do is think about who the audience will be. So who's going to be reading or listening to what I'm saying? And that really changes up what you want to do with your document or your presentation. And depending if you're talking to a more technical team, you might need something that allows you to either drop in snippets of code or more pictures and charts versus if you're trying to showcase your vision for a project, then you might need to put videos and want to choose something that supports that. So thinking back to your project scenario, let's say you're done ID-eating with design and you have a prototype and you know what you want to build. Now you want to document that and write down all your requirements and your specifications or success metrics for your feature team to run off with. When you're speaking with your feature team or communicating with them, I think it's really helpful to pick a tool that supports both text, large chunks of text, tables, and also means to save feedback and comments from other folks on your team. The goal of this is to have a living document where engineering, design, data science, and everyone can reference as a source of truth. So there's definitely going to be a lot of text and feedback that goes into this. Some tips I found that are super helpful is a table of contents or within Word if you're using the heading styles, then you can actually collapse different sections. So I thought that was helpful if maybe you're going through a review and you want to focus on a specific section at the time, you can collapse and minimize certain ones and move on to the next one. Also what is cool I think is using comments to track feedback. Let's say you're in a meeting and you're going over something with your feature team. Instead of writing it in line or maybe taking notes somewhere else, just writing a comment down and then tagging the person to either follow up or yourself to follow up. And that helps keep track of all the open questions within the context of the document. Now on the flip side, let's say you have a vision for how a feature should work and you're asked to present that vision to a number of different stakeholders. Then your audience is shifted from your feature team to a much more high level audience. And for that, I think what's really key is picking a tool that will allow you to tell a story that is your vision or maybe a scenario or a journey you want to walk through. And being able to do that is super important because this will help get teams on board and really behind what you're trying to convince or build with your feature team. So really trying to frame it in terms of a story. And with all stories, there's lots of pictures and videos, maybe some text, so you want to pick something that is friendly for all those different mediums. Some tips I have for here is that just start early and get feedback and iterate. There are a lot of different ways to present an idea and depending on your messaging and your goals, you might get different feedback and find it useful to share it with different people before you actually call it done. And then along the lines of that, too, think about how your deck will be shared and consumed. So Powerpoint is really awesome because you could do some really cool animations and transitions, but think about how the audience will consume it when you're not there or when it's not in presentation mode. I know sometimes if you're trying to do transitions, you might have pictures overlapping content. And I think what is helpful for people who maybe aren't viewing the presentation that way is to have a hidden slide that shows all the content uncovered. Or just hidden slides in general are super helpful for people to get context who maybe aren't watching the presentation live. And for this, I've used Powerpoint a lot. I know Prezi and Figma are also some cool tools to check out there. When you're creating those slide decks and Powerpoints, I think there are two main things, aside from the actual content to keep in mind. The first is your messaging. So how you actually message or highlight the key points to your deck is super important. Try to keep that to one per slide. For the slide, the main takeaway I want you to have is your deck should always tell a story. And with that story, what is really helpful is if you look at your slide deck and sort of a bird's-eye view so you only see the titles and then reflect on if you're still getting the full story by just reading the titles. And so that's a lot of times, that's what people do anyways. The second thing is your design and styling. So try to add something a little visual to every slide, whether it be small icons. That's always something better than nothing. And I think really take advantage of SlideMaster in any themes that your team uses or your company has to try and stay consistent. You definitely want to have some consistency in colors and layout within your slide deck so it doesn't take away or distract from the actual content you're trying to share. And then lastly, I think when you have slide decks with a lot of prototypes or screenshots, definitely don't be afraid to let that shine and maybe dedicate a whole slide to it. But just make sure you have a follow-up, either a hidden slide or something close to it so that people know what are the key things or what's important to look at within this image. And with that, we hope you found our talk interesting and valuable for you. The main thing we want you to take away is that tools will always change. There's a million of them out there. But what's most important is that you find a process that works for yourself and you can recognize in which situation to use what. The second thing is try out different mediums and tools to express your ideas, whether that be design, brainstorming, or a vision. Don't forget to try out new things. And lastly, what we just talked about, about communication, don't forget to think about who your audience is and how your deck and the piece of artifact you're creating will be shared out later when you're not there presenting it. Thank you.