Starting from last year, I have been thinking about what I really want to do in the next 5–10 years. This is also tied to a bigger question: what great value I want to bring to the world. I have always dreamed of creating innovative, impactful and useful products and building a sustainable business with it. Over the years, I have been working as a software engineer, mostly focusing on backend systems. Although my ability to solve technical problems has greatly improved, there are so many other skills I want to learn to achieve what I’ve dreamed of. Among them, the most critical skills are product management. Product management is all about knowing users well and the ability to translate user needs into feasible solutions. Without user insights, it’s hard to build something valuable. Before switching to a full-time product manager role, I decided to take a safer route, starting from a 20% project and saw how I liked the work. Finding a 20% project was not easy. I will discuss how I found the project in another article. This time I would like to focus on what I have learned in the first 60 days as a 20% Product Manager(PM).
Lesson 1: Shift your mindset
Engineers solve technical problems. The job of an engineer is to design and implement solutions given the constraints and requirements. PMs focus on customer problems. The problem may or may not exist. Solving a nonexistent problem can be a disaster to a team and also the business. That’s why PMs spend a lot of time collecting signals to decide if the problem is worth solving. PMs are not evaluated by the number of features shipped but by the user insights brought to the team, helping the team to make a more informed decision.
Lesson 2: Articulate your product hypotheses
PMs start opportunity exploration from product hypotheses. Product hypotheses could be based on user insights or observations. I will give an example what product hypotheses look like: Suppose we want to build a new application for online food delivery, the initial product hypotheses could be:
a. We assume for users who value time over money, they are willing to pay extra money to get their food delivered. (business value hypothesis)
b. We assume our target users are young professionals. (target user hypothesis)
c. We assume they value most is short delivery time and little efforts in choosing what food to eat. (user need hypothesis)
Once we have hypotheses, we conduct targeted user interviews to validate our hypotheses. This does not mean we only want the yes/no answer for each hypothesis. When we conduct interviews, we could form new hypotheses that need further exploration. We could also find our hypothesis is wrong. Our job is to continuously validate our hypotheses through user interviews.
Lesson 3: Judiciously choose what to learn
My 20% PM project is in a totally different area. The ramp up is a bit challenging. As a software engineer, I can start from understanding the high-level architecture and then dive into each component. As a PM, I have way more things to understand. Besides the product itself, the product ecosystem, the competitors, the users and their use cases are all the things I need to get familiar with. After gaining some basic understanding, I started to conduct my primary research for my project. The more I learned, the more I realize I don’t know so I started to binge read all the interesting articles I could find. I soon find it not helpful. These articles do not need the same amount of attention. I need to categorize them so only the most important ones are not missed. I put the articles into the following categories:
a. Fundamentals
These articles are deep and thorough. They are written by experts in an area. They talk about how the product/ecosystem evolves. For a technical product, it’s important to understand the technical concepts behind it. Some experts write beginner friendly training materials. I highly recommend starting from these articles.
b. User stories
This may only be applicable to enterprise products. It is not difficult to collect open user stories from their companies’ blogs. I focus on understanding their pain points, technical requirements and unsolved issues.
c. Product releases
I look at the competitors’ product releases. The release history is especially interesting to understand how they prioritize what features to build and what user needs behind it. This is like a backward learning method from what they built to what user insights they have gained. I am not sure if it is effective and feel free to leave comments for discussion.
d. Industrial reports
My PM mentor suggests me to read industrial reports. I started to read some but did not find them informative because most of the reports are already known facts but use more business-savvy language targeted at executives. I probably have not used the right tool or the right keywords to find useful reports.
Lesson 4: Identify user segments
We need to identify what customers we want to recruit for interviews. Since our product is enterprise-facing, it’s often hard to find enterprises which have not yet engaged with any related products in the whole ecosystem. We need to find customers who have used related products but have not yet explored our product or ended up using our competitors’ products for some reason. I initially suggested to focus on one particular industry. But my PM host suggested to expand into other industries since we can gain a diverse set of user insights. Finding the right user segment is important. It could affect the conclusions we make from the interviews. I will write more on this topic once I gain more experience.
