How To Build Trust Within Your Product Team & Get Stakeholder Buy-In

Read the Transcript:

Hannah Clark: Let me set the scene: you're in a meeting room with all of your key stakeholders. You look to your left to see the Account Director wrapping up an email. On your right, the Head of Engineering has their arms crossed and is eyeing your pitch deck warily. You're also pretty sure the Lead Product Designer is judging the layout of your slides. Somehow, some way, you're going to have to convince all of these people to move in the same direction. But before you can do that, you need them to trust you. So how can you win that trust and get buy-in? 

Today I'm joined by Noa Goldman, Lead Product Manager at DagsHub. Noa's career started in software development, so she's been on both sides—which means she knows how tough it can be to win hearts in cross-functional teams and end up with a strong solution to customers' problems. Noa shared her recipe for winning stakeholders over building up relationships and strengthening the output of the team. Let's jump in. 

Thank you so much, Noa, for joining us. 

Noa Goldman: Thank you. I'm happy to be here. Thank you for inviting me. 

Hannah Clark: Yeah, happy to have you. So Noa, you have a background in software development, which I'm sure has come in handy in so many ways. But I would love if you could give us some information about how it's influenced your approach to product management.

Noa Goldman: Sure. So I was a full stack developer for eight years. Part of it was my army service. Part of it was small startups and big corporations. And then I made the transition into becoming a product manager and my expertise today lies in the world of developer tools, which it helped me to be a developer in this area. 

And it influenced me a lot, obviously, first thing, it really developed a strong habit of thinking about the user and the buyer persona as well. I know this is something that most product managers say that is really important to them, and they constantly think about the user and the buyer persona. And from my experience, often they don't.

And for me being a developer and now being a product manager for developer tools, I always think about both the user and buyer persona. So for example, if we have a new feature that we wanna release, or maybe we have a new product that we wanna launch, so I will always think about myself trying this feature out. How would I feel about this feature?

How would my colleague feel about this feature? How would we use it? What are we measured by? This is something that is really important that I feel is being missed out a lot of times. When you release a specific feature, you always wanna think about how the user is being measured, like according to what and will this feature or this specific product will help the user improve or will help them in their measurements and in however their management is feeling about them in that specific use case. 

And so it obviously influenced me and my habit of thinking about the user persona, but it also helped me a lot when it comes to the buyer persona as well. Because again, I feel like this buyer persona is something that is constantly being left out in the process of releasing new features and product.

And when we try to launch a new product I will always think about, Okay, who are the people in the purchasing flow, like who are involved? Who is supposed to make this decision? For example, I think about myself. As a developer, I would come to my team lead with a new feature or a new product, and I would say, Hey, this is cool.

And those team leads, they would say, Why it will help us or why should we pay to this specific company? So I always try to think about those personas as well. So this is a very big part of me being a product manager, but my background as a developer, it really helped me with. And I also think it influenced me a lot when it comes to prioritizations.

Because for every new feature, I don't always have to go and ask the team lead. I feel like this is a process that can be a little hard for the team leads or the R&D leads when the product manager is constantly asking them how long it's gonna take or what are the efforts. So I feel like it's something that I can do pretty much on my own to a certain extent.

So that helped me a lot and influenced me a lot. And, but I think the most important thing that I took from being a developer is their relationships with the other developers. Because I know how I felt about the product manager as a developer, and I know how my colleagues felt about them. And it's not always, nice and fun and they don't always agree with them. 

And I feel like what I took out of this is I want the developers that I'm working with to feel good about me and to want to help me. So I know how important the relationship is, and I know, or at least I think I know how to gain their trust so I know how to choose over what to fight and what is more important and what is less important. And I think that, this trust, realizing that this trust is important really helped me a lot because I was a developer at first. 

Hannah Clark: So I'd like to hear a little bit more about that, like if a product manager listening is trying to work as well as possible with their development team, they don't want the resentment, they don't want that tension, what are some of the best practices that PMs can keep in mind for working effectively with the development team? 

Noa Goldman: Yeah, okay. So there are obviously a lot of conflicts at times, and it can get a little frustrating for both sides. Me being on both sides also, I know this very well. I think one of the most important things is to always explain the why, explain and connect them to the business side.

We, as product managers, being in the middle of everything, we constantly talk. We constantly stick with the marketing team or with the sales team, or with the higher management. And developers, not often do. And when you present something that you want to develop to the developers and the R&D teams, it's really clear to you as a product manager what you want and why you want it and how it's supposed to help the company. 

But the developers that hear it for the first time, they will not necessarily connect the dots. So it's really important to explain the why and connect them to the business side. For me specifically, I know that if someone comes and asks me to do something, I will not always agree because I'm not sure why. But if I'm being explained why and what is the reason and how it's gonna help the company, that I'm most likely going to be on board or at least open for a conversation, and I think this is a really important thing. And as product managers, most of our work has been dependent on others.

We barely do something that is developing a feature or doing the marketing. We always have to explain to others what we wanna do. So it's really important to explain the why and connect the dots in terms of the business side. And I think that it's also very important to show the data. So if you explain why and you explain the business side and how it's going to help the company grow, you need evidence, you need to back it up with the right data.

