DEV Community: Dai Nguyen

I Think AI Product Manager is Not Just “PM Knowing How to Use AI”

Dai Nguyen — Sat, 18 Jul 2026 10:35:52 +0000

I Think AI Product Manager is Not Just “PM Knowing How to Use AI”

There was a sentence in the lesson that made me pause for quite a while: according to PwC, AI is expected to contribute about $15.7 trillion to the global economy in the coming years. That number is too large to view AI as merely an “extra feature” for the product. It raises a very practical question: If products are increasingly driven by data, machine learning models, and automated decisions, who will ensure that these truly solve the needs of users and businesses?

I’m self-learning about the role of an AI Product Manager, and what I’ve realized is: An AI Product Manager is not simply a traditional Product Manager plus a few AI tools. This role requires a different way of thinking about products: not just asking "What features do users need?" but also "Which data is good enough for the model to learn?", "Is the model biased?", "When user behavior changes, does the product still make sense?", and "Do users trust AI’s decisions?"

If you're curious about AI PM, considering a career shift, or just want to understand why this role is mentioned more often, I think the most important point is: AI PM lies at the intersection of human needs, business strategy, and ever-changing AI systems.

1. Why Does the AI Product Manager Role Emerge At This Time?

I used to think that any Product Manager could manage AI products as long as they knew how to write a roadmap, prioritize features, and work well with engineers. But when I studied more deeply, I found that AI creates a new layer of complexity that traditional software products don’t always have.

Several major forces make the AI Product Manager role necessary. The first is the rapid development of machine learning, natural language processing, and generative AI. These technologies are no longer confined to labs or just for large tech companies. They start appearing in customer service, healthcare, education, retail, finance, manufacturing, logistics, and many other fields.

A common example: previously, an e-commerce app might only need product filters, a smooth cart, and payment process. Now, users may expect the app to understand their preferences, suggest suitable products, answer questions via chatbot, and even personalize promotions based on shopping behavior. If a competitor does that better, the business may lose market share, not because the product is “broken,” but because the experience is no longer competitive.

Secondly, there is business pressure. Companies integrate AI to improve customer experience, increase efficiency, reduce costs, or create competitive advantages. But AI doesn’t automatically create value just by being added. A chatbot giving incorrect answers can frustrate users more than delight them. A poor recommendation system could push unrelated products. An unfair risk scoring model can lead to serious consequences.

Thirdly is the technical complexity of AI products. AI products often rely on data pipelines, training data, model lifecycle, evaluation procedures, deployment, and continuous learning. It’s like building not just a store, but also a warehousing system, demand forecasting system, transportation system, and a learning mechanism from each purchase. If one link fails, the final experience may fail as well.

Practical advice for newcomers: don't start with the question "How to integrate AI into the product?" Start with the question “What problem truly needs AI for better resolution?” Not every problem requires AI. Sometimes a simple rule-based system, a UX improvement, or a clearer operational process is much more effective.

2. How is AI PM Different from Traditional Product Manager?

Traditional Product Managers often focus on identifying customer needs, prioritizing features, managing backlogs, coordinating with engineers, and bringing products to market. These tasks remain crucial for AI PMs. However, AI PMs must expand their interests to data, models, and how the system learns over time.

The first difference is moving from “feature delivery” to data-driven feature delivery. In traditional products, a feature is often clearly described: where the button is, what the user flow is like, what the error states are. With an AI product, the feature might depend on the prediction quality of the model. For example, if building a movie recommendation feature, the question is not just “where to display the movie list?” but also “does the viewing data represent enough?”, “does the model only suggest overly popular movies?”, “how to handle new users with no history?”.

The second difference is that AI PMs need to understand both user needs and data needs. Users might say “I want to find information faster,” but the AI PM has to delve deeper: what data accurately describes that need, is the data clean, is it legally usable, and does it miss any user groups. For example, if a recruiting app uses AI to recommend candidates, historical recruitment data might reflect past biases. If ignored, the model might repeat that bias as a form of “automation”.

The third difference is the working group. Traditional Product Managers typically work closely with software engineers, designers, marketing, sales, customer support. AI PMs still work with those teams but also need deep collaboration with data scientists, machine learning engineers, data engineers, and sometimes legal/compliance. In other words, AI PMs must understand the language of many groups to link them together with a common product goal.

The fourth difference is the roadmap. A traditional roadmap often relies on relatively stable requirements: this quarter work on feature A, next quarter work on feature B. With AI, the roadmap has to adapt to the model's learning cycle. You might plan to launch this month, but the data isn’t good enough. The model might perform well in testing, but its performance decreases in the real environment. User behavior may change, causing model drift.

