The 3 types of Product Managers

Working as a Cloud Native Consultant taught me so many things, ow boy, soooo many things. But surprisingly, most of these things weren't actually technical as one may expect. Sure, I did learn a lot about Kubernetes itself and all aspects of building good architecture in the cloud. But I'd say that this was maybe 30% of the stuff I learned. The other 70% was politics and business :) I've said already a few times that Cloud Native Transformation is about changing people's minds and processes much more than about building Cloud Native tech. So here's a short writeup on one of these random non-pure-tech things I learned over the course of the last 5 years.

So, today we're gonna talk about Product Managers. It's possibly the most "weird" position in the IT world. Why? Because of a few things.

First of all, it's the one that is least "clear" in the sense that PM can have very different goals and ways of working depending on the type of business and situation. There are 3 main "types" of PMs from a business perspective (but these are not the 3 types I was thinking about when writing the title, that will come later in the post):

• Internal PM - Product Manager who is responsible for a product that is only used internally within a company. So, for example, PM for an internal time tracking system. In small companies, that position usually doesn't exist, but in big corporations, it's quite normal. This type of PM is different from the other two, and the main reason here is the lack of "paying" clients. Typically a Product Manager position requires a lot of thinking on how to increase the product's revenue. With internal products, you don't have any paying clients, but you have something else to focus your priorities on. This something is client satisfaction. I mentioned that Internal PM doesn't have any paying clients, but it doesn't mean it has no clients at all. Obviously, every internal user of the product will be a client of that product, so the two most important things that Internal PM has to deal with are user satisfaction and... budget. Yes, I did mention the lack of paying clients and no need to think about revenue, but it doesn't mean Internal PMs don't need to care about money at all. Quite the opposite - arguably, with internal products, it's sometimes even more important to focus on the "efficiency" and "cost" of the product. Engineering time, of course, costs money, and because an internal product doesn't generate money (I'm simplifying here. Internal products can generate money indirectly by making some processes more efficient, etc.), that cost must be kept below a predefined level. For example, with internal products, it usually doesn't really matter how "pretty" or "modern" they look. Performance is usually not an issue either, so internal tools don't need to be extensively stress-tested and tuned to handle millions of users.
• B2C PM - Business-to-client Product Management is the most "typical" product management. In theory, it's also the "easiest", meaning the goals are the most clear - the main job of B2C PM is to make sure that users of the product like it and are happy to pay for it. This type of product management focuses mainly on gathering feedback from users and making decisions based on that feedback. Of course, in real life, it's not as straightforward as it sounds. You can't satisfy all, so there will always be situations that a new feature that you'd be so proud about will receive some negative feedback. The scale is also very important here. If you are managing a product that has 1000 users, 1% of that is only 10 people, which means if you have a bug in your product that affects 1% of users and a new feature that 50% of your users are waiting for, then it's usually safe to assume that you should focus your efforts on the new feature first. But if you have 1 million users, 1% of that is 10000 users, which is not something that you can easily ignore anymore. But overall, the bottom line is that this type of product management is the most "clear" in what the goal is.
• B2B PM - Business to Business product management is a very tricky business ;) this is primarily because in this model, on one way, you need to make sure that your actual users are happy with the product, but on the other hand, it's not them who decide if the product will be used or not. And at the same time, the people who decide probably won't even be using your product (this is especially true in the IT world, where management decides on tools that IT will be using). Therefore, B2B product management is arguably the most "difficult" one. It takes a special kind of person to be good at that. And that leads me to the point of this post...

The 3 types...

As mentioned before, the 3 types of PMs I explained above are not the 3 types that are the reason I'm writing this post. The above 3 types are the "business" types. But there are also 3 "typical" types of PMs from a personality perspective:

• Engineer - the engineer type is simply someone who was an engineer and got promoted into the PM role. No offence to anyone, and of course, this is just a generalisation from my side, but this type of PM usually doesn't care much about the business side of managing a product. In extreme cases, it will even fight against management. What engineers will care about the most is, well... making the best product (from an engineering perspective). You may be asking yourself now, "How on earth is that a bad thing?!" Well, let me give you an example. Imagine what would happen if you hired a Ferrari F1 engineer to be responsible for the development of the next generation of Volkswagen Golf :) F1 engineer would unconsciously try to create the best engine, suspension and everything. But the whole point of the Volkswagen Golf is to be cheap, moderately good, burn not much fuel and be reliable. This is the exact opposite of F1 requirements. So, while in theory, you want "the best" engine, suspension and everything for next-gen Golf, but in practice, you want those to be "the best WITHIN known constraints", and this is the very point here. "Engineer" type of PM will always try to build "the best" product possible, but usually, they will try to ignore the constraints. They will always see the business (management) as "holding them back" and setting "stupid" limitations.
• Artist - this type of PM is, I think, the most common type. This is probably because this type requires a person who is very extrovert, has probably thousands of followers on Twitter, and basically likes to talk a lot. This type of person usually nails the "typical" interview for product manager because they are just very good at "making a good impression". This is the type of person who probably has already many ideas during the interview on how to improve your product. But guess what... this is, unfortunately, usually just a facade. This type of PM usually struggles to actually deliver. They have new ideas every week but can't really think long-term. From the team (that will actually build the product), they are usually seen as "always busy", "chaotic" and/or "not clear what they actually want from us".
• Analyst - this type of PM is called an analyst because they only trust the data. It's the most common type for B2C PM because in B2C it's the most useful to rely on data. But what do analysts usually do wrong? Well, they don't believe in common sense and anything that doesn't have data to prove it. Don't get me wrong, having data to prove something is normally a good thing, but data can be misleading, can be wrong, can be incomplete, can be many things. That's why it's always great to have data to back your ideas, but it should be just one of a few "inputs" a PM takes into consideration when making an actual decision. Have you heard about the Survivorship bias? Look at the image below. It shows points where an aircraft was hit during battle. An "analyst" type of PM would immediately say, "we need to reinforce those areas". But it's actually the opposite. If you THINK about it, you'll realise that the data you gathered is from the aircrafts that DID COME BACK to you. This means, that those that were shot in places outside your data point are the ones that didn't come back. So, for example, shot in the top of the wing means that an aircraft is still able to fly back to base, but a shot in the engine area means the aircraft was not able to fly back, therefore the areas with the least red dots are the ones you should reinforce.

There you have it... the 3 most common product manager types you can meet in IT world. But you may be wondering now... the way I wrote the article sounds like none of them are actually good, so what? Am I saying all product managers are bad? Of course not! It's actually quite simple. To be a good product manager, you need to be all 3 types! Or, to put it in different words, you shouldn't be only one of the above.

If you want to be a good PM, you should be a little bit of an engineer to know how to build the best possible product, but you should also be a little bit of an analyst to validate your assumptions and ideas against the data, but you should also be a little bit of artist to make sure that the team (that is actually building the product) sees you as an "influencer" or "ambassador" rather than "boss" or... "asshole" ;) If you combine all these 3 then you'll become a "leader".