For a product manager to be successful, they must be viewed as both credible and trustworthy. Without that confidence, product managers can get stuck in an ongoing cycle of attempting to quash doubts by revisiting topics over and over again because they haven’t secured buy-in on the product strategy and the related ideas, projects, and initiatives. That’s why the most successful product teams build trust with internal teams.
A lack of trust from developers and engineers creates endless second-guessing, challenges, and sometimes even a refusal to follow through on requests, which becomes a huge timesuck and morale destroyer. If the executive team doesn’t have faith in product management, ideas are likely to be ignored, plans overruled and cachet denied. And when operational teams distrust product management they’ll become another faction out to derail initiatives rather than supporting them.
No one wants to work in such a negative and confrontational environment, and it certainly won’t help your product device and deliver game-changing strategies and growth. That’s why product teams must invest the time and energy to build trust with the rest of the organization.
Since trust must be earned and product teams aren’t given the benefit of the doubt by default, they can use some of these methods for building trust internally.
9 Ways product teams can build trust with internal teams
1. Tell your engineering team why (not just what)
Executives aren’t the only ones who care about business cases. If you’ve been operating under the assumption that engineers just want to build stuff, then you’re selling your technical team short. They may not want the gory details of ARPU calculations and markup percentages, but they definitely want to know why what they’re building will help the company grow, whether it’s revenue, users or usage.
You should have already figured out the business case of items on the roadmap, so don’t be afraid of sharing that perspective with your technical team. Understanding the “why” and the upside is a great motivator. And, this context might even positively impact their implementation choices.
“Leaders must get across the why as well as the what,” writes John Doerr in Measure What Matters. “Their people need more than milestones for motivation. They are thirsting for meaning, to understand how their goals relate to the mission.”
2. Give technical teams customer exposure
As a member of the product team, you’re talking to customers on a regular basis and hearing first-hand what they like and dislike, what they desire, and what they don’t need. But by the time that information reaches the engineering organization in the form of a requirement, the rationale may be stripped away and the developers may not share your opinion that it’s worthwhile.
“Engineers often feel disconnected from the customer’s use case, believing instead that the product they are building is desired by one and only one person: the product manager with some grand but delusional vision,” says Michael Bamberger of OptimizeIQ. “By nature, engineers are analytical and skeptical and will doubt the validity of a product without being able to vet the decision-making process. Knowing the “why” behind a product not only builds trust but increases motivation.”
Letting developers have some customer exposure is a great way to minimize this disconnect and prove that you really are generating requests based on actual market feedback. While they don’t need to be on every call, letting them listen in occasionally is a great opportunity to provide some transparency and build trust.
3. Remember that trust is a two-way street
“Do unto others” applies to this setting as well. If the product team is constantly questioning whether another group is able to do their job, over-managing and not providing enough space, they’re not showing that they trust that team or those individuals to be successful without their constant oversight. If you have properly communicated your vision and provided context into the “why” behind decisions, your work is done. You don’t need to micromanage or question the “how.”
This lack of respect doesn’t build a relationship based on trust. So if you want to be trusted, exhibit that same behavior in return. Otherwise, you come off like a dictator.
4. Invest in relationships
Your coworkers aren’t all robots—at least not yet—and most humans are desperately seeking meaningful connections with others. Keeping everything at a purely transactional level doesn’t imbue your colleagues with the warm-and-fuzzies that can pay off down the line.
The only way to truly build empathy is to connect with other teams on a personal level, which is why companies go on outings and schedule team-building activities. While “mandatory fun” may not be how you want to spend your day, getting to know people outside of the conference room and cubicle setting can strengthen relationships and make people more likely to trust you.
5. Be present and available
We all want to feel like we’re in this thing together, and your presence is an indicator that this truly is a collaborative relationship. So don’t chuck a requirement over the wall and wait for QA to check in on it.
“When an engineer gets blocked because your initial story didn’t describe expected behavior, you need to unblock her,” says Adam Sigel of Boston Product. “If you haven’t been attending standups regularly, that can be tough.”
This can extend to literal “togetherness” by physically locating teams that work together in the same place. The casual interactions build stronger personal relationships, which helps out with building trust. Plus the easy availability bridges the distance that can form between different teams.
“Due to physical proximity and actively getting to know one another, product managers and engineers are more open and honest with each other,” says Heidi Helfand of Procore Technologies. “Product managers get a daily or even hourly understanding of where things are at. Everyone is present together in their work-area and at regular team events.”
6. Don’t hog the spotlight
You might be “CEO of the product” but that doesn’t mean you must always be the star of the show. Leadership doesn’t require being the center of attention.
“One of the top ways PMs damage relationships with engineers is by hoarding all the credit. They claim that they thought of all the ideas and make sure they’re always the ones presenting to executives, leading meetings, or announcing results,” says Jackie Bavaro of Asana. “They act like they’re the most important person on the team.”
Instead, you can build trust by allowing others to present results, demo to executives and share in the glory of a job well done. Demonstrating that it’s not all about you shows you care about the other team and building up the image of the entire organization, plus it might just add to the credibility of your proposals.
“Tech leads are often your strongest ally when pitching new projects and opportunities to company stakeholders,” says Sebastian DeLuca of Doximity. “The marriage of a PM’s product intuition with a tech lead’s technical expertise and vision is a powerful combo when lobbying for your team to take on new and exciting responsibilities.”
7. Ask questions
Product managers are supposed to have all the answers, but they’re not supposed to be psychic. There’s no shame in saying “I don’t know” and asking for help, information or advice—this actually improves your perception by others because it shows you’re actually listening and actively seeking out the opinions of others.
“Information is cheap and easy to access – just Google it. Being able to synthesize this data to make a robust decision – that is a much rarer skill,” says Guarav Gupta of Kotter. “Your willingness to admit when you don’t have all the answers and your curiosity to find them will lead to better decision making and greater trust within your team. This authentic approach will speak to your character as a leader.”
Asking questions also shows that you both trust and value what others have to offer. If they feel appreciated and understand you’re gathering information from multiple sources it increases how much they’ll trust your final decisions.
8. Don’t fear failure
Infallibility doesn’t always breed trust, it can just as easily inspire resentment and make you seem unrelatable. Showing that you’re human and willing to admit your mistakes can actually improve your overall standing.
“Most teams have been burned by that irrational PM or founder that keeps shipping junk no one wants. They view all new PMs with that lens, assuming they’ll rack up technical debt and cognitive load on the organization with a million failed experiments,” says Drew Dillion of Skedulo. “Do a couple of little experiments, right when you start. Make these experiments highly measurable and explain the KPI ahead of time. Announce successes and failures, but be sure to really hammer those failures.”
And when failures, setbacks, and shortcomings occur, don’t try to sugarcoat them for stakeholders. Instead, give them the proper context in the overall narrative.
“Only sharing the good — and hiding the bad and the ugly — can backfire,” says Alexandra Edelstein of Klaviyo. “Highlight what is going well, and frame challenges in the context of what you’re doing to navigate and solve for them. When scope changes or timeline shifts may be required, engaging the right stakeholders at the earliest opportunity can often lead to unexpected resolutions.”
9. Don’t take trust for granted
You’ve worked hard, followed all the great advice above and the product team is now a trusted part of the organization. Mission accomplished!
Just remember that trust can disintegrate in an instant if those principles are neglected. As soon as product team members start going freelance and ignoring the tactics that created a trust, to begin with, it can all come crumbling down. And rebuilding trust is way harder than creating it in the first place.
