Introduction.
Product managers (PdMs) tend to be busy with a mountain of requests for functional improvements from other departments and customers, especially during the growth phase, although it depends on the phase of the product.
This article should contain my theory on how to prioritize products as PdM.
I, by the way, have not had any systematic training as a PdM (I don’t even know if there is such a thing), so please be aware that this is a theory OF my personal experience. m(_ _)m
First, determine the trunk on an annual basis.
First, at the beginning of the year, we imagine what we will accomplish as a product over the next year and what our ideal state should be in one year’s time, and then decide on one or two general things we need to do to achieve it.
At most, three per service. More than that, there is too much to think about, the direction of the product becomes unclear, the product becomes a “makunouchi bento”, and decision-making begins to take time.
If you are the representative and also the PdM, you decide the direction of the product that you think is ideal. On the other hand, if I am not the representative, as PdM, I propose my own ideas to the representative or the board of directors, discuss them, and obtain consensus.
This trunk can lead to KPIs that should be achieved on an annual basis, and it is also an indicator that should be constantly held as a PdM.
How do we respond to requests from other departments?
Personally, what is healthy for the organization is a situation where other departments communicate requests that come up within their department to the PdM with gusto, and the PdM then makes a decision and assigns priorities.
However, if you keep saying, “That can’t be done from a development standpoint,” the request itself will not be raised, and that is the most dangerous thing you can do.
Nevertheless, as more and more requests come in from other departments, if we do not make quick decisions on priorities on the spot, we will fall into a hell of notification and task management hell, and we will end up with a flat tire.
At this point, we will make a decision based on one or two core KPIs that we have just set as annual targets.
If the product team also meets the KPI it should aim for, it will be given a high priority, and if not, it will be given a medium priority if it is an important function for other departments, while recognizing that it is a branch function for the product.
If you try to respond to all the requests as much as possible, the development team will be forced to take on more work, and if you say, “We responded to all the requests from other departments, but (because of that) we could not achieve the KPI that the product team is pursuing,” they will say, “I don’t care if you say that. The ability to say “No” to some extent is also important. For this reason, it is important to proactively have priorities as PdM. Otherwise, requests from customers and requests from other departments will all appear to have high priority.
Then, in your mind, draw a rough timeline of the large functions that are being implemented, even on a monthly basis, and make decisions on the spot such as, “This request can be implemented more smoothly after this function is implemented two months from now, so we won’t have to do it twice,” and communicate it to the client. Like Lego blocks, the functions to be implemented are arranged in a timeline in the mind so that there is as little waste as possible.
It is also important for the product team to share that they are pursuing this KPI this year at monthly meetings and mtg with other departments. However, if there are more than four KPI index items for a product, there is a possibility that other departments, which are busy with their own work, will not recognize them. People cannot remember that many things.
How to respond to customer requests
As for customer requests, they are very important, but at the same time, the following two points are also important.
- Customers understand the surface of the issue, but not the depth and solution
- Customer requests are only a branch, and the product team decides the major direction (trunk) of the product on its own initiative.
Hearing about the issue is important, but instead of taking it as it is and passing it on to the development team like a pigeon, it is better to propose a solution to the customer on the spot by asking, “How about this solution for that issue? It is better to propose a counter-proposal to the customer on the spot that is as easy to develop as possible, and solve the problem on the spot.
While listening to the customer’s request, in the back of my mind, in real time, I think, “I see. If we were to develop this as is, it would take this much time, and since the development team is currently working on A and B, we would have to respond at this time…” and so on,
But, what if this customer’s request could be solved by doing something like this? It is important to think about things like, “This is what the customer says is the problem, but what they are actually having trouble with seems to be XXX.
In any case, “I’ll take it back and consider it,” is no good. If you don’t tell the customer on the spot whether you will or will not respond to the request and, if so, when you expect to do so by, you will not be able to adjust the customer’s expectations, and other tasks will fall on you, making it impossible to digest them and later forget about them.
From this perspective, the PdM should have some knowledge of UIUX as well as knowledge of the service and programming, so that he/she can make decisions more quickly before dropping them into development tickets, which will lead to the overall development speed of the service. Personally, I believe that a significant portion of the development speed bottleneck depends on the ability to make on-the-spot decisions at the PdM stage and prioritize the tickets that can be developed. Often when it comes to service development speed, the focus tends to be on the number of developers.
How do we adjust customer expectations?
That said, how do you make decisions on customer requests if you don’t have a core KPI in your product team or if you don’t have a clear priority in your PdM?
One solution would be to put all customers and development teams in the same group and create one channel there, “Requests for Improvement,” to make customer requests visible to other customers and to development members.
This is actually what I did with the melp I founded, until then, I received emails from customers to me with feature problems and requests for improvements, but this creates the following bottlenecks.
- From the customer’s point of view, the PdM is the single point of contact for development requests, so if the PdM does not respond to requests (and often the PdM is too busy to respond), the customer tends to become frustrated that his/her requests are not being fulfilled at any point in time.
- Customers think that the complaint they have is the most important and do not know about other requests for improvement from other customers
- Customer requests are concentrated in one PdM and PdM is tight
So, in the middle of the process, I thought, “Then, let’s include all customers and create a development request channel to make it visible.” I invited everyone to Slack and created the following channel.
As is often the case with Discord, etc., a “development request” channel was created in addition to the self-introduction channel, information sharing about services, and features to be released, etc. All development team members were also invited to this channel.
By doing so, the following three advantages were created.
Allows visualization of development priorities
- When I raise a development request on my Slack channel that others would like to see addressed, they “like” the post. The number of “likes” allows me to objectively judge development priorities, and development members can see this, making it easier for both customers and development members to be satisfied. The number of “Likes” is a good indicator of the priority of the development process.
- Many customer requests are imagined to be upgraded from a small branch to a larger branch. Whether or not they make it to the trunk is judged solely on whether or not they meet the KPI that is being pursued as a product.
Able to adjust customer expectations
- When communicating 1:1 with PdMs via email or phone, it is difficult to see requests from other customers, and it is structurally difficult for customers to understand that development is working on prioritized tasks based on multiple tasks and may not be able to respond to them right now -> this leads to dissatisfaction due to uncertainty about when they will be able to respond.
- The grouping in Slack reduces anxiety, since numerous requests are being raised in addition to those from myself, the priorities of the requests I have raised are visualized, and the development responses to the many requests are visualized as sequential.
Eliminates PdM bottleneck
- Until then, the PdM was the hub connecting the customer and the development team in service development, and was a single point of failure, for better or worse, and the PdM was getting busier and busier. However, by including development members in the group and having them communicate directly with customers, PdM will become easier and the development members will be able to understand the real voices of customers, which will lead to increased motivation.
This is an example seen in other companies as well, such as Qiita, which has set up a place called “Qiita Discussions” where users can openly respond to requests and questions.
summary
The above describes an example of how to determine priorities as a PdM
- Focus on no more than two core features or service improvements to be accomplished in the first year.
- Determine requests from other departments and customers based on the above priority axes.
- Directly connect customers and development members to set priorities through a mechanism, eliminating the single point of failure called PdM.
I always think about how I can make things easier for myself, because I believe that the PdM is a role that tends to get busy with notification hell due to requests from other departments and customers, and the last thing I want to do is drown myself in being busy (writing this, you might think I’m lazy (sweat…).
Not only PdM, but any work must be completed quickly and easily to have a margin of time to generate the next idea. By using the extra time for input, the priorities for subsequent tasks can be set even faster, creating even more margin, which is a positive cycle.
In addition, it is also important to be able to make decisions quickly on the spot regarding priorities, which I personally believe requires a huge amount of input regarding UIUX from the business and other products. I will write about this in a separate article at some point.