A mild rebuttal I've heard is: “A competent traditional PM can still learn about AI; there's no need for a new role.” I partially agree. The foundation of product thinking is still core. But when AI becomes a central component of the product, having someone clearly responsible for data strategy, model risk, AI ethics, and testing cycles is crucial. Not to replace traditional PM, but to expand product management capabilities for a more complex product type.

Advice for newcomers: when reading AI case studies, practice analyzing them on three levels: what users need, what data is required, how the model should be evaluated. Just this habit alone will help you see AI products as less ambiguous.

3. Core Skills of AI PM Are Not Just Technical

What makes the AI PM role interesting to me is that it doesn’t require everyone to become an AI researcher, but it does require a sufficient level of “AI literacy.” AI literacy here means understanding concepts like bias, model drift, training data, accuracy, precision/recall at the application level, and model limitations.

For example, bias can be simply understood as a scale that’s skewed from the start. If the training data doesn’t represent various user groups, the model may deliver unfair results. Model drift is like using an old map for a city whose roads have changed. When first deployed, the model might predict well; after a few months, user behavior, market, or operational environment change, making predictions worse.

The second skill is data strategy. AI PMs need to care about data quality, availability, and governance. Is the data clean enough? Is it legally collected? Who has access rights? What data is sensitive? Are there policies for data retention and deletion? For example, a health care app cannot treat patient symptom data like click data on an advertising banner. The degree of privacy and governance must be much more serious.

The third skill is responsible AI: fairness, transparency, and privacy. This is not an “ethical decoration” part at the end of the project. For AI products, trust is a part of the user experience. If users don’t understand why AI makes a recommendation or feel the system is too intrusive on personal data, they might stop using the product.

The fourth skill is collaboration. AI PMs need to discuss model metrics with data scientists, deployment capabilities with engineers, AI result explanation with designers, growth goals with the business team, and risks with legal/compliance. An easy-to-imagine example: if building an automated customer support ticket classification tool, data scientists might optimize accuracy, engineers care about latency, support teams concern with processing flow, while end users just want the issue resolved quickly and correctly. AI PMs must help ensure these goals don’t drag each other too far apart.

The fifth skill is experimentation mindset. AI products are rarely perfect on the first try. They require A/B testing, model iteration, hypothesis-driven development, continuous measurement. Instead of saying “I think users will like this recommendation,” AI PMs should turn it into a hypothesis: “If we personalize recommendations based on the last seven days of behavior, click-through rate will increase without reducing product diversity.” Then verify it with data.

Practical advice: if you're just learning, choose a familiar AI product like Netflix, Shopee, Google Maps, or ChatGPT, and try writing a short page including: the user problem, required data, bias/privacy risks, success metrics, and how to A/B test. This small exercise is very useful for practicing AI PM thinking.

4. Three Realistic Scenarios that Helped Me Understand the AI PM Role Better

In healthcare, an AI PM might be involved in designing triage tools, which support prioritizing cases based on urgency and symptoms. The goal is not just to "predict correctly" but to improve emergency room efficiency, allowing critically ill patients to be treated faster. Here, mistakes are no longer minor. If the system underestimates the severity, the consequences can be great. Therefore, AI PMs must pay attention to symptom data, reliability, how doctors use suggestions, and how to explain results.

In manufacturing, an AI PM might lead the deployment of predictive maintenance models, analyzing real-time sensor data to predict when machines will fail. For example, a production line with sensors measuring vibration, temperature, and pressure. If the model detects abnormal signs early, businesses can maintain before the machine stops unexpectedly. The value here is very specific: reducing downtime, saving costs, stabilizing operations. But AI PMs also have to balance early warnings and false alarms. If the system raises too many alerts, the operation team will lose trust.

In retail, an AI PM might build a personalized recommendation engine based on shopping behavior across multiple channels. For instance, a customer looking at running shoes on the app, reading marathon articles on the website, then visiting a store to try products. A good recommendation system could link those signals to suggest more suitable products, increasing conversion rate. However, if over-personalized, users might feel surveilled. Therefore, the experience must be both useful and respect privacy.

These three examples show that AI PMs do not just work with "smart models," but work with decision-making systems in real contexts. Healthcare contexts differ from manufacturing, and manufacturing differs from retail. Success metrics, risks, and user expectations are also different.

Advice for newcomers: learn AI PM through specific industries. Don't just ask "What can AI do?" ask “In this industry, what decisions consume time, rely on much data, occur often, and if improved, will create clear value?”.

