Indirect leadership is the specific type of leadership that a product manager must display in a cross-functional capacity. It is a leadership style that uses indirect, rather than managerial reporting, to lead a non-reporting team to deliver results. 

In theory, a product manager's role is well-established and there is mutual understanding between teams. In practice, people can disagree with you and choose not to operate under your prioritization. This happens more often than not. A traditional line manager has the organizational tools to keep a person in line under such a scenario, but a product manager does not. In order to lead effectively, the product manager must build strong relationships with each member of the team and learn how to influence them appropriately to operate within the product directive.

The general principles for indirect leadership are:

Indirect leadership, like all leadership, starts with an appreciation for people and the fact that everyone has their own point of view. As a product manager, you will have a very different point of view from everyone else around you because you are responsible for everything in the product management process. You may be worried about business impact or getting consensus for a big project - things that a member of the development team will simply not be aware of or responsible for. In the same way that you must develop deep empathy for the user, you must develop empathy for team members in order to build a strong relationship. Do not assume that they want the same things as you. Take the time to understand what motivates team members, what excites them, what angers them, and what they are trying to get out of their time at the company. 

Building a relationship does not mean being friends, although it can be a pleasant side-effect. It means creating a mutual respect between yourself and another individual as it pertains to the job at hand. Respect must operate in both directions in order for a product manager to be effective. You can always generate respect for another individual by taking the time to understand them and empathize with them. However, do not expect the same from them. This may sound a bit unfair, but it's the reality. You cannot control others, but you can control yourself. At the end of the day, you want to build products that deliver value and you need people to work with you to do it. 

To gain respect from another person, be useful to something they care about. Usefulness creates respect quickly. It is a common mistake for novice product managers to try to gain respect by being nice without being useful. When a disagreement occurs - and it will occur - they are frustrated to find their product direction disregarded. To remedy this situation, do something useful for the other person and show how working together is far more beneficial than working against each other. 

If someone does not understand why something is important or why it should be done, it is very unlikely they will do a good job. Explain the importance of a task and why it needs to get done. Be honest about what you need and don't exaggerate. Exaggeration may work once or twice, but eventually people catch on and they stop listening all together. If you can't explain why something must be done, then it's important that you find that out yourself before asking someone else to do it. It is often better to err on the side of redundancy than it is to not explain and get a bad result. Sometimes this will feel like you're repeating yourself, but that is often necessary. 

If there is a problem with getting team members on board with a project, then try to create a win-win scenario. Because you understand what the other person's incentives and goals are, you can make refinements to a project in such a way that it is a win for the other person. It is important to note that in a company, there are always incentives for greater pay, promotion, and meaningful work. People are affected by these incentives to varying degrees. While the product manager is not responsible for any of these items, a prudent product manager will keep them in mind when designing win-win scenarios. Working with people successfully in any capacity will always include helping them to get to their own goals. 

Providing support and giving credit are essential parts of maintaining strong relationships during your duration as a product manager. Recall that product management is a continuous process. You don't ship something once and call it a day. If you overload someone with too much work without any support or they don't feel appreciated, they won't be so keen to work with you on the next feature and you'll have problems getting your roadmap delivered. Be supportive where you can to help them deliver - take unnecessary things off their plate, provide clear guidance, and get rid of roadblocks for them. When things are finally delivered, be generous with credit. Elevate team members who contributed, even if their efforts were small. In any endeavor, there are many people who work behind the scenes and never get any credit. Even if they didn't ask for it, make sure they get some of the spotlight when the time comes. They'll want to work with you again.

You will work with many different teams and functions in your capacity as a product manager. While you will need to shape your understanding to your specific team and environment, there are some common problematic situations across functions that arise. You may not encounter all of them, but knowing some common problems can serve as an initial way to bootstrap your knowledge until you gain the relevant experience for yourself.

Engineers are generally motivated to build products that will actually be used. Impact size is often the best measure that the product manager can provide to indicate the importance of a project. To the extent this holds, there is often a good relationship between engineers and product managers.

