I think a good Product Manager isn't someone who knows everything, but someone who connects everything

I think a good Product Manager isn't someone who knows everything, but someone who connects everything

There was a detail that made me pause when learning about Product Manager skills: this role isn't solely about "coming up with new features." A Product Manager may have researched the market very thoroughly, understood customers deeply, and even have a quite convincing product idea, but if the leadership hasn't bought into that idea, the work hasn't gone anywhere. At that point, the needed skills are no longer brainstorming, but negotiation, communication, and consensus-building.

I used to think the main job of a Product Manager was to write the roadmap, gather requirements, and then pass them on to the technical team. But after learning from the sharing of Product Managers and experts, I see a much broader picture: they must understand the market, customers, technology, organizational capabilities, data, finance, marketing, sales, technical skills, and even human emotions during the process of product development.

My perspective is: A good Product Manager doesn't have to be the deepest expert in individual fields, but must understand enough to connect these specialties into a clear direction. This is especially important for those exploring AI Product Management, as AI products often have many additional layers of complexity: data, models, user expectations, bias risks, implementation ability, and true business value. If you're new to this field, learning Product Manager skills isn't to "be the boss of the product," but to learn how to view the product as a living system.

1. Business acumen: understanding the market, customers, and real limits of the organization

The first point I learned is business acumen, which can be understood as the ability to view products from a business perspective. This isn't just about knowing revenue or profit. It includes critical thinking ability, understanding how the market is operating, what customers really need, what the organization requires, and where the company's limits lie: team capacity, existing technology, budget, time, operational capability.

A real-life example: If you open a small café, you might love to create a menu with 50 items. But if the kitchen has only 2 people, ingredients are hard to preserve, and the local customers mainly buy to-go, then a "good idea" isn't necessarily the "right idea." Product Managers are similar. An appealing feature, but if the tech team lacks capacity, the market isn't ready, or it doesn't serve business goals, it should be reconsidered.

In lessons, research is heavily emphasized. Product Managers need to know what the market is doing, where technology is heading, and even how political context or external environments can impact the product. For AI PMs, this is even clearer: a change in data regulations, privacy, or user trust in AI can completely alter how a product is designed.

But business acumen isn't only about looking outside the market. It also requires customer connection: the ability to connect with customers and understand issues from their perspective. If a Product Manager can't put themselves in the customer's shoes, the product may easily become something "internally liked" but not wanted by users.

The advice I note for myself is: when learning about products, don't just ask, "What's good about this feature?", also ask four more questions: who needs it, where are they hurting, does the company have the capability to do it, and does it create business value after completing?

2. Communication, user centricity, and negotiation: the product doesn't move through an organization by itself

An idea repeated many times in lessons is communication, both speaking and writing. A Product Manager must communicate with many groups: technical, design, marketing, sales, finance, leadership, customers, partners, and sometimes even end users. Each group needs a different kind of information.

For instance, with the same product roadmap, the technical team might need to know priorities, scope, technical constraints, and completion criteria. The sales team needs to understand how that feature helps sales. Leadership wants to know its impact on strategy, revenue, or competitive positioning. If a Product Manager speaks the same way to everyone, there's a high chance some groups will feel under-informed, while others feel overwhelmed with details.

I found the phrase "delivering the information that they need in the way that they need it" very memorable. Communication isn't just about clearly stating what you want to say, but helping the listener receive exactly what they need to act.

A skill that goes along with communication is user centricity, or user-centered thinking. Product Managers need to "get inside the user's mind" and see the product from their perspective. For instance, if building a personal finance management app, the product team might want to add beautiful charts, advanced categorization, AI forecasting. But new users might just want something very simple: entering expenses in under 5 seconds without feeling frustrated. If not viewed from the user's side, the product can become "smart" but difficult to use.

Negotiation is also a crucial part. A Product Manager might have a good idea, but senior management hasn't agreed. Or the sales team wants feature A, the technical team warns of technical risks, while a large customer demands feature B. Product Management is a process of give and take, meaning constantly trading off between various needs.

A slight rebuttal that I found reasonable is: "If the product is good, it will convince everyone on its own, why is there a need for so much communication?" It sounds valid, but in reality, learned from this lesson, the product doesn't exist in a vacuum. A good idea still needs to be explained in the appropriate language, prioritized within finite resources, trusted by parties, and brought to the final result. Therefore, communication isn't an outer decoration; it's part of the product-making process.

For beginners, I think they can practice by rewriting any feature into three versions: one for users, one for engineers, and one for leadership. This small exercise quickly shows that product communication isn't simple.

3. Data, prioritization, and analytical thinking: not always having enough information

A Product Manager needs the ability to make prioritization decisions based on limited data. This is a point I find very realistic. When first learning, I often thought that a good decision is one based on complete data. But in the product environment, data is rarely perfect: surveys may have few samples, user behavior changes, markets shift, or quantitative data doesn't explain the reasons behind.

Therefore, Product Managers need to be both data analysts and accept uncertainty. They must process large amounts of data in short timeframes, using data analytics, reporting, and analytical thinking to identify critical signals. For instance, if a feature has many clicks but a low completion rate, PMs shouldn't hastily conclude that "users like this feature." They might click out of curiosity, but the usage flow is too difficult. Then it's necessary to combine quantitative data with user research for deeper understanding.