5. The Future of AI PM: More Opportunities, But Also More Responsibilities

What I find noteworthy is that AI PMs may no longer be just a role within technology companies. As AI becomes a part of business strategy, the demand for product managers who understand AI will increase in many fields: consumer applications, enterprise platforms, healthcare, energy, transportation, government, and digital transformation industries.

In the future, AI PMs might be viewed as an essential product leadership team because they help organizations turn AI from the “compelling idea” into real value. But with opportunity comes responsibility. As AI regulations increase, AI PMs will have to pay more attention to compliance, ethical design, and transparency. You cannot simply optimize for a growth metric while ignoring privacy, safety, or fairness.

Another point I really like is the trend emphasizing human-AI collaboration. AI PMs should not just think about how AI replaces humans in everything. Instead, a better question is: How can AI support humans in making better decisions? For example, in healthcare, AI can suggest priority levels, but doctors still need judgment rights. In customer service, AI can draft answers, but staff can adjust them to suit customer emotions. In data analysis, AI can find patterns, but humans need to ask the right questions.

For me, this is the part that makes the AI PM role more humane. AI PMs not only optimize model performance but also care about usability, trust, and long-term value. A good AI product is not one that amazes users in the first 5 minutes but is a product that they trust and want to use for the long term.

My main viewpoint after studying this is: The AI Product Manager is the natural evolution of product management as products begin to learn from data and affect deeper human decisions. If you’re exploring this field, don’t stress about knowing every algorithm right from the start. Start with product thinking, gradually learn about data, understand model limitations, and always ask about the real value to users.

If this article reminds you of an AI product you use daily, try to analyze it with three questions: what problem does the product solve, what data does it need, and what can cause users to lose trust? I’d love to hear how you view the AI PM role after this lesson.

I believe product management does not start from a "great idea", but from reducing guesswork

Dai Nguyen — Sat, 18 Jul 2026 09:00:14 +0000

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.

I think Product Manager is not just “product management”, but the person who keeps the product from drifting away from customers

Dai Nguyen — Sat, 18 Jul 2026 08:58:10 +0000

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.

Most people think AI Project Managers need to know AI models. I think they need something more important: the ability to connect data, models, infrastructure, and business goals.

Dai Nguyen — Tue, 07 Jul 2026 12:45:01 +0000

Dai Nguyen

Jul 5

Knowing AI Isn't Enough. Great AI Project Managers Connect Data, Models, and Products

#aipm #ai

8 min read

[Boost]

Dai Nguyen — Tue, 07 Jul 2026 12:40:39 +0000

Dai Nguyen

Jul 5

Knowing AI Isn't Enough. Great AI Project Managers Connect Data, Models, and Products

#aipm #ai

8 min read

Knowing AI Isn't Enough. Great AI Project Managers Connect Data, Models, and Products

Dai Nguyen — Sun, 05 Jul 2026 10:07:08 +0000

AI Project Manager: Connecting Data, Models, and Products

I've noticed a common scenario many junior team members face: as soon as the company mentions an "upcoming AI project," they immediately think of models, prompts, ChatGPT, LLMs, and chatbot demos. Yet, once the project kicks off, the focus shifts from "which model to use?" to questions like: Where will the data come from? Who has access? Which environment to deploy on? How to measure performance? How to handle a rollback when the model makes mistakes? And how should the backlog be written so developers, data scientists, and business teams understand? 😅

I believe the role of an AI Project Manager isn't about becoming a data scientist or cloud architect. Your real strength lies in connecting the dots: understanding enough about data architecture, AI platforms, DevOps, MLOps, GenAIOps/LLMOps, risk management, and utilizing AI to streamline project management itself.

1. AI Projects Begin with Data Architecture, Not Just Models

Looking at an AI architecture diagram on, say, Microsoft Azure, you’ll realize it’s not just a standalone "AI module." It’s akin to an industrial kitchen where ingredients are acquired, sorted, stored, cooked, and quality-checked before being served to customers. The AI model is only a part of this assembly line.

The first block is data integration and ingestion, where data is collected in periodic batches or real-time from multiple sources: ERP, CRM, IoT sensors, internal systems, files, and APIs. For instance, a retail company predicting product demand might pull data from sales systems, inventory, loyalty programs, and even store sensors. If this "ingredient import" phase is flawed, even the best model will only learn from insufficient or incorrect data.