Problematic situations can arise when engineers find the product work boring. After enough exposure to a certain type of work, an engineer may want more of a technical challenge. As a result, the engineer may actively try not to work on features or request different projects from the engineering manager. This can be particularly problematic when a product manager is taking a strategy of delivering a series of small features to deliver large, cumulative value. The small series of features can become uninteresting to build rather quickly, especially if each one of them is rather redundant from an engineering perspective. In these situations, try to offer a new angle to the project: is there an opportunity for some technical challenge?

For example, let's say you want to create different kinds of notifications for different kinds of user behavior. You believe that by creating a series of different types of personalized notifications, you can drive better app engagement. However, the engineer you would like to task this with is not interested in developing the seven different notification types. Another angle to this project can be: if we know that we need a series of personalizations for notifications, is there a way we can design a generic service that allows us to quickly create a custom notification and send it out to a specific subset of users? The difference between these angles from a technical perspective is quite large. The former is a series of somewhat tedious work. The latter is technically challenging to design and just might entice an engineer to see personal value in the project. If it works, the engineer gets to work on an interesting technical problem that aligns behind the long-term impact and you get additional efficiency for future notification additions.

In addition to engineers, a product manager must also deal with the engineering manager, who is the direct line manager. An engineering manager is responsible for the careers and growth of the engineers. For the most part, continued delivery of value helps to grow the team and the individuals within it. Problematic situations can occur when there isn't enough opportunity for the team. When this happens, an engineering manager may prioritize initiatives that show technical proficiency but don't deliver value. In doing so, the number of engineers available to deliver value becomes limited. This typically leads to disagreements about prioritization.

Remedying these situations can take time, but can be done by taking into account the manager's goals, finding a way to be useful to some of those goals, and designing a win-win scenario to make it happen. Because the engineering manager is the direct line manager of the engineers, it's incredibly important to maintain an excellent relationship. Having a bad dynamic with your engineering manager is one of the most miserable situations to be in as a product manager. Identify what the manager's goal is for the team and what they want to get accomplished from a technical perspective. Work with them to come up with solutions where they can obtain their goals by committing support toward the product initiative.

For example, let's say your engineering manager wants to rewrite the whole application stack. It will take a few months and there will be no user or business value generated from this activity. In the mean time, this initiative will tie up resources and make delivering the roadmap harder than ever. Rather than fight the initiative directly, seek to understand why the manager wants to do it. Perhaps the manager believes that a new stack will make it easier to recruit new engineers. Or maybe the manager thinks that the current stack is too complicated to work with and that a rewrite would make it significantly easier for the engineers. If the reasoning has some future value that you can see being beneficial to the team, support it and bargain for some deal that meets both needs. Imagine two different approaches:

This initiative doesn't make sense. We have a roadmap to deliver and this takes resources away from what we need to be doing. What is the business value or user value of this rewrite? It compromises our objectives and it means that we won't be delivering any impact. This is not the correct prioritization.

The engineering manager is unlikely to respond well to this approach. Not only does it fall into direct confrontation, but it also questions the validity of the engineering manager's problem. You must use direct confrontation strategically with your partners. If you have an extremely strong working relationship, you can afford to be more direct. If you don't, then taking such an approach will likely pit the engineering manager against you, making your job harder overall. Even if you win the round, the engineering manager may win the next. Don't let the relationship become adversarial.

I understand. It's really important to be able to hire the right talent. Why don't we write a blog post about the technical challenges of the last few deliveries we had? That might also generate some interest. I can get some help from our marketing team to share it if that would be helpful. For the rewrite, I was wondering, what if we extended the timeline? If we're going to do a full rewrite, let's do it right and make it easier for our developers to contribute. This means our features can eventually be delivered even faster. With the extra time, we can still deliver our promised objectives. Additionally new recruits will probably be excited by the idea of joining a team with strong operational excellence.