I, I'm sure everyone or most product managers will say they are data driven. But in this specific moments, when you show it to the development team, it's really important to be data driven. Because again, you want them to trust you and you want to gain their trust and you want them to be on board. So this is another very important thing that I would say.

And another thing that I've learned with time is it sound weird, but just give kudos. As I said before, a lot of our job depends on others. And when someone like a developer is on board and doing the hard work and developing a feature, it's really important to acknowledge that and appreciate that and give kudos and give like, "Good job", "Well done" one-on-one, but also in a wider forum so everyone will know.

And for me personally, when someone appreciates my job, I wanna do a good job, like I wanna continue and help. So I would say those are the things that help me the most when connected to the development team. 

Hannah Clark: Yeah, I think the kudos thing that's so important, I think in just about any role, and it's one of those simple things that people just seem to neglect that just make such a difference with any kind of cross-functional collaboration.

But on that topic, so when you're thinking about collaborating with cross-functional teams beyond just the development team, what are some of the best practices that you found to be useful to ensure that your feature development is working smoothly and everybody is on the same page regardless of their area of competency?

Noa Goldman: Yeah, so I remember one specific feature that really helped me to create my own recipe for how to deal with long-term features that requires a lot of efforts and time. And it was a specific feature. We did the, we improved the onboarding in a company that I worked at as a product manager, and we actually were able to increase the conversion rate from 15% to 90%.

And it was amazing, but it was a very long journey. And I was a junior PM, so working with cross-functional teams and working with marketing and sale and high management was really tough for me. But this is where I created my own cookbook on how to do that. And the first step for me, it's even before you present the new feature to the team, is just making sure the motive is right and this is the right thing to do right now internally.

So me, with myself before I want to present it to others, I wanna be confident and make sure that I'm doing the right thing. So regardless of high effort features, I always try to make sure I read the map correctly, if it means always listen to the business side and the request, and keeping a list of user features, requests, and seeing users how to use the product.

So I always try to make sure I have a map of how things are right now and what is important to the company and what's not. And when a huge feature comes in, so the first thing that I do is make sure with myself that this is the right thing. So I compare it to the map that I have and I make sure, okay, this is the thing that makes more sense now to do and I'm fine with this and this is what we are gonna do.

So I make sure that I am okay with this decision. And after I did that, I double check myself with the data. So I make sure the numbers make sense. I clean them up really nicely and I go over them and I make sure that the numbers make sense and to and doing this specific long-term feature, it's going to increase or increase the number, whatever you wanna achieve.

But I make sure the data is right and make sense. And I also, by doing this, I making sure that it's not just me falling in love with a specific feature. The data actually convinces me that this is the right thing to do. And after I did that, after I'm fully convinced that this is the right thing to do, I find a very clear way to present it. And it means that I try to create a one or two sentences on the problem and why it's important to solve it right away.

And those sentences supposed to explain it to the both most technical person in the room and least technical person in the room. Because it's a cross-functional team effort, then I want to sales marketing, high management, R&D team leads to all understand very clearly this is the problem, this is how fixing it going to help to improve the business.

So I make sure I present it really clearly to a four year old, and then I take the data that I already cleaned up and I present it very clearly. It sounds weird, but it's always, you have to make sure like the data is well defined and well presented. For example, green is good. Red is bad. Use the right graph.

Like those are things that sound really trivial, but they often not being presented right. So I make sure the problem and the data that backing it up is presented really nicely, really clearly, so everyone in the room will understand it. This is the second step. The third step sounds weird, but it's called in my book, it's called Divide and Conquer, which can have a little negative meaning, but it's not negative at all.

So this basically means before I present the feature to the whole room, to the whole leads of the cross-functional team, I try to have a one-on-ones with each lead from each cross-functional teams. This is going to take me a lot longer, but it will be worth it. So I will sit individually with the head of marketing and head of sales and head of R&D and whoever are involved in this process and whoever I need to convince to be on board.

And by doing this, I first of all, make them feel heard and listened to. Because as I said before, if you want to get someone on board, they don't have to listen to you, they don't have to agree. They have other stuff on their minds. If you wanna get them on board, you have to make them feel like they count and they are important.

So, sitting with them one-on-one, have a quick or long conversation or whatever you need, even if it's going to take a little longer for you, it will be worth it. So it helps them feel heard and once they feel heard, they wanna help you. And the second thing that it does, it really prepares me for the second step, which is meeting with everyone in the same room.

Because I already know how everyone's are feelings. I'm prepared with my answers to what they're gonna say. And I know how they're gonna answer to what they're going to say regarding this feature. And finally, those one-on-ones will just help you because others often have really good ideas and you want to integrate them in this feature.

It will obviously will make them feel more a part of it because their ideas are count, but they might have good ideas that you wanna hear. And by doing this and performing those one-on-ones will actually help you create a better feature that most team will be on board on developing it. So this is a step, having a one-on-one with each and every one of them.

And by this steps I, at least from my experience, most of the people involved will already be on board at this point because they feel like they are a part of the process and they feel like they're being heard. And the step after that will be team meeting, get everyone in the same room. It's a little tough.