Next, data management and storage deal with SQL databases, NoSQL databases, data lakes, distributed storage, encryption, access control, data catalogs, and metadata — essentially your "cold storage" and "inventory ledger." You need to know where data is stored, who can access it, whether it’s sensitive, and which version is used to train the model.

Following this is software development, covering backend, frontend, business logic, workflows, microservices, containers, authentication, and scalability. An AI model doesn’t naturally transform into a product; it requires web apps, mobile apps, APIs, business flows, logins, and permissions. Tools like GitHub and Jenkins aid CI/CD, while Terraform facilitates Infrastructure as Code deployment.

Then we reach the AI platform, housing machine learning, NLP, generative AI, and other models. This platform must support large-scale deployment, monitoring, and lifecycle management, providing an inference layer — the "execution engine" that takes input, processes it through trained models, and returns output.

Finally, we tackle other infrastructure aspects like APIs, messaging queues, streaming services, security tools, authentication, threat detection, access control, and AI model protection layers. For instance, if an internal chatbot accesses HR documents, you can't just ask if it answers correctly; you must know who asks what, where logs are saved, and if salary data exposure is possible.

Tips for juniors: Don’t attempt to learn all cloud services at once. Sketch a simplified AI project with five blocks: data entry, storage, app-model interaction, model operation, and security/monitoring. Creating this schematic view indicates substantial progress in project comprehension.

2. DevOps: The Foundation for More Than Mere AI Demos

A common counterargument is: "As an AI PM, why bother with DevOps? That's developer work." While you don't need to write Jenkins pipelines or Terraform modules, understanding DevOps is essential for managing timelines, release risks, testing environments, and distinguishing demos from fully-fledged products.

DevOps bridges software development and IT operations to deliver faster, more reliable, and trustworthy software. It emphasizes automation, CI/CD, infrastructure management, and real-time monitoring throughout the application's life cycle. For instance, when a feature for a product recommendation system is completed, CI/CD automates building, testing, and deployment across development, staging, and production environments, preventing risky manual copying.

An important concept is Infrastructure as Code (IaC), enabling server, network, and configuration files to be defined via code, ensuring consistent, scalable, and replicable environments. Imagine franchising a coffee shop — allowing each branch to brew based on "personal experience" would lead to chaos. IaC acts as the standardized recipe ensuring every branch has the correct setup.

DevOps also includes monitoring and logging — the system's "CCTV and logbook." When AI applications slow down, APIs time out, or users don't receive results, logs and metrics help teams detect, respond, and optimize performance swiftly. For AI PMs, these signals deeply impact release plans, SLA adherence, user experience, and business trust.

Tips: When joining a project, ask simple questions: how many environments does the team have, are releases manual or automated, where are logs viewed, how long does rollback take, who handles production incidents? You don’t need to be a DevOps engineer to ask these questions, but doing so marks a leap in project management maturity.

3. MLOps: Ensuring Model Longevity Post-Deployment

While DevOps stabilizes software operations, MLOps keeps machine learning models from becoming obsolete after production deployment. Many new AI learners skip this as they focus on model training, accuracy, notebooks, and demos. However, within businesses, models need to perform well continually, even as data, user behavior, and business goals evolve.

MLOps extends DevOps thinking across the entire machine learning lifecycle: data collection, model training, experimentation, validation, deployment, and monitoring. It involves version control for datasets and models, automated training pipelines, reproducible experiments, and governance. For example, if last month's fraud detection model used dataset A and this week's used dataset B, you need to know which version produced which result. Otherwise, when asked, "Why did the false positive rate increase?" the team struggles to respond.

Data drift is a crucial concept — the change in data distribution over time between training and production data. Think of it like acing past exam papers but the new year's format changes entirely. You're not less capable; your practice data no longer reflects reality. AI faces similar challenges. A travel demand prediction model trained pre-pandemic might perform poorly once travel behaviors shift.

MLOps also manages model updates, scales inference workloads, continuously evaluates model performance, and executes rollbacks or updates as needed. If a new recommendation model reduces revenue, the team needs quick rollback mechanisms. If requests surge during sales, the inference system must scale.

MLOps also covers traceability, auditability, documentation, and compliance with business, legal, and ethical standards. AI PMs should be particularly vigilant here. Models in finance, healthcare, or insurance need more than "high accuracy" justification. Teams must explain which data was used, who approved it, when models changed, and whether they comply with regulations.

Tips for juniors: When writing tasks or acceptance criteria for an AI feature, don't just record "model must achieve accuracy X." Include criteria on data, versioning, monitoring, rollback, and documentation. For instance: "Model versions must be logged in the registry; the dashboard must display latency, error rate, and key metrics; rollback options for prior versions must be available." Such statements reflect AI PM-like thinking rather than simply minute taking.

