Managing Perceptions as a Product Manager

In our careers, we face a different variable – which is how our role as a product manager is perceived. I’m not referring to a macro-level view of a position. It’s about daily experiences in each of our roles when we work with peers in different departments and functions. These are manifestations of subconscious or conscious opinions that coworkers may have of you before they get to know you.

Here’s a hypothetical example. If I were to join another company today as a product manager, what would they think about me before I even walk into the room? What would the marketer on my team think? How about the engineer? Or the designer? Or the analyst, the list goes on.

The more time I’ve spent working as a product manager, the more I’ve gleaned that it’s a good idea to address these perceptions head-on rather than pretending they don’t exist. If you have an inkling of how each function perceives you, you can work to address them and create a much more effective team.

This speaks to two main tenets of my product philosophy: 1) Building outcome-based aka “growth” teams and 2) Valuing emotional intelligence. These are gifts for you to use as you work with your stakeholders.

Here are some examples of why your team will also appreciate you using them.

Building an Outcome-Based Team as an Emotionally Intelligent Product Manager

Learn to involve each team member in an outcome-based team and set clear guidelines and goals to work against. Picture this – you’re the PM trying to launch a new product, and you’re facing tough deadlines to get it out by a certain launch date. You’re probably more concerned about just reaching the production date with your engineering team. On the other hand, you haven’t really thought about the GTM as much as you have about the feature set working.

Wait, what’s missing in this picture? The Marketer.

Most likely, they’re feeling out of the loop and likely a little frustrated. They have been thinking about the GTM of the product launch and how best to market it across PR, social media, and other marketing channels. They’re wondering why you haven’t involved them more in the process. Instead, they’re asking why you have chosen to ignore the function at a time where they could just own it and help the launch.

There is no limit to the benefits that arise from sharing business context with your project team and continuing to be transparent about it.

Let’s take the same scenario as above. I bet the engineering team might be asking a very different question.

Why must this feature be launched on that particular date? Can we push it? Why do they not have a say in it, given that they are the ones building it? Why does it seem like this PM is just bossing them around?

I’m sure at the beginning of the project, you as the PM had involved the lead engineer in planning and setting deadlines for launch. But did you involve the entire engineering team that was going to be working on the feature?

I have found that encouraging transparency and ownership of each function’s tasks actually turns potential conflict amongst different team members into a well-oiled, effective team. Every team member suddenly feels (rightfully so) that they are contributing equally to the success of the feature they are building. In addition, they can attach a tangible outcome (the business context) and get to the 5Ws of every launch date.

• Who is launching this feature? (the team)
• What are we launching?
• When are we launching?
• Where are we launching the feature?
• Why are we launching that day?

Assume the best, and arrive at a common outcome together.

In the middle of the craziness, your designers come to you and say that they are going to be late with red lines for a specific feature. As they come up, you notice that they seem quite firm about the changes that are needed and why the timeline is delayed from prior commitments.

The key here is to remember that the designer does not actually want to hand in anything later than initially promised. One possible reason why this is happening is that the designer discovered a key issue with the user flow during user research and felt it should be part of the initial release.

This is where the product manager can help drive to a common outcome with the designer on board. It’s time to ask whether this design is the only way to get to the intended fix. Is there some balance that can be struck where the MVP goes out without the full set of changes, but they are locked for the next iteration?

Many product managers I have seen forget this option. When there is a will, there’s a way. But there is even more of a way when both you and your team have the same will.

The intersection of product and data is where outcome-based projects become successful products.

Fast-forward a couple of months after the launch. You conducted some A/B test analysis before launching the product to 100% of the population. However, your product didn’t fare as well in the market as you initially thought. A data analyst performs historical analysis and finds that the feature actually negatively impacted a core app metric and the metric was not tracked while A/B testing the feature.

How did this happen?

Finding out something this late in the game means one of two things happened.

1. That data team was not involved early enough in the game to properly set up the A/B Test.
2. That the metric was known but not acted on.

In either option, it leads to a poor interpretation of data during the critical point of the feature launch. The data team at this point would most likely think poorly of the product manager and make some judgment that the PM is not data-driven.

Emotional Intelligence is the true key to PM success

Emotional Intelligence is possibly the most important trait of effective, collaborative Product Managers. By simply being aware, you can address most challenges with people rather than by yourself. It’s how I’ve been able to forge relationships that are more than just role-directed. Instead, they are based on true faith in the value each member brings to the team.

Henry Ford once said, “Coming together is a beginning, staying together is progress, and working together is success.”   

It looks like nothing has changed since the Model T.

Click here for our latest blog posts