It all comes down to influence.

The number one skill a product manager needs, above all else, is influence. Without influence, no matter how well you do your market analysis, you will utterly fail to get that product built. There are many occupations where talent can out-weigh the preverbal ‘jackass’ diva employee, especially if the rest of the team can isolate you. I’ve seen a couple of these divas do well. But never have I met a kickass, jackass Product Manager (please correct me if I’m wrong). This case is simply true because those who cannot influence their team towards a common mission and goal in an ultra-positive way will never produce great products.

The good news is, everyone can learn the skills required to have influence. Granted, for some, it will be harder than others. You will need a lot of humility and patience to grow people skills. But if you truly want to be a leader and influence people without outright authority (read fear), you will need to learn to be a humble, transparent, useful and above all, a lovable human being.

The following are the top 5 qualities I believe will get you on your way towards having a development team that respects and loves you as their product manager.

1) Listen, Take an Interest in their Work, Be Humble

I’ve heard pros and cons on both sides of the debate whether or not Product Managers should be technical enough to write code. However, let’s be clear what the product manager’s real purpose is. The product manager’s job is to determine what to build (product/market fit) and to get it built (design/development/launch).

My belief is simple. Product managers need to be involved in the development process, but they also need to know their place.

As a Product Manager you should:

Listen to the development team

Get the code on your computer

Learn to read and get the gist of the code

Walk through code snippets with developers as often as they let you (don’t annoy them)

Follow the check-in repository and comments

Be humble in knowing it’s the developer’s role to create the software, not yours. i.e. you are not the developer, don’t play one (even if you used to be one).

Trust the development team and their feedback, time estimations, etc… (If you cannot trust your developers, either you have fundamental issues, or your Dev team has fundamental issues, but someone needs to go.)

Solicit feedback on the entire product (not just development issues — i.e. business and design issues) and sincerely listen to the feedback

Developers want to be told what to build by you, leaving the ‘how’ up to them. The only appropriate time to provide thoughts on 'how' is when it is a requirement specific to the product.

2) Give them Details, Help them Focus

While it’s the developer’s job to build the software, it’s the product manager’s job to tell them what to build. Sometimes there might be a middle person between the product manager that helps in this process, who is often called a product owner. There will always be requirements discovered throughout the development process that were not anticipated, but this can be greatly reduced by thinking out and creating exceptions, edge-cases, trade-offs, etc… that the developer might not be aware of. All of these details create the ‘bowling lane bumpers’ so to speak that keep the development on-track. Development, when given details, build what you request, when details lack, their creativity ensues, and you might not like what you get back. Thus, working with development, being near them and helping them through the development process not only helps you understand what details they are looking for but helps them ask questions keeping them on target. This is one of the reasons I highly encourage the whole product team, including development, sitting together.

Details I’ve given as a product manager:

User Stories

Acceptance criteria

Documentation

3) Give them Context, A Clear Vision, Show You’re Calm and the Product is in Control.

While the previous point was about giving them details and helping them focus, here I’m almost saying the opposite. I want the development team to get the big picture, and a lot of product managers neglect to do this. Everyone on the product needs to understand the big picture so that the micro-focused decisions will always be in alignment with the macro purposes. It is often the case that context can give the development team insights not only on what to build but how to build it keeping in mind future purposes and goals.

An added benefit is that this reveals the decisions made by the product manager are in alignment with the product’s future (assuming they were made correctly), and that the roadmap is truly a plan for the future. If all is done correctly, all of this evidence not only gives the development team confidence that the product manager is doing the right thing, but it also shows them that the product manager is informed, calm and collected and that the product is under control in the right hands. When the crew sees the ship is going in the right direction, there are no mutinies.

Context resources I’ve given as a product manager:

Product Map (This is a document I created, See the article I wrote on it here)

Roadmap

Stakeholder feedback/interviews

Personas with ancillary info on how they were created

User Interviews (video, audio, summaries)

Asked them to sit-in on user research/usability testing

User insights and utterances

Asked them to be part of product meetings

