Product managers constantly balance 3 key responsibilities: the product perspective, the business perspective and the development perspective.
Often, only the product perspective – the relentless focus on the user – is referred as the key responsibility of a good PM. I find this a rather single dimensional view, which is why I want to bring the other perspectives to the table as well.
Note that in this post, I will give a rather superficial overview without going too much into detail. More in-depth posts on certain topics will follow in the upcoming weeks.
Product management is about communication
One of the key aspects of product management is being an outstanding communicator. Independent of your exact rank in the organization it will follow naturally, that you will find yourself in of the pivotal roles concerning information flow. Plus, you won‘t have organizational power but you will still need to encourage and lead your team.
In that sense, I like to think of a Product Manager as some kind of a translator.
He or she has to translate for example between creatives and techies, C-level and engineering, marketing and operations and even own some communication between the company and it‘s partners.
The product perspective
A Product Manager is also a translator in the sense that he shapes the output, the product of a company. The PM is in charge of making it understandable to the user: If your company produces a hammer, then a good PM would make sure it looks like a hammer, it feels like a hammer, and it does the things we expect a hammer to do.
And there is even more communication going on: It’s also part of the product how the company “talks" about it (marketing) and how it treats existing customers (customer support).
I‘ve talked to many people who wanted to become product managers because they would be executing their own ideas (btw. also other roles fall into that trap sometimes – yes, I‘m looking at you, SCRUM masters, QA managers, designers, & engineers). But as a PM it‘s all about the user.
However – and this is crucial to be successful in this job – the user can be many different stakeholders. The user does not necessarily have to be the end customer, but can also be your ads/sales department, your customer support team or your marketing team. And it‘s your job to figure out their needs, their success criteria, and the relative importance of all the little parts that make up the requested product.
If it‘s not clear who your user is, you don‘t have enough understanding of what you are building. As a Product Manager you need to be empathetic enough to relate to the user‘s needs and you have to have at least a basic understanding of your user‘s environment.
A little thought experiment
Now you may ask: Why is it so important to know your user? Isn‘t it enough to know what I expect? Fair question, therefore I want to do a little thought experiment with you.
Imagine designing a product to communicate with your best friend. What would the product look like?
Now, imagine your best friend lives in the USA while you are located on a different continent.
Imagine your friend is deaf.
Imagine you are poor.
Imagine you live in a country that has strict governmental regulations (eg. China). What would the product look like now?
Based on every single piece of information your product would (hopefully) look entirely different.
Empathy is the key to well thought product design.
Let me stress one thing here: The product perspective is so important and so complex, that this task is almost not doable by one single person. This is one of the reasons why the team’s input is so important and why a lot of product teams have UX designers and researchers on board. Also, a good portion of prototyping, user demos, and user tests help tremendously.
The business perspective
As much as PMs and development teams sometimes would like to focus on the user only, there also has to be the business perspective taken into account. It‘s not only critical that your customers use your product but also, that a Product Manager has an understanding of the long term business impact.
Business Metrics
At the end of the day, if the company does not profit in any way, it will be quite tough to sustain the product/feature/service. Therefore, the first principle has to be to protect revenue streams and the company’s brand.
In order to compare possible features and products, PMs need something similar to a ROI calculation in place. Depending on the end user and the goals, the „return“ of a product can be measured in many ways: revenue/profit, active users (think about Facebook) and brand recognition (think about Red Bull). This expected payoff has to stand in line with the company‘s goals and KPIs.
Additionally, the cost of implementation and maintenance has to be justified compared to the payoff.
A word on B2B vs. B2C
It is relatively clear that the business requirements are rather different for B2C compared to B2B companies. From my observation this mainly has to do with (early) switching costs. I will write about the growth funnel in a later post, but here is one short reason why this is so different:
If you download an app and you don‘t like it, you maybe wasted 5-10 minutes of your time. Usually that‘s quite different for B2B businesses where the evaluation process, the prototyping phase, and the decision process already takes weeks or even months and costs a lot of money. Also, the decision process inside a corporation is much more complicated. This fact has a big impact on the product as it’s a group of decision makers instead of a single individual.
More on that in a later post.
Types of Products/Features
A product usually consists of several features. Those should be evaluated not only in terms of immediate impact but of a system of interconnected functionalities. There are multiple dimensions along which features can be classified: growth funnel, business impact, user journey, competitive analysis,… Each one of those has its own unique approach and I will write about some of those more extensively in the following weeks.
As a start I like to propose to think about products/features in 3 categories, that are mainly core-product focussed: basics, marketers, and multipliers.
Basics
Basics are features that provide basic functionality. If you develop a running app, it‘s the basic tracking. If it‘s a music app, it‘s the music player. If it‘s Instagram, it‘s the camera. It‘s those features that provide the basic functionality that everyone expects who downloads the app.
Marketers
Marketers are those features that often don‘t have an immediate impact on the functionality but help with brand building. It’s nice little add-ons that give the user the impression of a well designed, well-thought product. Consider the Instagram photo filters. It‘s not needed for the basic functionality, but it‘s the nice little things that make the product exceptional.
Multipliers
Finally, there are the multipliers, that build on those functionalities and make them exponentially more useful. For example, if you build a social network on top of your basic functionality. For the core functionality this might not be necessary, but as soon as it‘s there (and given that it‘s well thought through), your users suddenly find a platform to interact with each other. Think of Medium (rather simplified): The more users get on there, the more content is produced, which attracts more users, and so on.
Potentially, those features can be the beginning of a platform business: not only does the company itself provide value, but network effects kick in and the platform gets more valuable by users adding value to the other customers (Check out Alex Moazed’s Modern Monopolies and Ben Thompson’s Stratechery Blog if you are interested in this topic).
The development perspective
Considering the actual implementation of a product is the last important perspective in a PM’s toolkit. It is so important, because it‘s the major constraint for building your product. You can have the best roadmap with the perfect features and have it all figured out, but if no one can actually build it, you are lost. No matter how great your product is, if the quality sucks, no one will use it.
Technical knowledge
As a product manager you don‘t have to be able to code the final product yourself. But you need to have at least a basic understanding of the relations and technical constraints of technology.
This has 2 benefits: On the one hand you are able to discuss technical proposals and help avoid over engineering. On the other hand you have at least a rough understanding on the complexity of your idea. Still, don’t limit your thinking too much. If you have talented engineers they will exceed your expectations anyways.
Team Motivation
As mentioned in the beginning, a Product Manager usually is not the organizational lead of their team. Therefore, they have to create intrinsic motivation: a sense of purpose, providing a compelling vision, and building team culture.
Product Managers want to encourage discussion and create a room where ideas can flow. You have to be careful of the boundaries and goals you set for your team: Too narrow and you will end up with a good-enough solution and demotivated team members. Too far and you will potentially run into over engineering.
Focus is important, but so is creativity and out of the box thinking.
I think, that this is THE crucial quality of a product development team, that separates high performing from low performing ones: Is the team able to direct their creativity and problem solving skills to solve customer needs effectively?
Prioritization
At the end of the day, it‘s the Product Manager‘s job to prioritize what‘s most important to build. They own the idea backlog. Sounds easy in theory, but it‘s hard in practice. Why?
The reasons are twofold: On one hand, it‘s about overcoming our emotions and perfectionism at some point and decide what‘s really needed. On the other hand the scope of a product is usually a moving target. Do we want to launch an early prototype for testing or a minimal marketable product? Is it more important to fix a bug on a paywall or finish building a feature?
This is, where the real seniority of a PM comes into play: Understanding the constraints that come with those decisions. The 3 perspectives mentioned in this post will hopefully provide a good starting point.
Conclusion
This is exactly what the amazing challenge of product management is: wearing multiple hats, being empathetic with the user, thinking about the business while not losing sight of the technical dynamics, and team building. Being always prepared.
I‘ve written a blog post on the Tyranny Of Metrics the other day, where I wrote about invisible skills. Abilities that don‘t show up on any analytical sheet but contribute tremendously to a company‘s success.
I think that a lot of PM abilities play exactly into this category: motivation, communication, prioritization, & analytical skills.
Product Managers are „multipliers“ in that sense: they make sure, that the development teams are running together in the right direction.
Questions, ideas or feedback? Would you like to read on a special topic? Leave a comment or shoot me a message!