Justin Reidy

Watch the video response on Loom, or reac the transcript below: I've received this question about how to earn the trust of a team many times, usually from folks who are taking over in a product role from an existing PM, maybe it's a new team that's being spun out. And the question is always the same. "I need the team to trust me. I want the team to trust me. How do I build trust with this team". And just as the question is often the same, the answer is the same; no matter what team it is, I always give it the same answer. It's incredibly simple, but not easy. First, you have to show up. You have to be there when the team needs you, you have to be there to answer your team's questions. You need to be reliable. And this doesn't mean, you know, co-location or even co-temporality. As we have distributed work across time zones, sometimes it's not possible to be online at the same time, but you need to be responsive. And the team needs to feel like you care about the team, and the team's work, and the teams product, and that you're not simply there to build up your own portfolio or identity or to be managing up or managing laterally. You need to be there for the team, and you need to be prioritizing the team, and the work of the team. Two is to be humble. And this manifests most often in admitting what you don't know, and then finding out the answer. So, especially when you're new, but really at any point, asking the team for their opinions, for their insights, recognizing that you don't know all the answers and that even when you have a strong opinion and maybe even a point of disagreement or contention with the team, seek out their viewpoint, try to understand why they have a different viewpoint, examine your own perspective and see if maybe your opinion isn't as solid as you thought it was. Always ask yourself how you can be learning more from the team, and then bring those learnings back to the team. And finally, you have to serve the team. And this gets back to the first two. Inevitably, there's going to be a challenge. There is going to be a tight deadline. There is going to be an outage or an incident. There's going to be a product that launches and it just doesn't work. And in those situations, you really need to be there to back up the team and support them and make sure that they feel like you're with them in whatever hard situation they're facing. There's nothing artificial you can do to build trust. Trust takes time. It takes presence and it takes an open mindset. You just need to recognize that and dig in for the long haul.

Watch my answer on Loom, or read the transcript below! There is a lot in this question, and I think it's necessary to unpack it a bit in order to respond to all of the threads. So really let's dive into this question of managing people that don't report to you. I think there's a lot in that word "manage", and we see a few of those connotations in the sub questions here around giving feedback on a piece of work or getting them to prioritize the product or project you're running. So in this first area, "feedback" - presumably this is constructive feedback. Possibly also constructive feedback around the fact that they're not prioritizing what you want them to prioritize. But it may just be an influence area of they're juggling multiple things. You want them to juggle your thing more than other things. Really, the heart of this to me is communication and being very clear about what you need from the person, when you need it, why you need it, and what the interface is between you and that person. So I'm going to work under the assumption here that this could be someone who's a cross-functional peer, or even more likely given the context here someone lower on the reporting hierarchy than you. So you could theoretically be their manager if you were in their function, but you're not in their function. Distilling this question, it's something like: I need to give manager style feedback, but I'm not their manager. What do I do? And what you do is: you communicate with them as if you were their manager. And when I say that, I'm coming from a position where as a manager, you should not be bossing them and saying: "do this". You should be giving them clear expectations of what you need, why you need it, when you need it by, and also seeking to understand what's on their plate. What are they prioritizing? Why are they prioritizing it? You know, in a lot of these situations, you may find out that the reason why someone isn't actually doing what you want them to do, or they're not delivering work in the way you want them to deliver, is because they have other obligations that you don't know about. And in some cases, those obligations might actually be contra-purpose with what you are aiming for. And by asking these questions, you're going to find out about something that you really should be aware of. And then maybe you can then address a root cause somewhere else in the organization that is causing this kind of downstream effect, that's hindering your work. So getting back to the core question here, how do you manage people who don't necessarily report to you? You speak to them, candidly, you seek to understand what their priorities are and you clarify what you need when you need it, and why you need it.

Watch the video response on Loom, or read the transcript below: So I think the best way of becoming a more influential product manager is to stop trying to be an influential product manager. And what I mean by that, is that influence comes from competence. It comes from successful delivery, doing good work and shipping. Good work is going to build your reputation, and that reputation earns you capital. And then you can use that capital to influence others in the organization, but especially when it comes to product, you're judged by what you ship. That means that your first priority needs to be shipping something good. And you do that by focusing on what's in your area of ownership, what are you responsible for? Become an expert in that, and then use that expertise to ship something impactful and then do it again and again. Naturally what's going to happen is that your scope is going to start to expand. As your scope expands, you're going to do the same thing, become an expert, nail it, ship something solid, the scope expands again. Now the key thing in all of this is that as your scope is expanding, you're making sure to be focusing on the right thing. That could mean delegating to other folks on your team. It could mean at some point hiring there's lots of different ways to handle delegation. The key here is that you are making sure that you are shipping in the most impactful area where you can. Oftentimes that means as scope becomes available to you, and you feel ready to take on that scope, that you expand into it and ship within that scope. And then this naturally leads to influence because you have to start working across the organization as your scope expands. And as you build more and more impactful things, you're hitting more and more of your organization, more and more of your business. So a natural progression for that is that you influence other people by what you are doing, by what you are shipping. Other people will come to you with questions because they will recognize, "that person is being successful. I want to have some of that too. How can I learn what they're doing? How can I be part of that success?" So don't worry about influence, worry about your team's success, and worry about shipping a product that works.

Watch the video response on Loom, or read the transcript below: This question is a tough one. How do you ensure alignment when you have two executives, or sometimes even more than two, who disagree with each other on something that's important to you? Let me tell you what not to do. Don't get in the middle! The middle is a very dangerous place for you to be. You don't have context for what is driving their disagreement and You don't have the authority or power or awareness to even be part of that conversation. Don't try to solve it. It's just going to be problematic for you, and you're never going to solve the issue. So what do you do? Well, you need to get your job done. So focus on what your job is. First, is there a way for you to narrow what you're proposing to find alignment? So constantly re-anchor the conversation on the question that you need answered the, agreement that you need to drive. Oftentimes, the disagreements that happen among executive stakeholders are at least one degree away from what you actually need. Oftentimes several degrees away from what you actually need. So bring it back. Re-anchor. What do you need explicitly? Ask for it. "This is what I need to move forward. Can you commit to this?" Of course, let the conversation go a little bit, because again, you don't want to be getting in the middle and you don't want to be one of the people who are arguing here. You want to let a natural break happen and then say, "let's focus on this one thing." And again, with all of these things, you always need to be clear. "This is the impact I need this today or in the next week or in the next two weeks in order to ensure XYZ, without that ABC will happen." Really focus on the absolute minimal amount of oversight that you need agreement, that you need alignment, that you need to get your job done. Now, in an ideal situation, you don't need to get approval from executives except in potentially problematic one way door decisions. And so I would also encourage you to ask yourself, are you at a place that prioritizes autonomy? And is this a one-time thing, the exception that proves the rule, or is this a frequent occurrence. Because your growth depends upon your autonomy. You need to be able to make decisions quickly, to take actions quickly in order to fail faster and learn more. So yes, solve THIS problem. Everybody has to deal with it. We're all humans working in human organizations, people disagree. This is just how it works. The more responsibility that you have, the higher the complexity of the problems that you face. are the less that you have safety nets. But if you're running into this problem all the time, there might be a delegation and autonomy problem at your organization. If you, you have a larger issue, and one which you need to address.