Focus on what really matters: Lesson learned as a product manager

Min Wang
Product Coalition
Published in
5 min readMar 19, 2019

--

Things I learned the hard way, but you don’t have to

Credit: Spider-Man: Into the Spider-Verse, Sony Picture

Converting into a product manager has never been an easy task, however ready I thought I was. Behind the busy therefore seemingly self-important schedule, I have been keeping asking myself, what value do I bring to the table? After all, product managers are not the real “makers”. There are developers who write codes; there are UX/UI designers who deliver wireframes and screen designs. What do I produce? How do I know if I am doing a good job? And as a beginner product manager, no matter how long and how good I was in my previous career track, the haunting self-doubt whether I have what it takes to be a good one.

This was my struggle when I started my product management career. I learned things the hard way. This article is not about the “right answer” of product management. This is the record of my exploration, question by question, layer by layer. To those of you who just started your PM career or are considering to take the leap, I hope this article will make you less uncertain about yourself and about product management.

What value does PM bring to the table?

Among the long list of skills and qualities a PM should have, problem-definition and prioritization are the two most important ones. Starting from the problem definition, a PM is responsible for picking the right problems to go after, defining the goals and determining if the solution meets the goals. If the PM identifies the wrong pain points or not prioritizes well, the project is doomed, no matter how strong the developers and the designers are. This echoes the fact that PMs are judged nearly exclusively on the output of the teamwork.

Is it a good idea to copy the competitors?

As a product manager, we may all, at one point, be facing the question — shall I copy my competitor? Copying a proven feature is tempting, especially when the products are competing for the same target customers. However, before jumping on to the development, dig deeper.

Look into the problem, not the solution. Technology changes all the time. There will always be better solutions to solve the problem. Copy the “solution” from the competitor, however good it seems, is like chasing yesterday’s tomorrow. Take the “favorite button” as an example. Almost every application has a “favorite button”. However, “favorite button” is just a means to an end. For a shopping site/app, by using the favorite button, the user probably wants to mark the item and accomplish, a) keeping looking for similar items; b) comparing price/specs; c) waiting for the right time to buy. A product manager must understand the real problem in order for the team to come up with the right solution.

Can PM just build any product that solves the pain points?

Identifying customer pain point without playing to the strength of the team simply won’t work. A case in point, Google’s effort in the social network (Google Wave, Google Plus) all ends up failing. Another angle to think about this. Why didn’t Amazon expand into perishable goods 10 years ago? The needs for convenient grocery shopping have long been there. But the maturity of the supply chain and delivery system, including Amazon’s fulfillment center were not. Sometimes, a good idea alone is not enough to move the needle. If the idea is good enough, you can expect a competitive market ahead. Time is a precious commodity. The resource of a company is always limited. In product management, you need to look at all these strategies and see where, or, if they intersect.

My professor used to tell me “keep your head high above the cloud and keep your feet firmly on the ground”

Why is prioritization important?

When I started my first MVP, I was very ambitious to build a “good product”. I kept adding new features and I was obsessed with getting the details right. That didn’t work out. The problem is that adding more features would be at the cost of either speed, or quality, or both.

Software only creates value for customers once it’s shipped. Sadly, shipping the perfect product is an illusion, and trade-offs are always required to ship. In crafting a solution to the problem that is defined, prioritization means doing the things that create the most customer value first. Especially when building an MVP, usually, the solution is an assumption or even the problem to solve is an assumption. In this case, the product should be shipped as fast as possible to validate the assumptions first.

When prioritizing work, a PM should always ask oneself: is this absolutely necessary? Sometimes, the emotion gets in the way. Or as it was in my case, my ambition. If it comes to that, use the goals as a parameter for the decision. Is the current solution meet the goals already? If not, will the new solution meeting the goals after adding this feature?

“Product management” is not something one can learn in college. It’s a murky territory. Most of the time, we product managers wear multiple hats to get the things done. I still have yet to figure out what makes a PM great. But I’m a firm believer that fundamentally, product management is a mission that has a lot to do with understanding the world. Why something is working the way it is? And can we improve on that? I enjoy this mission very much. My proudest moment as a product manager is to see the product finally gets shipped after the enduring journey starting from a concept. I relish our effort to make this world at least a little bit better.

Thank you!

This is my first ever blog post. Your feedback would be my biggest encouragement! I’d be very happy to see your comments below or connect with you on Linkedin.

--

--