I believe product management does not start from a "great idea", but from reducing guesswork
There is a situation I find very common when first learning about Product Management: someone comes up with a feature that sounds quite reasonable, the whole team gets excited about how to do it, and only after a few weeks do they realize that customers don't really need it, the sales team doesn't know who to sell it to, and the engineering team has wasted a considerable amount of effort. Previously, I used to think that product management was mainly about "coming up with new products" or "writing requirements for the development team". But as I learned more deeply, I realized that product management is much more expansive: it is how a company imagines, plans, develops, tests, launches, distributes, and ultimately withdraws the product from the market.
My perspective after this lesson is: good product management is not about making the product sound more enticing, but about reducing guesswork in costly, time-consuming decisions that affect customers. A Product Manager not only asks "what to do next?" but also has to ask "why do it?", "who really needs it?", "does this align with the company's strategy?", and "what stage is the product at in its lifecycle?".
If you are learning about this field, especially AI PM or Product Management in general, understanding this foundation is very important. Because before talking about roadmap, data, AI, growth, or strategy, we need to understand what Product Management is actually managing: not just a list of features, but the entire life journey of a product.
1. Product Management is managing the entire product lifecycle, not just managing features
The first point that made me adjust my understanding is the very broad definition of Product Management. It includes how the company conceives, plans, develops, tests, launches, delivers, and retires the product from the market. In simpler terms: from the moment an idea is still on paper, to when it is built, tested, launched, operated, improved, and possibly replaced or discontinued.
A common example: imagine a coffee shop wants to sell a new type of drink. If only looking from a "feature creation" perspective, the owner might say: "Create a matcha milk tea, it's trendy." But from a product management perspective, they will have to ask more: do current customers like this flavor, does the cost of ingredients make the profit margin too low, can the staff consistently make it, should this be tested at one branch first or launched system-wide, and if the trend fades, should we keep it? That is thinking about the product lifecycle in a very small example.
In the company, Product Managers are often responsible for analyzing the market and customer needs, then making recommendations about developing new products or improving existing ones. The goal of these recommendations is not just to "create something new", but to create products with the potential to be profitable for the company. This is a very realistic point: a product may be good, beautiful, technologically advanced, but if it doesn't create enough value for customers and the business, it's hard for it to survive long.
Effective Product Management helps avoid three quite dangerous things: guesswork, developing in the wrong direction, and missing opportunities. Guesswork occurs when the product team goes by intuition. Developing in the wrong direction happens when the company invests in something customers don't need or aren't willing to pay for. Missing opportunities occur when the market has given clear signals but the organization doesn't recognize them or reacts too slowly.
Practical advice for beginners: when you read about any product, don't just ask "what features does it have?". Try asking these four questions: who does this product serve, what pain does it solve, where does the company earn or create value, and when might this product need to change or be replaced? These four questions alone can help you view a product more like a PM than an ordinary user.
2. Internal and External: not every product is for the final customer
An idea I find easily overlooked is that Product Management has two different focuses: internal and external. When hearing the word "product", I often immediately think of apps, websites, cosmetics, phones, cloud services, or payment gateways. But in reality, many products are built not to be sold directly to external customers, but to serve the internal organization itself.
The internal aspect of Product Management involves applying product management principles and techniques to develop tools used within the company. These products are not for consumers but help improve processes, procedures, and operational efficiency. Examples include human resource information systems (HRIS), customer relationship management systems (CRM), enterprise resource planning systems (ERP), or other internal tools.
Specific example: a company has a sales team that must input customer information into several different Excel files. The data is duplicated, managers find it hard to track the pipeline, and new employees spend a lot of time learning the process. If the company builds a better internal CRM, that is also a product. Its users are the sales team, customer service team, and management team. The problem to solve is not "make an app for customers to download", but "help staff work faster, more accurately, and with fewer errors".
Conversely, external product management focuses on products and services for customers outside the organization. They can be tangible products like cosmetics, electronics, or digital products like payment gateways, cloud services, ride-hailing apps, online learning platforms. Here, the Product Manager must understand the market, customer behavior, competition, positioning, pricing, distribution channels, and user experience.
A slight rebuttal might be: "Do internal products need to be managed as formally? After all, the users are company employees, they have to use it." I think this is quite a dangerous mindset. Because if the internal tool is hard to use, employees will find ways to bypass the process, use separate files, send separate messages, or enter data perfunctorily. The company might think it has digitalized, but in reality, it has only transferred chaos from paper to software.
For newcomers, a good exercise is to choose a tool you use every day, such as Google Calendar, Notion, a time attendance system, a banking app, or an e-commerce site. Then classify: is this an internal or external product? Who are the main users? How is the success of this product measured? If it's an internal tool, it could be time-saving, error reduction, increased process compliance. If it's an external product, it could be revenue, retention rate, number of transactions, satisfaction level, or market share.
3. There is no single Product Management organizational model
A point that makes Product Management both interesting and difficult to learn is: there is no one organizational model that applies to every company. The product management structure can change significantly depending on the company's size, industry, culture, and specific needs.
At startups, the structure is usually simpler. There might only be one Product Manager, or the founder also takes on the product role. This person talks to customers, prioritizes features, works with engineering, and sometimes supports marketing and sales. For example, a startup building a personal finance management app might only have a CEO, a few engineers, one designer, and one person in charge of the product. Product decisions happen fast, with fewer approval layers, but can also easily depend on a few people's intuitions.
In large companies, the structure is much more complex. There might be multiple Vice Presidents, multiple strategic business units, each with a Director level leader responsible for Product Management. A tech conglomerate might divide products by segments: cloud, payment, consumer app, enterprise solution. Each segment has several small teams responsible for individual product lines or customer segments.
Product Managers might report directly to the CEO or senior leaders in companies where product decisions are tightly linked with overall strategy. This usually happens when the product is the heart of the company, such as a SaaS platform seeking product-market fit or a tech company where the roadmap determines the entire business's direction. In other cases, Product Managers might reside within a business unit, a specific department, or be integrated into other functions like marketing, engineering, or operations.
My takeaway is not to hastily judge whether a company does "correct or incorrect" product work just based on the organizational chart. A Product Manager in an engineering room is not necessarily doing only technical work. A Product Manager in a business unit isn't necessarily lacking in strategy. The more important question is: who has the authority to make product decisions, how well-informed are these decisions by data and customer insight, and do the teams collaborate well?
Advice for newcomers when reading a Product Manager job description is to pay attention to the reporting line and stakeholders. If the JD says to work directly with the CEO, the role might lean towards company-wide strategy and prioritization. If the JD states close collaboration with sales, marketing, and customer success, the product might be in the market and needs growth optimization. If the JD emphasizes working with the engineering team, backlog, sprint, the role might be closer to daily execution. No option is automatically better; they just develop different skills.
4. Upstream and downstream: one looks to the future, one takes care of the product after birth
The lesson of dividing Product Management into upstream and downstream gave me a clearer framework. Upstream involves strategy, roadmap development, and new product creation. Downstream involves the product lifecycle after launch, including growth, maturity, decline, and post-launch marketing and sales activities.
In upstream, Product Managers are responsible for strategic planning, understanding the current and new product portfolio of the company, and ensuring new product ideas align with the overall vision and add value. For example, a company with an English learning app for adults wants to expand to a children's product. Upstream PM will not just ask "can we add animated interfaces?", but need to assess whether the children's market fits the company's capabilities, whether parents are willing to pay, if the current brand is trustworthy enough, and whether the new product will dilute resources from the main product.
The roadmap in upstream should not just be a list of features by quarter. The way I understand it, the roadmap is like a strategic intention map: where the company wants to go, which problems it prioritizes, which customer group it serves, and why those steps are in that order. If the roadmap is just "do A in March, B in April, C in May" without clear reasons, it easily turns into a mere task calendar rather than a strategic tool.
Downstream is closer to taking care of the product as it steps out into the market. Products typically go through three stages: growth, maturity, decline. In the growth stage, the goal might be user acquisition, improving onboarding, increasing conversion. In the maturity stage, the product is more stable, competition is stronger, so it's necessary to optimize for profitability, retain customers, and upgrade experiences. In the decline stage, demand reduces or technology changes, and the company must decide to reform, replace, narrow, or discontinue the product.
A clear example is smartphones. When a new line is launched and grows well, the company focuses on communication, expanding distribution, updating software. When the line becomes mature, they optimize pricing, release new color models, warranty packages, or exchange programs. When the product enters decline, the company might stop production, reduce support, or move customers to the new generation.
Downstream also includes marketing and sales after the product is launched. I see this as important because many new to product focus too much on the "build" phase and forget that products do not automatically reach users. A good product with a wrong positioning, confusing messaging, sales that don't know how to sell, or customer success that can't support well, can still fail.
Practical advice: when analyzing a product, try to identify which stage it's in during the lifecycle. A newly launched app requires different questions than an enterprise software that has existed for 10 years. For a new product, focus on problem-solution fit and adoption. For a mature product, look at retention, profitability, and differentiation. For a declining product, consider whether to improve, re-position, or discontinue.
5. Product Management is not Project Management, though the two roles are very easily confused
One of the most common confusions is viewing Product Management and Project Management as the same. I also used to confuse them: thinking the Product Manager is the one managing the product’s development timeline. But the lesson clarifies that these two roles differ in focus.
Product Management focuses on strategy and product. It asks: what problem should the product solve, for whom, why now, which priority is the most important, what is the business value, what stage is the product at, and what is the next direction? The Product Manager must continuously balance customer needs, company goals, technical capabilities, and market context.
Project Management focuses on executing the necessary tasks to implement the strategy or product. It asks: what tasks need to be done, who is responsible, when is the deadline, how do groups depend on each other, where are the timeline risks, are the budget and resources sufficient? The Project Manager helps the plan to be implemented orderly and as committed.
Everyday example: if building a new kitchen for a restaurant, Product Management is like deciding what business model the kitchen needs to serve: take-away or dine-in, what the main dish is, what speed of serving is needed, what space the chef requires, what quality customers expect. Project Management is like planning the construction: when to buy equipment, who installs the electrical system, when to conduct safety checks, and whether the cost exceeds the budget.
Top comments (0)