Melissa Perri: evaluation

Transcript context

…This is the only advice they'll need. So I'd say, one, the best thing that you could possibly do as a product manager, even if you've been in this role for a while, is to make sure that you're always learning. But the way that you're going to learn the most, usually, is from execution. So what I'd say is first, focus on that. Focus on doing your job every day. Then, I would analyze your job and say, what's working? What's not working? And then, take out certain pieces of it that you want to get better at, and then do a deep dive into that. So for me, when I was thinking about my career and my stuff, I did a similar approach where I'd just run into problems, and I'm like, I need to learn more about why that problem is causing this. One of them was Agile. I found out that a bunch of people who never did product management before became product owners. They were writing 8,000 user stories for very small, little features. I'm like, why are you writing so many user stories? So I went down a rabbit hole, interviewing everybody who wrote the Agile manifesto and [inaudible 00:50:19] and taught all those things to find out where this came from, so then I could figure out how to fix it. And I think you need to carve stuff out like that, where you go, what's this topic I want to get better at? What's this going to do to help me get to the next level? Where do I need to learn and help fill in my skill gaps? For instance, if you're not great at user research, or you haven't had a lot of experience talking to customers, I might deep dive on that. If you're not great at data analytics, I could deep dive on that. But I think there's a certain point where we get to, okay, I understand the basic product framework, and everybody's going to have different opinions about what that framework should look like. But we all generally agree at the end of the day, you should be talking to your users, you should be working with your teams to develop what a test should be, run some tests, figure out what your users want, build it with your team in an iterative fashion, measure success, and keep going from there. That all generally stays the same. But how you do each part of that, you're going to find some people have one opinion, some people don't. And you have to find something that works for you, and then stick with it, and then find out that if it doesn't work for you, change it. And this is where I get really passionate and frustrated with Agile processes, which I used to rant about a lot. But I feel like some places, we've solved this problem, some places we haven't. But I try to tell teams that started with scrum or started with some of these more dogmatic processes, if it doesn't serve you, move on. Change it. Everything is meant to be iterated on. Everything is meant to be adapted. If it does not work for you, you do not have to keep doing it. ogmatic processes, if it doesn't serve you, move on. Change it. Everything is meant to be iterated on. Everything is meant to be adapted. If it does not work for you, you do not have to keep doing it. And I think that's the biggest message I can tell to anybody learning, is really, sit down, do a retrospective with yourself, and say, is this helping me get better at being a product manager? And if it's not, change it. Change your approach. Do something different. If it is, keep it. Keep it in your toolbox. Create your own toolbox and go from there.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.