2 minute read

working_with_others

I was having a conversation with a friend of mine and I could tell he was frustrated with the developers he worked with. As a product manager you are often beholden to the efforts of others to get the work done for you. You do not have any actual power over the people doing the work. They don’t report to you and you are usually in a very different reporting chain of the organization. When it comes to “making” people do the work you need, it becomes difficult and possibly frustrating for some product managers to make progress on their goals, and yet there are some pretty straight forward ways to do so without resorting to the proverbial “kick in the pants” that sometimes pervades a product managers thinking.

My first tactic is to just be an example of hard work. When other people see the amount of time you put in, the effort you dedicate to the product and, as long as you are also putting out quality work, they will respect you and what you are trying to do. That respect can be leveraged in so many different ways, as long as you also employ the next tactic.

You must listen to them. You have to understand what they are working on and their reasons for doing so. There may be some very legitimate reasons for the refactor that needs to be done. There may be some very good reasons for standing up a new server. There may be some very good reasons for introducing a new technology. As long as you understand what the reasons are and if you can truly understand what their goals are, that can go a long way to building a good relationship. And for product managers, relations are the primary currency to getting things done.

Once you have built a good relationship with the development and design teams, you can then begin to negotiate with them. This is where you can share with them your priorities and the reasoning behind what you are trying to accomplish. You can help share with them the goals, the research you have done and, if you have the data, the expected results. This is where you begin to work with the team, not as an outsider, but as a partner to create the best product you can.

As a member of the group you then come up with solutions, priorities and a roadmap for what will be done for the product in the future. You should expect that all the features you want to get in will not. But you should also expect that your highest one or two will. And the team will be more willing to listen to you in the future.

Put in metrics that will help you see if the feature is meeting the goals you have. If not, be willing to kill the feature. Your willingness to allow the data to help you and the team make decisions will go a long way to increasing your reputation with the team and will improve the overall quality of the product as well. The development team signed on to create a product and they want their software to be used. They are successful when the product is successful and they want that as much as you do. Recognize that and build on that common goal. If you do that, you will find ways to get through the challenges you have in working with them.


Photo by Joe Pregadio on Unsplash

Updated:

Comments