Development does not need to use or go through all of these resources, but making them available goes a long way to the team trusting and loving you.

4) Take their Pain

Let’s be honest. Developer’s, like all people, hate to do some things. It should be the goal of the product manager to remove any hinderances to the development team. This is where you can jump in and help. If there is something that is encumbering the development team, that is out of their job focus, and you can do it, or find someone to do it, do so. Whatever it is, take the pain away from the development team so they can do their job and get it done. Helping the development team helps the product. Be the development team’s advocate. Help them get what they need to get the job done. This is the job of the manager of the product, do what needs to be done to get the product made. If there isn’t an expert for the role, you become the expert. If there is an expert, get that expert.

As a product manager I’ve:

Acquired tools and resources (books, software, etc…) the development team needed

Cooked, made or got my team food

Counseled them on personal matters ( sometimes pain is real pain )

Cleaned their desk

Dealt with other departments bugging them

Edited writings and wrote on their behalf

5) Be a Great Human! Have Empathy

This is the most important of all steps. I’ve never been a believer that work is all ‘professional’. What I mean by this is that the people you spend the majority of your time with 8+ hrs, 5 days a week, are going to be more than simply professional relationships. They are either going to be your friends or not your friends. The dynamic you instigate is going to set the tone for the work-place environment. If you want a culture of transparency, and trust where you hear the good and the bad before it impacts you or the product, then you’re going to need to deal with personal relationships. Let’s not forget, developers are not ‘resources.’ They are not ‘assets.’ They are people. Whatever you do, do not dehumanize them or their role. People have good days and bad days. You too will have good days and bad days. You’re going to have to learn to give and receive grace.

One of the most important skills that a product manager needs to hone is his or her ability to have empathy for their users. More often than not, though, we as product managers forget that we need to have empathy for our company and for our team. This empathy will either help the product succeed or fail without it. Sometimes emergencies happen and we need to work extra hard or fast, and whether or not we have displayed empathy beforehand, will be part of the determination on how the team reacts to those emergencies.

As a product manager I have:

Taken walks with coworkers out of the office to hear their problems with another coworker (not to gossip, but to just be that listening ear, sometimes people just need to vent and let it go)

Taken the blunt of the frustration towards the customer, so that the developer can vent and feel heard, and the customer can be informed in a better way

Told coworkers, go home and take the day to rest, or deal with whatever family or other problem you need to deal with

Taken the team out to celebrate victories, whether small or large, sometimes you need to celebrate!

Given a motivational talk when the bad news hits, sometimes an emotional reset button needs to be pressed before digging into problems.

Thrown dinner parties and social events to help the team gel better together outside of work

Baked cookies and brought them in for people

Mourn with those who have lost something they loved

Given free hugs, because sometimes, you just need to be hugged, oh yes, developers too

Summary:

Being a product manager and running a product team is often described as being the CEO of a product. I couldn’t disagree more. Unlike a CEO, we have no authority. All of the product manager’s power comes through influence. Neither are we the parent of the product. It isn’t our baby. When it comes to the product itself, we are a doctor, prescribing what is best for the health of the product. But when it comes to the product team, I believe we are the mothers. I don’t know about your mother, but the mother’s I know are the framework that holds the house together. The dad might be the authoritarian, but the mother is the nurturer. She holds sway by her influence. The mother’s most powerful and natural gift is that of empathy for her children. And for that empathy, she has the devout loyalty of her children. So here the metaphor ends, as developers are not your children, neither are designers, nor anyone else on your team. But like a mother, as a product manager, you need to do the things you need to do, even sacrifice, not only to get the product built but to make sure everyone gets there successfully with the product, in an emotionally healthy state.

It has been my honor all these years to lead developers, whether as their manager, CEO, or now as their product manager. I have learned if I do the above things, giving each developer the respect and dignity of being an intelligent human being, and the trust that they are going to do a great job, that they will, in turn, do so while giving me the same respect, trust, and friendship. I hope you are blessed with the same developer relationships that I have had throughout the years.

This article can also be found on my Medium Blog.