Research skills are also mentioned as an important technical skill: research-based skills, user research, data analysis, reporting. I find this aligns closely with AI PM. If working with AI products, a Product Manager doesn't just look at usage counts, but needs to understand output quality, error rates, user trust levels, scenarios where the model answers incorrectly, and whether users are truly better supported.

Besides analysis, Product Managers must know how to write user stories and do roadmapping. User stories help turn user needs into expressions that the development team can understand. For example: "As a salesperson, I want to see a list of customers likely to churn, so I can prioritize care." A roadmap is like a journey map: it not only lists features but also shows priority order, reasons, and the future direction of the product.

Practical advice for beginners is to practice reading data by asking questions, not just by looking at numbers. When seeing a metric rise or fall, ask: "What does this say about user behavior? Are there any other hypotheses? What additional data is needed to reduce guessing?"

4. Technical skills: don't need to know everything, but must understand enough to communicate

One point I liked in the lesson is the balanced view on technical skills. A Product Manager's technical skills depend on the product. If the product is very technical, the Product Manager needs to understand that domain more deeply. If working on a product related to DevOps, PMs should put themselves in the developer's shoes, understand their daily workflow, difficulties, and the language they use. If managing a mobile application, understanding how mobile apps are developed, basic architecture, coding processes, or app release procedures will be very useful.

This doesn't mean that Product Managers need to become engineers. As I understand, the goal is to understand enough to ask the right questions, evaluate trade-offs, write clear requirements, and not create too large a gap with the development team. A vague requirement like "make AI smarter recommendations" is very difficult for engineering to implement. But if PMs clearly define the user problem, input data, desired behavior, success criteria, and risk limitations, the technical team has a better foundation to build on.

Lessons also mention collaboration tools like Microsoft Office, Teams, Zoom, WebEx, Slack, Mural, Trello, Jira. For me, this isn't a list to "collect tool logos," but a reminder that Product Managers work across many channels: online meetings, documents, roadmaps, technical tickets, idea workshops, progress tracking. Tools are valuable only when they help teams understand each other and work more clearly.

Beyond engineering, Product Managers should also understand how marketing promotes the product, how sales sell it to customers, and how finance views the product through costs, revenue, profit margins, or investment risks. For instance, a feature might help marketing tell a more compelling story, but if sales can't explain the value within the first 2 minutes to customers, that feature still struggles to make an impact commercially.

There is a common counter-argument here: "If PMs don't code, why do they need to understand technicalities?" I think a reasonable answer is: A PM doesn't necessarily have to code production, but if they don't understand anything about development processes, technical limits, and technical debt, they are likely to set unrealistic expectations. Conversely, if PMs focus solely on technical aspects and forget customers and the business, they also deviate from their role. The balance point is to understand broadly enough to connect, and deeply enough in the product domain to make responsible decisions.

5. Soft skills: emotional intelligence, leadership by influence, and continuous learning

The soft skills section in the lesson is very dense, and I find it accurately reflects the "working with people" nature of Product Management. Skills mentioned include emotional intelligence, empathy, self-awareness, social skills, communication, collaboration, time management, leadership, and problem-solving.

Emotional intelligence isn't an abstract concept. It can start from recognizing when you're defensive in response to feedback, when an engineer opposes because they're "difficult" or because they truly see risks, when a customer is angry because of a product error or because they feel unheard. Empathy prevents PMs from turning a meeting into a tug-of-war, but rather a place to understand each party's motivation.

Conflict management skills are also very important because Product Managers often work with various roles. Which feature gets done first? Where to cut scope? Should the release be delayed to fix errors? Should priority be given to large customers or a broader user group? These aren't questions with neat answers for all situations. A PM needs to know how to coordinate, negotiate, and bring the team to a decision they can act upon.

Leadership in Product Management is also quite unique: it often involves leading by influence, not by direct authority. Others trust PMs because they see PMs understand the problem, have good arguments, know how to listen, know how to connect, and have the capability to bring work to completion. In other words, Product Managers don't just "propose," but also help the product reach closure.

Presentation skills are clearly noted: Product Managers need to know how to create and present presentations to various audience groups, from operational teams, internal teams, to C-level executives. A presentation with senior leadership often needs to be brief, clear in impact, and clear about decisions being solicited. A session with the technical team needs more detail about context, requirements, and constraints.

The last is time management and continuous learning. Product Managers have too many work streams: customer research, writing requirements, stakeholder meetings, reviewing data, updating roadmaps, handling feedback, tracking delivery. Without time management skills, PMs can easily get caught up in meetings and messages without leaving time for deep thinking. Continuous learning is mandatory as the market, technology, and user behavior continually change. For AI PMs, this is even more evident: new models, new tools, new expectations, and new risks appear very quickly.

After learning this section, I no longer view Product Manager as a "feature management" role. I see it as a role that needs to connect three layers: customer value, organizational execution capability, and business goals. To do this, PMs need business acumen, market research, customer connection, communication, negotiation, data thinking, technical understanding, clear requirement writing, roadmapping, influence through leadership, and continuous learning.

If you're also exploring Product Management or AI Product Management, I think there's no need to start by trying to learn all the tools at once. You can start smaller: choose a product you use daily, try writing a user story for a problem, guess what the technical team needs to know, how sales will sell that value, what metrics leadership will ask for, and whether users truly need it. Just one exercise like this can help you see the product more multidimensionally.

If you've ever self-taught PM, transitioning to AI PM, or have an example of a product that made you realize "feature creation" is far from "value creation," please share your experience.