Diary 01: Prioritize tasks as a Product Manager

In the summer of 2022, I interned as a Product Manager at SoFi/Galileo. One of the tasks assigned to me was to prioritize accumulated clients' requests, some of which could be dated back to 2 years ago. The goal was to propose a roadmap that would address such requests in the following months.

The challenges were: 1) those requested weren’t standalone, as some of them were part of others while some of them were asked by several clients about the same issue 2) I needed to balance the needs of clients, the benefit to our company, as well as engineering team concerns.

Therefore, to come up with a solution that caters to the needs of all sides, I borrowed what I learned from the IPD course at iii to design an evaluation model that weighs different concerns.

Step 1 What were the tasks?

First, I collected all the client’s requests on the JIRA platform and simply grouped them into different categories mainly based on their associated products.

Step 2 Reviewed by Engineers

The reason why Engineers’ opinions mattered in the early steps is that they were the best people to turn to if I wanted to understand the feasibility of each task. Some clients’ requests might be hard to achieve or have very low ROI. Therefore, I used the canvas shown below to collect Engineers’ thoughts on each client request. Interestingly, I found out that the Engineers that I worked with usually prefer communication over written documents like specs, mock-ups, or spreadsheets like this to a meeting. I do agree that meetings sometimes take a long time and the ongoing talking actually prevents people from thinking it through.

After their reviews, I was able to understand all these requests from the perspective of development. Also, with the engineers’ help, I sorted out the relationships between each task, which greatly decreased the complexity of the prioritization because some of the requests were rejected, and some of the requests were part of each other. I used the visualization to indicate their relationship.

Step 3: Enter the evaluation model

After knowing the connection between each task, the next thing to do was to find out what task had a higher importance and what had not. To do that, I came up with an evaluation model (see below). On the left, I mainly consider the potential value of each task, which can be broken down into the client’s satisfaction and the company’s satisfaction, which could be represented by user growth. And on the right was the consideration of development effort: 1) alignment: if the request aligned with our long-term development goal, 2) sympathy, if we saw the necessity to do so, and 3) regulatory if the request had any regulatory concerns. As shown, I gave the regulatory factor double weight because it has the urgency to be fulfilled.

When all the considerations were clear, I gave a score to each task accordingly. Then it became a number game to sort out the most and the least important request.

Step 4 The Prioritization

Now each request had a score of importance. But the scores were ranging from one to six, making six levels of priority. However, six levels were too complicated in the task given that there were not many requests in total. Therefore, I classified that into three tiers instead of six. Note that the visualization I used only illustrated the idea, not the actual process.

The first priority tier included requests of high importance. The second priority tier included requests of medium importance. The third priority tier included requests of low importance.

I also developed a color-coding system. The requests of the highest priority were coded with red, the medium ones with orange, and the lowest with yellow. This system allows for a quick visual identification of the level of importance.

Step 05 Roadmap

Another thing to do before turning the prioritization into a roadmap is to understand what else is needed for an executable roadmap. I discovered the following

• Identifying deadlines
• Defining roles and responsibilities
• Understanding dependencies
• Assessing the resources needed
• Identifying potential risks and issues
• Documenting the roadmap

After understanding the process and the key activities needed to complete it, I laid out the roadmap in a timeline. This timeline detailed the steps for each priority request and the timeline for completion

The timeline was also useful to identify any resource constraints, potential issues, and deadlines. I also used this to assign tasks and get status updates from team members. It also served as an initial assessment to determine if any requests need to be re-prioritized

In conclusion, I created a roadmap for the prioritization of requests by establishing tiers of priority, color-coding, and creating a timeline. This roadmap allows teams to be efficient in their prioritization process and to identify any potential risks or issues.