Five Ways to Be a PM That Developers Actually LIKE!

Five Ways to Be a PM That Developers Actually LIKE!

Product Managers sometimes have a bad reputation when it comes to Development teams — and we often unintentionally earn these reputations, by the way that we work with them.  There are, however some things that Product Managers can do to build a strong relationship with their development teams — something that is, in fact, essential to the success of the product and your company as a whole.  Here are five tips that you can use to ensure that you have the best relationship possible with your development teams:

1. Give Them Credit for the Work They Do

Product Management is a thankless job – or at least it should be.  One of the best ways to build a strong relationship with your development team is to ensure that when the kudos come around for a job well-done, the PM directs those kudos to the people who actually did the heavy lifting to hit the deadline or to deliver the product as promised — and that’s not you.  It’s the developers, the testers, and the stakeholders who helped you to ensure that you were doing the right thing at the right time, and who pushed and pulled the moving parts until the product was ready for launch.  This isn’t to say that you need to be damagingly humble — but a certain level of humility is necessary, and is a great tool for building a strong relationship with your dev team.  Don’t put them behind a grand curtain that nobody can look behind – let them take a company bow as often as you can.

2. Explain the “Why” and Not Just the “What”

A lot of Product Managers treat their developers like a black box into which you feed requirements and out of which you get (sometimes) working product.  They tend to isolate their developers so that they are only exposed to the extrapolated, abstracted, isolated technical requirements.  They isolate them from contact with stakeholders and users.  In short, they treat them like an entirely separate part of the business, one that lives in the dark and is expected to deliver without context.  And I can’t tell you just how wrong this is — in every case where I’ve worked with my development teams to increase their understanding of the end user and the strategic and tactical reasons for the work that they are being asked to do, the end result has been a better product, a stronger team, and a faster process from beginning to end.  Developers are people too, and like everyone else in your organization, the more they know about the why behind what they’re being asked to do, the better they are at ensuring that they’re working in concert with the strategic and tactical goals of the company.

3. Let Them Solve Problems

The single most important thing that any Product Manager needs to keep in mind when working with developers is that they are called “software engineers” for a reason.  Engineers solve problems — so do developers.  In fact, with the right team of engineers, approaching them with a problem to solve that’s properly scoped for their work can be a motivating force for them.  There’s certainly a balance to be struck between specifying enough detail that the team knows what needs to be done, but without micromanaging the team so much that they don’t feel they have the freedom to work and solve a problem in the way they believe to be best.  Trusting your developers with loosely-defined, but carefully-confined requirements, combined with a better understanding of the reasons for these requirements, is an amazing way to ensure that you’re building a trusted relationship with the team.

4. Be Their Shield and Their Sword

A lot of Product Managers know that they have to be a shield for their dev teams, keeping a layer of abstraction between the daily random requests that come from all across the organization.  But a lot of Product Manager fail to sufficiently stand by their development teams when dealing on the “other side” of the business.  A good Product Manager with a strong relationship with their development team knows that they have to actively evangelize for their development team — no Product Manager should ever throw their dev team “under the bus,” no matter what the situation is.  You need to be the representative of the business to development, but at the same time make sure that you’re actively representing the interests of the development teams to the business.  If the dev team tells you that they don’t have enough time or resources to get something done, you need to take that to the business and explain the reasoning and back their play.  Unless the teams feel that you truly do have their back (as well as play an insulator from randomization), they’re going to have difficulty trusting you and being honest about what’s going on in their world.

5. Be Technical Enough But Not Too Technical

The best Product Managers know just enough about the product, the architecture, and the overall technology that they can tell when the development teams are sandbagging or not being entirely honest in their assessments, estimations, and status reports.  You need to be able to figure out when a dev team is sandbagging on something they don’t want to do, or when they’re underestimating something because it’s new and cool and interesting to them.  This is perhaps the single biggest balancing act that you will face, since if you try to exert too much of your technical know-how you’re going to come off as a micromanaging jerk — but if you don’t leverage it on occasion, the developers just might abuse the deference that you’re giving them.

Back To Top