 Hi, I'm Ariel. I've been a PM at Dropbox for four years. When I was just starting out, I had all these preconceptions, these myths about what being a PM would be like. So today I'd like to share with you how my experiences taught me which of these myths are fact or fiction. We're going to go over seven myths today, but if you have additional questions, please leave a comment below. So myth number one, when you look at a PM's calendar, it's usually booked nine to five meetings. So that must be all a PM does, right? Drive meetings, attend meetings. This myth is actually fiction. A PM's job is all about delivering results. And sometimes meetings are helpful to delivering results, but you can get your job done with as many or a few meetings as you would like. In fact, at Dropbox, since we've moved to a virtual first world, we've been practicing an async first mentality to accommodate all of our coworkers in different time zones. And I would say I feel even more productive. In an async first world, I found it super helpful to be judicious about what does or doesn't need a meeting. For me, I found meetings most helpful when we need to discuss, for example, when my engineering and design counterparts are jamming with me on how to solve a user problem. When we need to decide, for example, when we have a really good idea for a project and we need to get stakeholder buy-in to move forward. Or when feelings are involved. For example, when a project doesn't go well, and we want to retrospect on how we can do better next time. But for things that don't need meetings, I've been moving them to Slack and email so that I can have a lot more heads down time and really focus and think on solving the hard problems. Next one. Well, if a PM's job is to deliver results, then obviously they need to ship, right? This one I've learned is fiction. Results doesn't always mean ship that shiny new thing. In fact, sometimes results mean don't do anything or even take something away. And initially that feels a little counterintuitive. But if you zoom out and think about the big picture, the company has limited resources. So any resources that they're spending on this low impact thing are resources they can't be spending on the higher impact project. In fact, at Dropbox, I've had two projects where there's a lot of internal excitement about it. But when I started interviewing users and quantifying the opportunity, I realized that no one really wanted this. So despite it being the unpopular opinion, I had to push back on doing the project. Thankfully at Dropbox, we value focusing our resources on the highest impact thing. So I felt confident in moving forward and pushing for the right decision. So assuming you're working on a project where you decided shipping is the right thing. Your job is done once it's out the door, right? In my experience, this one is fiction. For an experience, obviously the goal is to learn. So getting it in users' hands is just the first step. The fun part comes when the learnings come in and you can iterate on your hypotheses and continue learning. But even for GA, a PM's job isn't done once the feature is out the door. Because our job is to deliver results, we need to make sure that we move those metrics that measure that we delivered results. So once the feature goes out the door, I make sure that the metrics move so that we actually measure that we deliver those results. I make sure the feature doesn't adversely impact someone else's important guardrail metrics. And I make sure that over time, the feature doesn't just stop delivering results, maybe because it's broken. Next up, a PM doesn't need to know how to code, right? In my experience, this one is a fact. And at Dropbox, you definitely do not need a technical background in order to be a successful PM. In fact, I know many successful PMs that came from non-technical majors like physics or even history. Through my experience, I've done a few more technical projects like search, machine learning, integrations. And the most technical I've ever had to get is understanding how all the services connect together in a technical architecture diagram. Of course, I found understanding under the hood helps me make trade-offs and make the right decision. But I lean on a strong technical lead partner to be able to do this. My TL partner will go look through the code and understand what the limitations are and come back to me so that I have contacts to make the right decision. So please do not let the lack of a CS degree deter you from pursuing product management. Switching gears a bit. So if people look to PMs for the decisions, then is it a PM's job to make all the decisions? This one is fiction. I was a bit unfair in this one because I think phrasing is key. Yes, a PM's job is to make sure a decision is made so the project can continue moving forward. But a PM does not need to single-handedly make all of those decisions. At Dropbox, we use a daisy framework to streamline decision-making. D stands for driver. This person is in charge of making sure a decision is made and often involves laying out all the options, analyzing the trade-offs and making a recommendation. A stands for approver. So this person is accountable for the project's outcome. So they often need to be cool with the decision that's made. C stands for contributors. These people help provide context to evaluate options for the decision. And then I stands for informed. So these people are updated once the decision is made. Let's walk through an example where I was not the one who made the decision. Recently, we had to make a decision about how to display image thumbnails. I considered myself the approver as the PM because I was accountable for the results that this feature delivered. But I didn't feel like I had all the right context to make the call here. So I asked the driver, the designer, to drive this decision. And I told them what I cared about, which was meeting user needs and not accruing a lot of unnecessary engineering costs. The designer then jammed with the contributors, the engineers, on the solutions and kind of the trade-offs and came with a recommendation. And then I was called the recommendation. So we informed the rest of the team. Because of our clear roles, we were able to make a decision quickly and keep the project moving forward without getting caught up in differing opinions. Next up, when everyone's looking to you, obviously a PM should have all the answers, right? So there's two ways to interpret this myth. And both are actually fiction. First interpretation, let's say someone asks you a question during the meeting. You don't know the answer. Moment of panic, what do you do? In my experience, I've actually learned it's totally fine. You can just follow up afterwards and be like, hey, this is the answer to your question. Because no matter how good of a PM you are, there's no way you keep every single piece of information in your head and on hand what someone asked you for it. The second interpretation is let's say you have identified a user problem, but you don't know how to solve it. Is that a personal failure? Again, no. Because the whole point of hypothesis-driven development is that you take your best guess, your hypothesis, and then you put it out and you learn and you iterate. And even if you were right or wrong in your hypothesis, you've learned something, and now you're one step closer to giving the right solutions to users. Next up. Is it helpful for a PM to have a network? I found this one is a fact. It's pretty obvious. In my opinion, it's always helpful to have a network to lean on. And at Dropbox, I try to maintain a network of peers and mentors that have different strengths and are in different areas of the company. My area has a working session of most PMs every week where we bring early ideas and jam on them to build our craft. And in addition to that, I try to maintain a network outside of my immediate peers to hear their different perspectives and understand how the company is operating as a whole to make my decisions better. I end with this one because it's really hard to maintain a network as a PM. Before all this remote-first stuff, it was already hard because you only have a handful of PMs in a particular area. And then now with this remote work situation, it's even harder because you can't just run into people in the hallway. I found that I've had to put in the extra effort to attend a bunch of socials at the company, a bunch of conferences in order to build my network. So while it's hard, please don't be discouraged from building your network because that support system is so helpful for our personal growth as PMs. So that is all of our myths today. I want to thank you so much for watching this webinar, and I had a lot of fun making this, and I really hope my experience can help you in your career.