It Takes All Types: What Type of Product Manager Are You?

Too often the job title of Product Manager is referred to as a blanket term, implying that from company to company the role is a standardized set of responsibilities that will translate across industries and products. Different organizations have different needs and subsequently, call for different PMs. While there are lessons that can be applied to the role, no matter the product it oversees, the truth is that there is a wide difference between the responsibilities of PMs depending on a multitude of factors. In this article, we will breakdown the key components that make up a successful product manager, before diving into some of the differences between PM roles and the responsibilities that go along with them.

So Sayeth the Senior PM

I recently had the pleasure of attending a talk by Charles Huang of WeWork that focused on his story of becoming a Senior PM at the shared workspace company. In his talk, Huang went into his own background before circling back to the lessons and experiences that brought him to his current role. Huang asserts that while there are different categorical traits that make up a PM, different roles will call for strengths across different categories. For example, a Product Marketing Manager will require far more evangelizing and customer-facing work, whereas a Growth Product Manager, will probably be in a much more data-driven role that calls for deep dives into driving revenue and social media analyzation; however, no matter the title of the PM role, Huang believes that there are a standard set of skills that do translate to every PM position.

All Together Now

A PM’s primary job, Huang puts it, is to listen to customers. Often, customers will offer their own solutions while walking a PM through their problems or requests, but a good PM should take time to diagnose the problem themselves. This involves negotiation, gathering data, and then making calculated decisions based on said data collected. Huang calls this process a “mental chess” game, which entails sitting and conducting user research sessions for the sake of understanding what the user is facing as someone unfamiliar with the product from a development standpoint. Watching users struggle through using a feature is the best way of understanding what a feature is truly for, Huang says. When users are befuddled by UX choices or UI implementation, it means that a PM hasn’t done their job correctly and must reassess the feature before release.

A PM should really be all about prioritization. Managing stakeholders and tasks, planning product roadmaps, and crafting a vision and strategy are all very important parts of a PM’s job, but they are not something that each and every PM should focus on. All and none of these responsibilities will take priority depending on the company and product a PM is working for. Different products in different states of release or development have different priorities and a PM should adjust accordingly.

Thanks For Nothing

“Being a PM is not as sexy as you think it is.”

Huang states these words of warning before going deeper into the separation of responsibilities in different PM roles. There are far too many people, according to Huang, who enter into the role for the wrong reasons. Many see the glory of a successful product launch as the driving force behind their interest in the role, but Huang warns prospective PMs to the actual reality of the day-to-day responsibilities of the position. As he puts it, when everything goes right with a product launch, the engineering team will generally reap the benefit of the praise. Yet, when things go wrong, it is usually the PM that incurs the wrath of higher-ups and stakeholders. It is easy to see, after hearing this warning, why Huang cautions prospective PMs to the challenges of the position. While being a PM is not a thankless role, recognition should not be the driving force behind pursuing a career as a PM, Huang says.

Tech vs. Non-Tech

A great PM lives in a space between UX, tech, and business. However, Huang asserts that being incredibly technical as a PM is not a requisite. He believes that it can be immensely helpful because much of a PM's job is communicating clearly with an engineering team, but it also can be a bit of a double-edged sword. If a PM is too technical, they tend to step on an engineering team’s toes and perform some of the engineering team’s responsibilities for them. This is a line that should not be crossed, says Huang.

Huang does believe that a PM should at least be technical enough to empathize with software developers, though. Non-technical PMs can hinder empathetic communication with an engineering team, which can garner feelings of resentment. Even if a PM is not technical, in that they aren’t able to write and refactor code themselves, they should be able to speak the lingo that corresponds to their product. That much will allow clear and open lines of communication between product and development, which will make a PM more capable of performing their job responsibilities well.

What Type Are You?

Everything covered in this article so far makes up the core competencies that a PM should possess. There are many different types of PMs, though, and choosing what type of Product Manager you wish to become should hinge on what you feel you would like to focus on the most. If you like checking out the competition, giving talks, and evangelizing, a Product Marketing Manager role is probably right for you. If you enjoy driving revenue and subscriptions or diving deep into social media marketing, then a Growth Product Manager role may fit you best. If you aren’t interested in the technical side of the position but want to dive deep into researching your competition’s features, then a Business Product Manager position may be ideal. If you want to assess massive amounts of data and make sure that said data is as clean and as curated as possible, entertain the possibility of a Data Product Manager role.

There are more positions out there than the ones mentioned above, but the point rings true for any PM role you pursue. Find out what excites you and then search for a PM role that accommodates that interest. No role will require the same strengths, and every company will require a different perspective on achieving their goals at any given time. A PM role comes down to responsibilities, so figure out your strengths and find something that fits those best.

Lighten the Load

No matter the PM role you choose to pursue, you can make your job easier by making decisions early to lighten the load of your engineering tasks. If your codebase calls for API integrations, one way to ensure a smooth product roadmap is through the use of a Kloudless Unified API. Learning different APIs and the documentation behind them is an incredibly taxing job and can take your engineering team up to 6 months per connection. By leveraging a Unified API in your product, you can connect with as many popular categorical offerings as your users will need in the same amount of time it would take to build a single connection. Steps like these can be the difference between painful pivots or broken future functionality due to API updates.