The engineering manager is likely to respond relatively well to this approach. This approach acknowledges the validity of the engineering manager's problem and offers some assistance in reducing it. In addition, this approach positions a different angle for prioritization so that it is about a win-win rather than an adversarial fight over who is right. It is easier for an engineering manager to see that such an approach would be sensible to their goals. In the mean time, this means you're also able to accomplish your own.

Designers are generally motivated to design products that will delight the user. User experience is often the most relevant concern for designers. User problem statements will be the most impactful way to express to designers the value of a problem. To the extent there is agreement on the user problem and value, there is often alignment between designers and product managers.

Problematic situations can arise when the designer has a different opinion of what makes for a better user experience. Both designers and product managers are trained with the belief that they are there to speak for the user. So when a difference exists between the designer and the product manager on this matter, there can be a conflict over who really holds the user card.

Having a strong product thinking process solves most of this issue. Because product thinking is quite similar to design thinking, you should be able to communicate your process and how you came to your findings to the designer. Likewise, remain open-minded and ask for the same process that generated the designer's hypothesis. Assess the ideas openly and agree to a common way to determine the best ideas. If the designer's idea has merit, then it's to your benefit to incorporate it because it will increase the chance of success. During this discussion, it's important to make sure that you make the designer feel heard. A designer who feels that their voice is ignored will be unhappy. Designers are responsible for the most tactile version of user experience, and thus want their insights to be heard to make the product better.

The working relationship between a designer and a product manager is heavily predicated on the need for a common understanding of the user. As your understanding of the user evolves, keep your designer in the loop. Engage in user research activities together and take the time to do working sessions to sketch out ideas. You'll gain an understanding for how the designer thinks and likes to work. It also gives you an opportunity to bounce ideas off each other and sync perspectives on the user. If you have a chance to spend time with users, ask the designer if he or she would like to come along. The more opportunity you have to generate the same user understanding, the stronger the working relationship will be.

Sales teams are generally motivated to make their sales quotas. To the extent that the product value and sales quotas are aligned, there is usually a relatively good working relationship because the better the product is, the better the sales are. An enterprise product manager will typically work with the sales team quite intensively in order to communicate the value of the features and get feedback on what is and is not working in the sales field.

It is incredibly important for a product manager to manage the sales team's expectations appropriately. Overpromising and underdelivering is a recipe for a bad working relationship. Sales teams are often under pressure and may take development projections and use them as a promise date to potential clients. When development takes longer than expected, it can look like a lack of commitment or an execution error when in fact it is neither. To prevent situations like this from occurring, it is best to generally give projections as if you were giving them to potential clients yourself. Don't set a date or delivery in stone unless you know for sure that you can absolutely deliver it.

Most problems arise when the sales team pressures the product manager for different asks that help them meet quota, but don't deliver overall value. From the sales perspective, making the sale is the most important thing. If they feel that the product manager is not listening to them, they will eventually escalate sales problems and attribute it to lack of collaboration with the product manager. In an enterprise business this is a bad spot to be in because revenue growth is dependent on making sales.

To remedy this situation, it is helpful for the product manager to identify systematic problems that the sales team is facing and address them holistically. Like with other functions, it is important for an enterprise product manager to spend time with the sales team to understand the pressures they face. Is the product easy to sell? Is the competition stiff? What is the hardest part about closing the deal?

For example, if you continuously get sales asks to build custom demos that eat up your development team's time, it may be a worthwhile initiative to create a self-service demo experience that gives salespeople the ability to customize specific components. Such a solution would provide a scalable way to demo, while still giving the salesperson an ability to customize each account. Now each salesperson can work on their leads faster and improve their chances of meeting quota. A sales team that feels their product manager is understanding of their needs and who provides solutions to their problems is a sales team that will respect the product manager as an expert to have on their side rather than one they should be pressuring.

Sales teams can be great sources of information on how competitive the product is and how well it is resonating with potential users. It's often valuable for enterprise product managers to attend a few sales meetings themselves. Getting a first hand impression of how the product is being sold and how prospective clients perceive it is useful for developing the proper lens for sales asks.

Product Knacks

Leading without authority

Indirect Leadership

Register for complete access