4. GenAIOps and LLMOps: Confidence Is No Guarantee of Accuracy

Generative AI and large language models spice things up but also introduce operational complexities. GenAIOps and LLMOps are specialized MLOps branches focusing on the operationalization of generative AI models. These models are large, resource-intensive, latency-prone, ethically risky, and control-challenged.

Regarding performance and cost, GenAIOps/LLMOps employ techniques like quantization, pruning, distillation, distributing workloads between edge and cloud, which make models "leaner, faster, cheaper" while maintaining adequate quality. For example, a customer support chatbot shouldn't take 15 seconds to respond due to model heft. Users will abandon it before it displays its intelligence.

Prompt optimization, continuous evaluation, and AI red teaming are distinctive aspects. A prompt isn’t just a question typed into ChatGPT; in actual products, it’s a system design component. Teams need to test prompts for information leakage, user jailbreak attempts, and off-topic responses. Red teaming involves bringing in "attackers" to find weaknesses before real users or malicious actors do.

GenAIOps/LLMOps also monitor output for hallucination, bias, and toxic language. Hallucination occurs when models confidently deliver incorrect responses. For example, an internal chatbot inventing a non-existent leave policy. While seemingly trivial, if followed, the operational and legal fallout could be severe.

Teams need feedback loops and retraining or parameter adjustment mechanisms based on real-world usage. Security takes center stage: safety filters, access control, compliance checks, protection of private data, and avoidance of harmful or sensitive content generation. Real-time use cases like chatbots, virtual assistants, and enterprise search must ensure low latency, high availability, and efficient scaling.

Tips: If on a GenAI project, add these questions to your checklist: What can the model fabricate, who checks answers, does the prompt have versioning, is there content filtering, do logs capture sensitive data, can users provide feedback, what metrics assess quality beyond "appears okay"? These questions help avoid turning AI into a "confident black box."

5. AI Project Managers Cultivate System Maturity, Not Just Tasks

What I appreciate about the AI Project Manager role is its flexibility — there isn’t a single way to manage AI projects. Business and technology environments are still shaping standards, best practices are clarifying, but each organization has its maturity level. This presents both challenges and opportunities for young professionals.

If you see AI PMs as just Jira updaters, deadline reminders, and meeting note-takers, you'll miss the best part. Skilled AI PMs operate tactically to manage specific projects but also contribute to overall AI strategy and technical discussions. You’re not deciding architecture like an architect, but you can query: does this project enhance the company's AI maturity, does it allow data or pipeline reuse for future projects, are additional databases, frameworks, or governance tools needed?

The three operational groups — DevOps, MLOps, and GenAIOps/LLMOps — complement each other. DevOps ensures software and infrastructure reliability; MLOps manages the ML model lifecycle; GenAIOps/LLMOps address generative AI and LLM nuances like prompts, hallucinations, safety, latency, and cost. As an AI PM, observe your organization’s maturity across these realms, enabling teams to adopt the best practices and tools suitable for scaling.

Your role doesn’t end after implementation. It extends into productization and daily usage. As backlogs wrap up, systems continue releasing new features, collecting performance metrics, assessing model efficacy, and determining whether experimentation can transition into real products. Here, automation, traceability, pipelines, monitoring, and governance demonstrate their value.

A common misconception is equating "managing AI projects" with "AI for project managers." Managing AI projects involves overseeing projects with AI components: data, models, software, operations, and risks. AI for project managers involves using AI to enhance PM tasks: writing user stories, summarizing meetings, analyzing backlogs, creating templates, planning assistance. Both are valuable, but distinct.

A practical example: use AI for backlog enrichment. From meeting transcripts or requirement documents, prompt AI to create technical stories following this structure: Title, priority, points estimate, story description, acceptance criteria. If information is lacking, AI notes "TO BE DEFINED." You can also request outputs as Jira-compatible data models, exporting as JSON or CSV for tool import. Remember: AI drafts only. PMs must verify logic, consult the team, confirm criteria, and keep the backlog accurate.

Final advice: develop a "T-shaped skill" set. Broadly understand data, software, AI platforms, DevOps, MLOps, LLMOps, security, and governance. Deeply focus on project management, stakeholder communication, backlog management, risk management, and delivery. You needn't master everything immediately. However, each week, choose a concept and ask: "If I were a PM in this project, what should I ask to mitigate risks?"