The Three Perspectives Necessary for a Product Manager
The role of a Product Manager (PdM) is, in a few words, to “understand the overall direction of the company and business, and lead the product (or service) to success. The phase of a product varies, sometimes you plan and launch a new product from scratch, and sometimes you are involved in the growth of an existing product.
This diagram clearly shows the perspective that PdM should have in any phase.
© 2011 Martin Eriksson. Re-use with appropriate attribution.
This is not my original diagram, but Martin Eriksson’s. UX, business, and technology are exactly the three perspectives that PdM should have. I will try to explain them one by one with my interpretation.
UX
In other words, it is the quality of value from the user’s perspective. A good UX is a state where the quality of user value is high, and this quality can be broken down into two categories: quantitative quality and qualitative quality.
(1) Quantitative quality
Quantitative quality is an indicator that is tied to the essential value of a product. For example, assuming an automatic meeting minutes application with voice recognition at its core, the voice recognition rate would be the KPI for UX. once the KPI is determined, it can be broken down into how to measure it, to what level of accuracy to satisfy users, and what is missing to raise it. This KPI needs to be measurable and have specific actions tied to the target value of the indicator.
In a nutshell, what PdM should do for quantitative quality is to define it and create a cycle of improvement. The process for creating a cycle of improvement can be broken down as follows.
a. Define the indicators that relate to the essential value of the product (UX KPI)
b. Define goals and timelines for UX KPIs
c. Build a system to measure the UX KPIs.
d. Establish and rapidly solve issues to increase UX KPIs
e. Regularly check whether the improvement of UX KPI is related to the KGI (sales, DAU, etc.) of the product.
Of particular importance is to create a mechanism to measure C. Resist the temptation to create tangible value quickly, and create a mechanism to measure UX quantitatively, so that the cycle of improvement can run without cost. I don’t think it’s an exaggeration to say that whether or not this is done will determine whether or not the subsequent activities to improve UX quality will run smoothly.
(2) Qualitative quality
Qualitative quality, on the other hand, is very difficult to express in numbers. If I had to put it into words, it would be comfort of use or pleasantness. Ideally, it should feel good enough to make you want to continue using it even if you have no purpose. It could be the response speed, a little animation, etc. The point of “pleasantness” depends on the character of the product.
The important thing about qualitative quality is to understand the importance of qualitative quality. In other words, don’t rely too much on quantitative quality; as a single user, you should also rely on your sensibility, whether you intuitively want to continue using the product or not, and whether the UX is pleasant. While it is important to measure quantitatively, it is also important for PdM, who has the authority to make decisions about the product, to take into account the sensibility of the user.
Technology
From a technology perspective, the key is an understanding of the difficulty and cost of implementation and an understanding of low layer technologies.
(1) Understanding of the difficulty and cost of implementation
As a matter of course, if you know the level of difficulty and cost, you won’t be able to make the specifications of the service unpredictable, and if there is a gap between the state you should aim for and the team’s capabilities, you can strengthen the team from an early stage. (I have the impression that there are surprisingly few people who accurately understand even the latter gap.)
The best way to understand the difficulty and cost is to have actual development experience, but I know it can be difficult to get that experience on all layers. (Though you should make an effort to…
If you don’t have development experience, you should at least have a deep understanding of the development process. For example, when you want to improve the accuracy of a speech recognition engine, you need to know what kind of training data it needs, how much training data it needs, what kind of pre-processing it needs to do to use it as training data, the cost of training, and a series of processes to evaluate the accuracy. (If you understand the process, you should be able to understand about half of the difficulty level.
Understanding the level of difficulty also has the side effect of making it easier to make backup plans ahead of time, since you will know the uncertainties, or risks, in the project.
(2) Understanding of low layer technologies
The key to not being misled by marketing buzzwords is to have an understanding of lower layer technologies. For example, if you have a good understanding of TCP/IP, you can understand how the software related to it works, and you can imagine what it can do and to what extent. On the other hand, if you are only looking at the final product, you cannot recognize different buzzwords that are actually based on the same technology. It is also impossible to measure the sophistication of the essential technology.
Understanding low layer technologies is a long road and can be painful unless you like the technology itself. However, once you understand it, you will be able to determine the specifications of your product, and when you encounter a technical problem, you will be able to get an idea of whether it is a solvable problem or not.
If you are an engineer who actually writes code, you need to keep updating your knowledge of the how by following the trends in technology. From the perspective of PdM, on the other hand, I think it is a better role for PdM to understand the underlying technology rather than chasing the how trend, because it will help you understand the boundaries that can be realized as essential user value.
Business
In a nutshell, when it comes to business, it is very important to understand the motivations of all the stakeholders involved in the product. These stakeholders are all the people inside and outside the company.
(1) Understanding of user motivation
What motivates the users of the product is why they use the product, what means they use to satisfy their needs or solve their problems without the product, and so on. If we know what motivates users to use the product (even if they have to switch from other current solutions), we can assume how much they are willing to pay for it.
“Business” tends to be defined as a business model, but there are cases where the business model itself is better left to the experts who are good at it, and I think it is possible to actually leave it to them. PdM, on the other hand, should be based on an understanding of UX and technology, and should consider the answer to the more fundamental questions of why users find value in it (quality of value) and how many users will find value in it (quantity of value).
(2) Understanding partner motivation
Naturally, it is also important to motivate the partner company that will be creating the product with you. Why do you collaborate with your company, what is the purpose of the collaboration, and conversely, what are the things you don’t really care about? Since the form of the company itself does not exist as a single intention, it is necessary to raise the resolution to understand who the decision makers and key persons are, and what processes are used to make decisions.
If you have a deep understanding of your partner’s motivations, it will be easier to envision how to connect their wants in order to create the same user value, and it will also be easier to predict how changes in their situation will affect the product.
(3) Understanding the motivations of internal stakeholders
The last one is internal. This is why the company develops and promotes the product. Mainly, it is important to understand the company-wide policy from the top management’s point of view, and how to match the product policy with the company’s policy. This matching is not a one-time process, and especially in a company with dynamic management, it is always moving, so it is necessary to update it in detail and keep checking the expectations in short cycles.
If the significance of the product has already been established within the company, there are many cases where a “model” for controlling expectations has already been established. On the other hand, especially in the case of a new business, the degree of difficulty is high because there is no visible product or outcome, and I think this is often the most important (and difficult) task among the many PdM tasks.
In the end
I’ve written a lot of things, but I haven’t done them all myself. What is the most important thing, then, can be summed up in these three things.
1. Understand the perspectives required for PdM
2. Understand the perspectives and skills you are lacking
3. Involve the people you need to fill in 2.
PdM believes that the two most important skills are the ability to understand what is needed and the ability to fill in what is missing. I believe that the ability to fill in the gaps will allow PdMs to learn more from the teams they work with, and as a result, increase their own knowledge and abilities.
I have broken down the perspectives needed as PdM in three categories: UX, technology, and business. I hope this will be helpful to you.