It makes you a little nervous, but you're supposed to be prepared by now because you had all those one-on-ones. And you sit them all in the same room and you gather them and then you just present the same thing that you presented on the one-on-one. If you remember from the previous steps, you have those one or two sentences that really describe the problem very simply, and you have the data and you already spoke with each and everyone within this room. 

So you just, you do it again and you present it again. And by this time, most of the people are going to be on board or at least open for a conversation. And what do you want in this meeting is, first of all, make sure everyone on are heard in the same forum, in a wider forum, and get the agreement of most of them.

You're never going to get, or almost never going to get the agreement of everyone in the room, but when they all feeling like they're heard, they're at least open to the idea. And by this step, most of them should be on board right now. So this is the final step of making everyone on board. And the steps after that are just what I like to call taking the stage.

So everyone on a green or on developing this feature and the process is already getting along, you want to make sure you'll always update everyone. So take the stage, whether it's weekly or monthly, or use an already existing sync and take a few minutes just to update everyone. I like to always show the visual changes.

I like to divide a huge feature into smaller, quick wins. So we will be able to visually see the changes and the progress. And by updating everyone, they keeping the engagement going. They want to hear about it, they see that we are making the progress, and it really helps. And it's also a good opportunity to show the data if the feature is already released, show your success and failures.

Just make sure that you're being really clear and really honest about the process and everybody will be on board. And it's also a great opportunity to again, hear their thoughts, hear their ideas, hear what they think about the progress we already made. And doing that along developing this feature, it's basically what's supposed to help all the cross-functional teams be on board constantly and wanted to help.

Hannah Clark: That's a great process. I think that's also very clear to follow. I am curious though, so what happens or what's your approach when you have a little bit more of a split room, or if there's not full agreement across the board, or not enough of a consensus across the board for a feature to move forward, how do you handle something like that?

Noa Goldman: Okay, so if I'm sure this is the right thing to do, and if I'm sure it makes sense for the company, I always try to think about the fact that eventually we're all in the same team and we all want the company to succeed. So I try to again, try to divide and conquer, try to explain the business and the why, and try to convince them that we're all in the same team.

And eventually it works. If it still doesn't work, I try to pick my bottles. So for example, yeah, so if someone is not on board, I try to like choose how I'm going to convince them, whether it's letting them to have other features, maybe it's helping them, to push their agenda in a certain ways.

Again, it's all about, to me, it's all about the relationships. So when you help someone, they will often want to help you back. So it's navigating through those negotiations and make sure everyone gets what they want eventually. 

Hannah Clark: Yeah, that makes sense. So switching gears a little bit towards prioritization, as I always say, a huge, when we're talking about managing, developing features, feature prioritization always is a big part of that. So what are your sort of secrets to success or some of the methods that you've used for prioritizing features? 

Noa Goldman: Okay, so I have my own north star metric, which is the business. Whatever the company needs to grow, this is my North Star metric. This is what I will compare it to, eventually, at the end of the day, my work is to help the business grow and help the company grow.

It's not about what features I love or what my teams want to develop at this moment. It's about helping the company. So, I describe the map that I always have. I constantly keep track of what users are requesting and I constantly keep track of the business requests and what marketing wants and the whole market.

And I try to think about the business. And for each and every feature, I will say, okay, is this the thing that will help the company grow the most right now? And if it makes sense, and if this answer is yes, then I say, okay, and then I ask the next question, which is this the easiest way to develop this feature?

So in terms of prioritization, I will always choose what helps the business the most and what is easiest to develop and needs less efforts, I would say. So those are the two questions that I will ask myself. And if you are able to answer those two questions, you are able to prioritize everything.

Hannah Clark: We're almost outta time, but I did want to end on something a little bit more fun. One of the things that I've been asking a few of our guests now is about music and it's a bit of a left out of left field. But whether you're listening to music on the job or outside of the job, is there an artist or an album or any kind of music genre that you're really into right now?

Noa Goldman: Wow. This is a very fun question. I'm so happy you asked it. I'm not even sure why I'm so happy. Yeah. So I definitely listen to music constantly all the time. I try to do it while I'm working on things that are not required a lot of thinking because otherwise I get confused. And my main artist that I'm listening to right now is Paulo Nutini.

I'm not sure if you heard of him, but he's great. He just released a new album that I love and my dream is to see him playing at a concert, which probably not gonna happen, but I'm gonna work on that, so we'll see. 

Hannah Clark: Oh great. I haven't heard of him, but I'm hoping that we can put together a Product Manager podcast playlist for, from all our guests, so. 

Noa Goldman: I would love that. 

Hannah Clark: Yeah. So, I'd love to check him out. Well, thank you so much for joining us today, Noa. I really appreciate the time and I love that you gave us a recipe that's such a great and easy to follow kind of format for us to gain some real concrete knowledge. So I really appreciate your time here.

Noa Goldman: Thank you. I enjoyed it a lot, really. Thank you so much. 

Hannah Clark: Thanks for listening in. For more great insights, how-to guides and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to the Product Manager wherever you get your podcasts.