Being a Product Manager is a thankless job, I don’t think so.

I have come across a lot of experienced Product Managers who like to say that their job is the most thankless one ever. Or how product management is all about responsibilities while having no power.

I recently attended a Product Management event where one of the speakers had a very negative outlook towards what his day to day includes and especially towards how engineers treat Product Managers. Interestingly few of the attendees also had questions on the lines of how to deal with engineers when they give a timeline of 6 months for a task of 3 months. Having had a very different experience, I decided to write about it.

As Product Managers we work with different type of people. I categorise them as:

• Leaders/Stakeholders: CEOs, COOs, CTOs, VP Product etc. These are the people responsible for running the business around products we make and setting up long term vision of the business.
• Business and operation counterparts: Marketing, sales, customer service, operations, training etc. These are the people who communicate value of our products to customers, help them use those products and provide additional services that make our product successful.
• Engineers and developers: These are the people who make products we envision possible. For a product manager, this is the set of people who they need to work most closely with.
• Product team: UX and UI Designers, Analysts, Testers etc. These are the people who help us do our job in defining great products and ensuring their successful delivery.
• Users: Customers, End users, evangelists, internal users etc. These are the people who define success of the products we build.

In my experience, different people say thanks differently. They may not go around announcing how you are an important part of the team or how your decisions helped the team achieve success but they would thank you in the most appropriate way possible, they will help you deliver great products.

Engineers and Developers

They are the ones Product Managers end up having a lot of differences. Differences about how the product should be made, what should be made, why it should be made and the biggest of all when it will be delivered. In my experience, there is a lot of to and fro that happens when actual developments start as Engineers face some issues.

Engineers are not supposed to be treated as mercenaries who execute orders. Involving engineers in the decision making process, explaining to them what we are building and why, letting them decide how they want to do it are some of the basic things that can be done to let them feel they are a crucial part of the team. When they tell you it will take more time than you anticipated then try to understand why. Most of the times they have valid reasons and discussing them as any other problem at times help them come up with better ways to solve it. Help them in unblocking the issues they face in day to day development, resolve dependencies and have healthy discussions.

Once you establish to your engineers that you are really an enabler who would help them do their job, you will find your engineers expressing their gratitude in more ways than one. They will allow you to participate in their casual conversations about tech they have with other engineers, they will work late to help you deliver at the promised timeline, they will discuss how they plan to implement a feature instead of blocking you out of the discussion and most importantly they will participate in the product discovery process by discussing user problems, ideating better solutions and building prototypes above and beyond their regular deliverables. That’s how engineers express their gratitude.

Leaders/Stakeholders

Based on the kind of team you work with there are a lot of differences you can have with the leaders. My major difference had always been that the leaders are not obsessed enough about users. They tend to focus on getting results faster instead of doing things right.

Leaders have a business to run. For the kind of teams I have worked with, they are fighting for the survival of the business everyday. While customer satisfaction matters, we won’t be able to deliver that if we are out of business. This is a crucial point my CEO at Dreamkats helped me understand.

Once you start empathising with your stakeholders and internalise the business objectives as a part of your product discovery process and deliver them timely, you will find that stakeholders can empower you so that you don’t feel powerless anymore. In my case, I was invited to be a crucial part of defining the business objectives and the long term vision of the product. In general, once you deliver a few important successes your stakeholders will allow you to take bigger risks and introduce changes in the product discovery and delivery process itself. Their trust is the biggest gratitude you can expect from stakeholders.

Business and Operations Counterparts

These are the people who work to make your product successful. When your product fails these are also the ones who face a lot of slack from the customers. They also act as a crucial bridge between you and the customer. The major differences that occur between business/operations team and product team is on what to build. Sometimes the business/operations team ask for specific features which are continuously ignored, sometimes the products being built require a lot more effort from them than anticipated and more often than not their general feedback about product are ignored.

These people work under their own constraints, building products without taking them in consideration will always make their life difficult. They interact with users at a much higher frequency than you do. Their insights about users are extremely valuable, use them instead of ignoring them. They face problems themselves and they help users deal with their problems, it is natural that they will come up with solutions. You don’t have to build the solutions they demand, understand the problem they want to solve with it and build solutions for those problems because the problems are real.

The best form of gratitude I received from my business counterparts was when they shared personal messages they received from happy customers to me to let me share the joy. But they do a lot more. My operations team has helped me test a few features before building automation tools around them by putting extra efforts to do a lot of manual operations. I was invited by the marketing team in discussions about what kind of experiments they could run to improve efficiency of their marketing efforts. You can feel their gratitude towards you when they don’t snub your products, instead put extra efforts to make them successful.

Product Team

Without their support you are never going to successfully build something worthwhile. They are the ones who give shape to your vision, who ensure that your vision is being delivered, who help you find new opportunities and who help you establish success of your product.

When you feel squeezed in between the leaders and the engineers, these are the people who have to face the slack from you. You would want your designers to come up with a highly detailed design in the time frame to design a wire frame, you will expect your UX designer to come up with insightful design ideas without doing in-depth user research, you would expect the analysts to come up with cool insights and data that doesn’t exist and you will expect your QA to find all the bugs in the product with only a couple of hours of testing. It becomes worse especially when these people actually report to you.

You will always be expecting too much from these people, especially when you are giving your 100%. To begin with, be grateful to them for everything they do to make your job easier. Provide them a lot of information, provide them access to information that will make their job easier and above all create more time for them to do their job. Actively seek their feedback, use their feedback to improve communication and processes. Invite them in the product discovery process and let them feel welcomed.

If your interactions with them make them smile, if they talk to you about their problems, if they never make you ask twice for a deliverable and if they go the extra mile then you know this is how they say thanks to you.

Users

Depending on how you look at it users are never grateful enough or they are always grateful. I like to go with them being always grateful by using our products. But even when they are being grateful it is tough to feel it at times. People don’t write positive reviews often and when they do they surely don’t thank the product manager who made it all possible. But that’s only because they don’t know you. Further, we are exposed to a lot of user issues and negative reviews than the positive ones. If you are making too many bad products you are bound to see only the negative.

But there are users whom you directly interact with, I hope you do. They might be the ones whose calls were forwarded to you by the service/training team, people you decided to call for random feedback, people who have been part of your user research, reference users who help you discover products by actively working with you or people who have signed up to be use your beta version. These people know who is responsible for the features they love and they will always thank you. Directly and in as many words as possible. Some of them will also go the extra mile and act as if they were an employee or an intern helping you build great products. They will become your evangelists and they will ask for features in the nicest way possible. For a Product Manager there is nothing bigger than the gratitude expressed by a user.

When you change your attitude, empathise with people you work with and really become an enabler of those around you then you will see a lot of gratitude being expressed.