I think Product Manager is not just “product management”, but the person who keeps the product from drifting away from customers
There is a detail that made me pause for quite a while when learning about the role of a Product Manager: if the company makes detergent, the PM cannot just generally state that “customers want a better product.” The person needs to understand whether customers prefer powder, liquid, or capsule detergents; whether they care about fresh scents, specific pricing, strong stain removal capabilities, or any other factor. It sounds very mundane, but it's this mundanity that made me realize Product Management isn’t a vague role standing between departments for “prestige”.
My perspective after this lesson is: A Product Manager is someone who transforms the voice of the customer, market data, and business objectives into a clear enough direction for the entire organization to act upon. The PM doesn’t necessarily have to design, code, sell, or advertise themselves, but they must understand enough to connect those parts.
This is important for anyone exploring AI PM or Product Management in general, because if you only view the PM as “the person who writes roadmaps,” it is very easy to overlook the hardest part: knowing who the product should serve, what problem it should solve, what should be prioritized, when to launch, and what to learn from the feedback thereafter.
1. Product Manager starts from product planning, not from a list of features
The first thing I learned is that the Product Manager has a significant responsibility in product planning, meaning planning for the product. But the plan here is not just “this quarter feature A, next quarter feature B.” The PM needs to understand customer needs, grasp what the current market holds, where the market is heading, and from there decide which direction the product should be developed.
An example from the lesson mentions customers increasingly asking more about organic products. If you are a PM in a consumer goods company, you cannot just hear the word “organic” and immediately instruct your team to make an organic product. You need to research what kinds of organic products the market already has, whether customers buy for health, environment, brand, or trend reasons, what price they’re willing to accept, and how competitors are positioning their products. From there, the product plan has a foundation.
I find this point is very similar to preparing to open a small coffee shop. If you only say “people like good coffee,” it’s not enough. You must know if the area has more office workers or students, if they need coffee to-go or a place to work, if they are willing to pay 25,000 or 60,000 dong, and how many similar coffee shops are around. Product planning is the same: you cannot separate the product from the market context and the real behavior of the users.
Another responsibility that goes along with planning is risk management. In the lesson, the PM is described as the person who sets product strategy, conducts market research, creates a roadmap, prioritizes features, coordinates teams, monitors competition, launches products, collects feedback, and manages risks. I understand risk here can mean misidentifying needs, launching too late, mispricing, the technical team lacking resources, or the product being outpaced by competitors.
A practical piece of advice I take for newcomers is: if you want to learn Product Management, don’t start by learning how to write a beautiful backlog. Try to choose a familiar product, such as a food delivery app, e-wallet, or language learning app, and then answer three questions: who are the main customers, where are they in pain, and what alternatives does the market have. Even such a small exercise helps you view the product much less emotionally.
2. “Voice of Customer” is structured listening, not just listening for the sake
An idea I found very important is that the Product Manager must learn to think like customers and listen to the voice of the customer. But “listening to the customer” does not mean doing exactly what the customer says. As I understand, the PM needs to transform words, behaviors, and separate data into actionable needs.
The detergent example in the lesson is very understandable. A customer might say, “I want a cleaner washing product.” But “cleaner” might mean better oil stain removal, better color retention, better sweat odor removal, or leaving fewer residues on clothes. Another person might prioritize low cost, while yet another wants long-lasting fragrance. If the PM doesn’t dig deeper, the product team might optimize the wrong thing.
The methods of capturing the voice of customers are also very diverse: the PM might interact directly with customers, analyze survey data, organize focus groups, conduct interviews, or use other data sources. What I like here is that the lesson doesn’t confine the PM to just one type of data. Sometimes you need wide data from surveys, sometimes deep listening through interviews, or sometimes observing real behavior to see what users do, not just what they say.
However, I also want to pose a light counterpoint: customers don’t always know exactly the solution they need. They know their discomfort very well, but the solution might require further exploration by the PM and the product team. For example, a user of a language learning app might say “I want more lessons,” but the real issue might be they can’t maintain a learning habit, don’t see progress, or the current lessons are too long. If you just add lessons, the product might expand without properly addressing the problem.
For newcomers, I think there is a simple exercise: next time you hear someone complain about a product, don’t rush to think of a fix. Ask further: “What bothers you the most?”, “In what situation did you encounter that?”, “How are you temporarily handling it?”, “If you could improve just one thing, what would it be?”. This is a practical way to train customer-centric thinking.
3. PM is the one who connects many groups, so they must negotiate between different demands
One part that makes me find the PM role harder than imagined is that they don’t only work with external customers. There are many different types of products and contexts: the PM might be responsible for IT platforms or services, internal products used within the organization, external products for customers, products closely tied to marketing, or post-purchase services such as aftermarket services.
This means that the “customer” of the PM is not always the end buyer. If the product is an internal dashboard for the sales team, the customer might be sales employees, business managers, the operations team, and even leadership. Each group will have different needs. Sales want fast data entry, marketing wants clearer segment data, advertising wants to measure campaign effectiveness, and management wants comprehensive reports. The PM must collect, analyze data, and then find a common direction.
The lesson emphasizes that the PM may have to negotiate and consolidate the needs of many internal customers. I find this a very “human” skill in Product Management. A product cannot satisfy everyone at once, especially when resources are finite. Therefore, the PM needs to know how to prioritize features, explain reasons, and help parties understand why some things should be done first, and some have to wait.
For example, consider a company wanting to build an internal customer management system. The sales team wants a callback reminder feature, the marketing team wants automatic customer tagging, the customer service team wants to see complaint history, and the technical team says there’s only enough time to do two features this month. If the PM simply transfers requests from one side to another, everything will be confused. The PM needs to view the current goal as increasing revenue, reducing churn, or improving productivity, and then prioritize based on actual impact.
A useful piece of advice for newcomers is: practice talking about the product in the language of many parties. With engineering, you need clarity on requirements and constraints. With marketing, you need to understand positioning and messaging. With sales, you need to understand the reasons for purchasing or not purchasing. With leadership, you need to connect the product with business objectives. The PM doesn’t need to be the best at every expertise, but needs to understand enough not to break the communication flow between groups.
4. Roadmap is a thoughtful promise, not decorative scheduling
The lesson says that Product Manager is often the point person for the product, meaning the main responsible person and “owner” of the product in terms of direction. After developing the vision, the PM has to introduce the product and make the rest of the organization understand that product. This is where I find the concept of “product owner” in the lesson very noteworthy: ownership doesn’t mean taking on all the work, but being responsible for ensuring the product has a consistent direction.
The roadmap is the central tool in that. A roadmap doesn’t just answer “what to do”, but also needs to answer: what the product is, why it’s important, how it will be launched, when it will launch, and for whom. If lacking these questions, the roadmap can easily turn into a feature list laid out month-to-month with no strategic logic.
For example, Tony in the lesson is a Product Manager at a computer processing chip manufacturing company. Tony tracks changes in customer demand and knows what the competition is doing. If a competitor releases a lower-priced chip or a faster chip, Tony needs to collect that data and share it with marketing, engineering, IT, and related teams to improve the current product or develop a new one. Tony’s responsibility isn’t just “knowing the competitor’s information”, but turning that information into action in the product lifecycle.
There are many responsibilities connected here: competitive tracking, data communication, cross-functional team coordination, product improvement or development, lifecycle management, and launch preparation. After the product is launched, the PM still has to collect feedback from the market to see if the initial assumptions were correct. If the feedback shows customers don’t care about faster speeds but care about energy savings, the next roadmap must reflect that.
The PM might also work with senior leadership to promote the product internally and advocate for unmet needs. For example, if the PM knows the competitor is improving the product to better meet customer needs, the PM needs to bring that information to the right place, present the current gap, and propose improvement directions. I think this is a part that is easily underestimated: the PM must know how to protect the product’s needs and customer needs against competing priorities in the organization.
A practice for newcomers is to try writing a one-page roadmap for a product you like. Don’t start with a timeline. Start with five lines: who is the target user, what is the main problem, what are the business objectives, what are the three biggest priorities, and what will not be done at this stage. Sometimes the “not doing” statement makes the roadmap clearer than a list of “what will be done”.
5. Persona helps me remember that “user” is not an anonymous crowd
The section on persona is the part I find easiest to apply when learning on my own. Product Managers use personas to build a picture of a typical user of the product. A persona is not a character made up for fun, but a way to synthesize data to understand what characteristics the customer has, what goals they have, what skill level they possess, what features they value, what dissatisfies them, and what they are trying to achieve.
A good persona might include their place of living, age, occupation, goals, dreams, skill level, personality, features important to them, and factors that do not meet their expectations. To create a persona, the PM should rely on data from surveys, focus groups, interviews, and other sources, and then categorize the data into meaningful groups. An important point to me is that the persona should be data-based, not just based on the product team’s imagination.
The lesson’s example is Jimmy: a 25-year-old male, living in Los Angeles, working as an IT professional, typically ranking third or fourth in chess tournaments. Jimmy’s goal is to become the best player in his league. His challenge is that the tournament is very competitive; he practices a lot but hasn’t found a better strategy to win the championship. A potential bias is that Jimmy might think our product suits a longer-term strategy rather than providing an immediate advantage.
I like this example because it shows that a persona isn’t just “male, 25, works in IT.” The valuable part lies in the goals, pain points, competitive background, and biases when viewing the product. If the product is a chess training tool, Jimmy might need game analysis, strategy suggestions, exercise based on weaknesses, or a training roadmap before the competition. But if he thinks the product only has long-term effects, the onboarding message needs to demonstrate short-term value more clearly.
My advice for you if you are just learning about personas: avoid creating a persona that is too flashy but hollow. A persona with a nice avatar, a catchy name, but doesn’t help with product decisions is not enough. Ask yourself: “If I look at this persona, do I know which feature to prioritize?”, “Do I know what message would persuade them?”, “Do I know what might disappoint them?”. If the answer is no, the persona needs more data or should be rewritten more specifically.
My Takeaway: PM Keeps the Product Close to Reality
After finishing this part, I see that a Product Manager is not someone who has the answers to everything. Rather, the PM is someone who continuously asks the right questions: what do customers need, how is the market changing, what are competitors doing, what can the team build, what should be prioritized, who will the product be launched to, and what does market feedback say about the initial assumptions.
I also think the PM role is very suitable for those who like to stand at the intersection of people, data, technology, and business. But that allure comes with responsibility: not loving the product so much that you forget the customer, not listening to customers superficially, and not turning a roadmap into an unfocused wish list.
Top comments (0)