Post-Covid, many technology companies transitioned towards remote or flexible work environments. While many employees prefer this, working remotely makes it difficult to create strong relationships and trust with new team members and business teams.
In order to compensate for this, it has become even more important to prioritize developing your corporate culture. Work to ask the right questions to team members and organize regular team gatherings and events to help keep things fresh.
I’ve been working remotely since the beginning of Covid. My company values our team culture and regularly schedules events with the technology teams, but we recently realized that we never arrange gatherings with business teams and internal customers. This presents a problem because it’s impossible to lead someone you don’t know.
Leading in product management is different from leading a team or organization. As a PM, you’re leading the atmosphere, meetings, and different project flows. It’s an interdisciplinary process that requires you to be aware of all the individuals that you come in contact with.
In this article, you will learn strategies for leading by example and building trustworthiness, as well as read real-world examples of effective leadership.
For product managers, leadership looks different than other more traditional forms of management. PMs often only directly manage when they serve as the team leader for other PMs. Instead, product managers help prevent the development team from veering off track and work to keep the business team aligned on their priorities.
PM leadership falls into two main categories:
Development teams already have a leader, so as a PM, you’re not their direct leader, but you are responsible for the backlog, roadmap, product vision, and mission. Even in agile environments, you should lead the stories and tasks according to the project plan.
Leading a tech team without a technical background can be tricky. You should always understand the business flow and ask the business team about any gaps in knowledge you discover. A lack of information will cause the team to postpone the feature to the next sprint, which could impact your progress on deadlines.
In grooming meetings, you should create an environment where team members can ask as many questions as they can. You should not be the one talking; feature discussion meetings should be interactive. If no one is asking questions, it is your duty to make them start asking. Remember, you are just guiding them, not telling how they will develop the request.
Leading customers requires more soft skills compared to engineers who seek analytical skills. You should understand their daily struggles and create an understanding to deliver the right solution to them.
What customers want and really need will mostly be different. So you need to lead them by asking the right questions, showing previous behavior, draft flows or mockups. Delivery time will always be the most important thing for them. Be careful not to promise any time before you are certain.
If a customer is asking for delivery as soon as possible, you can set demo sessions and send them regular updates. You should know your customer and act according to their needs. Because you will have limited development resources and doing every customer request as they requested will make your developers burn out.
The promised delivery dates are PMs’ responsibility and customers will not agree to postpone. Delivering a feature earlier may not always be doable for the tech team. While leading customers, you should seek balance between the tech team and them.
Your trustworthiness level will determine your capability to lead them, and all components require effort and time. Like all engineers, I love mathematical formulas. Let’s share a formula for your trustworthiness.
Trustworthiness = (credibility + reliability + intimacy) / self-orientation
Credibility is making people confident about your subjects and requests. What you say and show will not be accepted by the team if you don’t have enough credibility. You will need more proof and data every time (you should already have the data, but not like being an investigation).
You should not be bossy about their subjects. They should feel they are in command, and you are only sharing your knowledge.
Reliability can be achieved by keeping your promises, meeting the deadlines you set, and delivering successful features. If the team sees a difference between the real situation and the version you tell, this will make everything collapse.
As a product manager, you should be as open as you can while trying not to stress stakeholders. Your team can handle tough things, and you can get over it together. Nothing is worth losing your reliability.
Intimacy is my strongest side among these aspects. I build intimate relationships with both tech and business teams. When they feel safe and secure about our relationship, their confidence level increases directly.
I ask important questions about their personal beliefs or share mine to make them feel more comfortable. Leading people is hard because we all are complicated beings. You should be able to guess their emotional concerns and show they are valued and respected by you.
Self-orientation (the single denominator in this equation) is basically the focus. It doesn’t necessarily have to be just you; it might be another person. As a product manager, if you hear those words, you should know what you are doing is completely wrong:
While increasing credibility, reliability, and intimacy, be careful not to increase self-orientation. Mostly product teams are in between the tech and business teams. They do not fully belong to both of them. This may confuse PMs, and they can become a self-oriented person by asking both sides about their needs without paying attention to their dynamics.
To be able to increase your trustworthiness, you should reduce self-orientation. Even a single shadow of selfishness can weaken your efforts. For example, if you ask the development team to develop a feature that is not meaningful and force them to deliver it, you will see the disappointment in their faces. They might not deliver the feature or it will be hard to motivate them for next features.
Product managers do not include the development team by nature. Developers and testers work together in daily routines, just like the business team. So it is important for a PM to set regular 1:1 meetings for the people they work with.
1:1 meetings will help you build trust and strong relationships. The right questions will help you understand their characters and act accordingly. The topic you want to cover may differ for each person. The meeting can cover questions about:
Make sure to come with questions and your undivided attention. Select the questions carefully and pay attention not to force hard-to-answer questions. The 1:1 meetings should be at least 30 minutes and not more than 60 minutes. The date and time should be fixed, and be careful not to cancel your session. Frequency can differ according to need, like once a week, twice a week, or once in a month.
As a PM, you should be careful about the fact that this is their time. Your aim is to listen to them to build a strong relationship and create a productive environment. You can change topics according to their mood; you can ask about their interests or struggles about work. For remote work it’s difficult, but if you are in the office, you can go out and meet in a different place.
1:1 meetings help you lead your coworkers and develop better products. Meetings give you an opportunity to fix problems while they are still small. If you can show you care about them, it will improve their morale, trust, and commitment in the product. Most importantly, their feedback will show you your mistakes. You will be able to ask forgiveness and learn from your mistakes.
In the meetings, if you can create a safe space for their ideas, you will get better results in other meetings with them. After you gain their trust, you will learn what drives them.
Leading in product management is like walking a fine line. You know the customer request exactly, but transferring the request strictly will decrease the quality of the results.
In an important project, I worked really hard to deliver a successful result. I created mockups, UML diagrams, requirements, acceptance criteria with full coverage. I even set the limits and directions (everything I can imagine). This made our project delivery easy and fast.
We delivered an expected result for customer, but during the following months, we realized that there were better solutions and options we could implement.
Over-defined features created a blind eye for the tech team and they focused on achieving the goal I set for them. I realized that if you provide options, people mostly tend to select one, and not seek for another. What I should have done was explain the problem and guide them, not frame the solution itself.
Recently, we completed a project that customers were passionately asking for. While developing the project, I explained to the team how important this project was. We finished everything and waited for customers to use the project.
After one month, we saw that there was no entry to the page. I started to ask why, and customers said their plans had changed and they would not use it in the scope we agreed upon. As you can imagine, the development team started to ask more questions for every detail later on. I lost the reliability I had built.
It was my fault for not waiting for the decisions of customers. I assumed everything would go as they promised and started development as they insisted, but I could have convinced the customers to wait until they bought the device, which would’ve increase usage. To gain more trust for my later decisions, I collected additional data and showed more post metrics for each project.
As product managers, we should lead time prioritization, projects, and the decisions being made. That means leading customers and the internal team at the same time. We sometimes lose internal team trust to make customers happy.
I believe being honest and open solves most of your problems. Customers do not like being in the dark while you are doing something they want. Update customers and gain their trust. Then you can ask favors if there is a technological bottleneck; otherwise, they will insist on sticking to the plan.
Product managers often tend to hide if there is a technical problem. I always inform the customer to take required action for the problem until we solve it. Remember, they are also leading an operation, and they are planning their daily workload.
If you do not inform them, they will make arrangements and protect themselves. Additionally, they will start to think that if there was a problem, you would inform them. If they do not feel you are hiding something, there will be no trust issue. Every project has a problem; there is no need to tell lies.
As a product manager, know that if there is success, it is the entire team’s success; if there is a failure, it’s yours. Take responsibility for your team’s actions. The reason you failed could be a communication problem, lack of information, or simply motivation. And retrospective meetings are exactly for this: ask and learn the problem.
I always reward positive behaviors and thank the team. People tend to provide feedback if there is a problem and ignore the good ones because they assume this is what they are supposed to do. It is a huge mistake; please do not hesitate to point out good things.
Lastly, I don’t like leaders whose characters change, and cannot act the same every day. Being consistent in behavior is important for customers and the team so that they always feel free to ask anything. The answer (or behavior) will be the same every time; this will make them feel more comfortable around you.
The same methods will not work for everybody; we all are unique and valuable. Build strong communications, reply to every question positively, motivate everyone to ask for help anytime they need. Demonstrate a strong work ethic because you are the face of the entire technology team; what you show will represent the efforts they are making.
Do not forget to reward positive behaviors and find problems along the way. Take your lessons learned and continue working. Blaming the team is the worst thing to solve a problem.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Rahul Chaudhari covers Amazon’s “customer backwards” approach and how he used it to unlock $500M of value via a homepage redesign.
A practical guide for PMs on using session replay safely. Learn what data to capture, how to mask PII, and balance UX insight with trust.
Maryam Ashoori, VP of Product and Engineering at IBM’s Watsonx platform, talks about the messy reality of enterprise AI deployment.
A product manager’s guide to deciding when automation is enough, when AI adds value, and how to make the tradeoffs intentionally.
Learn more →
