DEV Community: Dai Nguyen

Why I believe understanding the product lifecycle correctly helps you feel less confused when self-studying product management

Dai Nguyen — Thu, 06 Aug 2026 17:22:12 +0000

Why I believe understanding the product lifecycle correctly helps you feel less confused when self-studying product management

When I first started self-studying product management, I kept pondering one question: "When does a product die?" I remember early this year, I bought a phone that had just been released, and I was very excited. As it turned out, after just a few weeks, it froze, the battery drained abnormally fast, and it took two full months before the manufacturer released a patch. I didn't understand how a "brand new" product could be that bad. It wasn't until much later that I learned this is a natural part of the product lifecycle – and that it's not just electronic devices, but everything from software, soft drinks, to cars that go through their own trajectories.

My perspective after a period of self-study: many people are confusing the product lifecycle with the product management lifecycle, leading to wrong expectations at each point in time. The product lifecycle is about how the product itself goes from birth to retirement – while the product management lifecycle is the process that the product team should follow. Grasping the four stages: introduction, growth, maturity, and decline – like having a map – helps you know where you stand and what to do next, instead of panicking the moment a product seems to be "faltering."

Making the distinction from the start: the product lifecycle is not the product management lifecycle

I've read many articles that use these two terms interchangeably, so today I want to clarify this right away. The product lifecycle refers to the stages that the product itself goes through – from the initial idea, being designed, manufactured, brought to market, growing, plateauing, then declining and being discontinued. The product management lifecycle, on the other hand, is the process that the product management team applies to make decisions, plan, and execute throughout that product's life.

Imagine the product lifecycle as a human life: being born, growing up, starting a family, then growing old. The product management lifecycle is like how parents raise a child – caring, teaching, guiding. They are two different things, but they complement each other. If you're self-studying like me, separating these two concepts helps you avoid confusion when reading materials or in interviews – this is also a classic question in product-related discussions.

The introduction stage: a launch can be "imperfect," and that's normal

According to the video I learned from, the introduction stage begins when the product first reaches customers. It includes understanding needs, research and vision development, design, manufacturing, all the way to sales strategy, marketing, supply chain operations – everything needed to bring the product to market. The first buyers at this point are called "early adopters" – they buy early for various reasons: curiosity, wanting to experience it, or genuinely needing that feature.

Interestingly, this stage is often not perfect. Take phones or software for example – I've experienced it myself, and in the lesson they clearly state: electronic and software products often have errors, have bugs, and these get fixed gradually as the product matures. Product managers spend a lot of time "spreading the word" about the product, making it accessible, while also listening to feedback and learning how to improve. In fact, there's a real chance the product fails right here – not every product survives this stage.

Advice for those new to the field: don't panic when you see an early launch version with bugs. Instead of concluding "the product is bad," watch whether the product team is handling bugs quickly and whether they're listening to early users. As a self-learner, you can practice reading blogs after a new product launches – observe what they say about the first feedback loop. That's good practice for understanding the introduction stage.

The growth stage: accelerate but be careful with every step

When a product gets past its early period, it enters the growth stage. Here, product managers ramp up marketing efforts. Even though it's a sign of progress, there's still much to do: marketing strategy may change, production capacity may need to be expanded. The video emphasized that this stage must be executed carefully, because one mistake can negatively affect a product that's already on the market. The goal is to continue growing the product and market share to maintain vitality.

I relate this stage to a runner who's covered the first stretch and now wants to run faster, but if they change their posture suddenly, they can easily get injured. It's completely different from the introduction stage – at that point you're just focused on signaling to people that the product exists; now you need to optimize everything. If you pay attention, software companies often roll out promotions, ramp up advertising, and simultaneously expand servers to handle the surge in users.

Beginners like us should learn to look at growth metrics (revenue, active user numbers, market share) to assess whether the product is heading in the right direction. But also don't forget to observe whether quality is being compromised when scaling too fast – because that's an important lesson from this stage.

The maturity stage: growth plateaus and "slow and steady wins the race"

Most products spend the majority of their time in the maturity stage – growth tends to flatten out. Marketing becomes more sophisticated, starting to introduce nuances and minor product variations. Look at soft drinks: a new flavor from the same brand appears, or cars that change only slightly each year – adding some aerodynamic technology, a new safety feature – but rarely undergoing complete transformation.

I find this extremely interesting because it reflects real life: at some point, the boom gives way to stability. If you've ever seen a product that's "no longer as hot" as before but still sells steadily, that's the maturity stage. Companies try to optimize profits from the product, cut production costs, and polish small upgrade versions.

For those self-studying, I recommend picking a familiar product (such as a soft drink or a car model) and tracking its history. You'll see that the maturity stage can last many years – and recognizing it helps you not feel confused when the product is no longer "growing at lightning speed" like at first. One point worth considering (a light counter-argument): some people think maturity is a sign the product has "no room left," but in reality this is the stage that yields the most profit thanks to low marketing costs and a loyal customer base.

The decline stage: not an ending, but an opportunity for the next product

When the customer market shifts, the product begins to decline and eventually ends its lifecycle. Product managers at this point must focus on strategy for developing the next product. The classic example is CDs and DVDs – they were gradually phased out as streaming services became popular. I remember when I was young, every household had a shelf of music discs; now you just open Spotify or Netflix.

Decline isn't scary. It's like a piece in the bigger picture: old products leave to make way for new products

I Think Soft Skills are the 'Hard to Measure But Essential' Part of a Product Manager

Dai Nguyen — Sat, 01 Aug 2026 08:49:39 +0000

I Think Soft Skills are the "Hard to Measure But Essential" Part of a Product Manager

Introduction

There is a scenario that I find very easy to picture when starting to learn about Product Managers: a product is behind schedule, the technical team says the requirements aren't clear, the business team says customers are getting anxious, and the users care about only one simple thing: “When will this feature be usable?”. From the outside, I used to think that Product Managers primarily needed to know about roadmaps, backlogs, data, markets, or a bit of technical skills. But the more I learn, the more I realize another less "glamorous" part is crucial: soft skills.

As I understand it, soft skills are non-technical skills that help a person professionally interact with others in work and social contexts. For Product Managers, skills like leadership, research, analytical thinking, communication, creativity, and teamwork are not just decoration to make a CV look good. They are tools to turn a group with many perspectives into a team working towards a meaningful product.

This is important for anyone exploring Product Management because products rarely fail just because of a lack of ideas. Often, the problem lies in the team not understanding the same goal, data not being read correctly, conflicts not being dealt with, or the product vision not being clearly communicated.

1. Soft Skills Aren't as "Soft" as Their Name Suggests: They Help the Team Move in One Direction

The first point that caught my attention is that soft skills are not just about "talking nicely" or "getting along with others". In the role of a Product Manager, soft skills help create motivation, inspire, encourage collaboration, and form a shared product vision. If a product is like a journey, then the product vision is the map; soft skills are how the team agrees on where they’re going, why they’re doing it, and how to handle rough patches.

An everyday example: if a group of friends is organizing a trip, some want to relax, some want to explore, some only care about the budget. Without someone clarifying the common goal, the group can easily keep arguing over accommodation, itinerary, and transportation. Product teams are similar. A designer might prioritize a smooth experience, an engineer might care about stability, sales might want features to close deals, and customer support might see repetitive complaints. A Product Manager doesn't have to be the one giving orders, but needs to help everyone see the bigger picture.

I see this as why soft skills are practically valuable: they help teams move past obstacles instead of getting stuck in blame. When a problem occurs, for instance, a new feature doesn't meet expectations, a Product Manager with good soft skills won't just ask "who made a mistake?", but will bring everyone to the more important questions: "What does the data say, what issues are users facing, and how should we adjust?"

A small tip for beginners like me: when reading a product case study, don’t just ask “what feature did they build?”. Also ask: how did the team collaborate to reach that decision? This question helps us see Product Management closer to reality.

2. Leadership in Product Management is About Building Trust, Not Always About Authority

One idea I find very memorable is that Product Managers need to have leadership skills, especially in competitive and uncertain environments. But leadership here doesn't necessarily mean having the highest title or deciding everything. I understand it as the ability to provide direction the team can trust, even when things get tough.

In a product team, differences between members are inevitable. Technical people might think a requirement takes too much effort. Business people might feel missing out if not done immediately. User researchers might argue that customers don’t really need that feature. Good leadership doesn’t turn these differences into "factions", but into assets. Each perspective is like a piece of the puzzle helping product decisions be less one-sided.

Illustrative example: imagine a team deciding whether to add an “automatic suggestion” feature to an app. Sales says big clients are asking for it. Engineers say the current data isn’t clean enough. The designer worries users will get confused. A Product Manager with good leadership won't simply side with whichever sounds most persuasive. They can help the team identify priorities: what goal this feature serves, what the biggest risk is, if it can be tested on a small scale first, and what criteria will be used to measure success.

The lesson I draw is that leadership also involves helping the team set priorities, bringing meaning to the work, reducing frustration, and supporting conflict resolution. When people understand why their work matters, they cooperate more easily. When goals are clear, the team works more efficiently because they are less drawn into circular debates.

However, I also think it’s important to be cautious of a misconception: leadership doesn’t mean always being certain. In Product Management, many decisions are made when information is imperfect. A trustworthy leader isn’t someone who never errs, but someone transparent about assumptions, listens to rebuttals, and is willing to adjust as new data emerges.

3. Research and Analytical Thinking: Listen to the Market, But Don’t be Led by Data

Product Managers often have to research a lot: products, markets, competitors, factors affecting the product, customer motivations, and growth potential. I like how the lesson emphasizes that data is one of the most important assets, but data is only useful when we think seriously about it with analytical thinking.

Research helps Product Managers understand where the product can go. For example, if a language learning app sees many people quitting after the first week, research might start by looking at behavioral data, user interviews, feedback, comparison with other products. But merely gathering information isn’t enough. Analytical thinking helps break a large problem into smaller parts: do users quit because lessons are too difficult, because they don't see progress, because reminder notifications are annoying, or because their initial goals aren’t clear enough?

An easy analogy is going to a doctor. A doctor can’t just look at one symptom and conclude immediately. A fever can come from many different causes. More questions, tests, and context are needed. Product Managers are similar. If one sees the conversion rate drop and concludes “change the interface”, they might be overlooking the real cause: price changes, wrong marketing message, slow loading speeds, or users not understanding the product’s value.

I find analytical thinking particularly useful because it helps us find logical connections from data, rather than opting for the easiest explanation. It also helps tackle complex problems by breaking them down: who is affected, at what step they are stuck, how severe it is, what goal it impacts, and what initial solutions can be tested.

A gentle counter-argument here is: some might say “Product Managers who analyze too much will be slow, losing opportunities”. I find this somewhat true. If always insisting on enough data before acting, the team might miss market timing. But conversely, acting solely based on intuition is also very risky. Perhaps the balance is using analysis to clarify the most important assumptions and then testing small enough to learn quickly. For newcomers, a practical tip is to practice writing down assumptions before reaching conclusions: “I think users need X because of data Y, but I’m not sure about point Z”.

4. Communication and Creativity: Be Clear to Understand Together, Think Differently to Avoid Stagnation

Communication is a skill I used to underestimate, as it sounds too familiar. But in Product Management, communication isn’t just about presenting well or writing documents. It’s about being able to work with many types of people who have different communication styles. An engineer might want very specific requirements. A high-level stakeholder might need a strategic overview. A customer might only describe the issue with a feeling: “This step is too annoying for me”. A Product Manager needs to translate these different languages into a shared understanding.

For example, when talking to the technical team, saying “users want this screen to be easier to use” is too vague. But if it’s explained as “users take an average of 3 minutes to complete this step, 40% exit at the information input field, and the goal is to reduce mandatory fields from 6 to 3”, the conversation becomes more concrete. Conversely, when talking to business leaders, just detailing technical aspects might not answer the questions they care about: impact on revenue, user retention, cost, or risk.

Communication is also tightly linked with leadership because to share vision and drive participation, a Product Manager must convey what they are aiming for accurately. If a vision is only in one person’s head, it isn’t truly a shared vision. It needs to be spoken, written, illustrated with examples, repeated when needed, and adjusted as the context changes.

Besides communication, the lesson also mentions creativity and innovation. In a constantly changing tech environment where customer needs change quickly, a Product Manager needs to think differently to create competitive advantages. I understand “think outside the box” not as coming up with bizarre ideas to be unique, but not getting stuck in old solutions when the problem has shifted.

For instance, if users complain they spend too much time entering data, the solution isn’t necessarily just to “make the form prettier”. It could be auto-fill, document scanning, integrating data from other sources, or omitting an unnecessary step. Creativity here serves real needs, not just to make the product appear fresh.

Practical advice for beginners: practice explaining the same idea in three different ways: one for technical people, one for business people, and one for general users. Then, try asking, “Is there a way to solve this problem without adding new features?” That question often opens up more creative paths.

5. Teamwork and Judgement: Know When to Lead, When to Step Back

Teamwork is a very important part of Product Management because a product is rarely created by a single individual. Effective teamwork means everyone is working towards a common goal, understands their roles and responsibilities, trusts each other, and collaborates well. When conflict arises, an effective team doesn’t avoid it, but also doesn’t let it drag into personal issues. They handle it quickly and constructively because they stay focused on the ultimate destination.

An everyday example: on a soccer team, forwards, goalkeepers, and defenders have different roles. If everyone just runs after the ball without understanding their position, the team will be in chaos. But if each only focuses on their part without cooperating, the team will struggle to win. Product teams are similar. Engineers, designers, marketers, researchers, sales, and support all have their own specialties, but a successful product requires collaboration between these specialties.

What I found most interesting in the lesson is that no soft skill is always the most important in every situation. A Product Manager needs to use judgement to apply the right skills at the right time. Sometimes analytical thinking is more important than creativity, especially when the team needs to understand the root cause of a problem. Sometimes creativity is more necessary, particularly when familiar solutions are no longer effective. Sometimes a Product Manager must play the role of a team member, listening and supporting. Sometimes the team needs the Product Manager to step up, provide direction, and help everyone agree on decisions.

This is the part that makes Product Management challenging but interesting. There’s no rigid formula like “just communicate well is enough” or “just having data is a win”. The success of a product depends on wisely applying these skills. If applied at the wrong time, a good skill can backfire. For example, over-analyzing when the team needs to make a quick decision can slow progress. Conversely, pushing for continuous innovation when the team hasn’t resolved core issues can complicate the product further.

For those newly learning, I think a simple exercise is when reading a product situation, ask yourself: “What skill is most lacking here?”. If the team is arguing without clear goals, it may lack leadership and communication. If the team is doing a lot but doesn’t know what users need, it may lack research. If there’s a lot of data but disorganized conclusions, it may lack analytical thinking. If people are working disjointly, it may lack teamwork.

Conclusion

After studying this section, I view the soft skills of a Product Manager more realistically: they aren’t secondary skills, but the foundation that helps someone connect data, people, markets, and product vision. Leadership gives the team a trustworthy direction. Research brings understanding of the market and customers. Analytical thinking helps break down complex problems to find reasonable solutions. Communication helps different groups of people understand the same thing. Creativity drives innovation to keep up with changing markets. Teamwork helps everyone move towards a common goal.

What I want to remind myself is: learning Product Management isn’t just about learning tools or terminology. It’s also about learning to ask better questions, listen more attentively, express more clearly, and make better judgments in each context. If you’re also exploring this topic, you might try choosing a product you use daily and analyze: if you were the Product Manager of that product, what soft skills would you need most this week? If you have any interesting learning thoughts or experiences, please share so we can continue learning together.

For more AI PM perspective updates: according to Toolify.ai, skills like effectively communicating between technical and non-technical groups and analytical thinking for data-driven decision-making,

Nguồn tham khảo: https://www.toolify.ai/vi/ai-news-vn/ai-product-manager-nh-ngha-k-nng-vai-tr-trong-tng-lai-3608392?utm_source=openai

I Think “Product” is not Just What is Sold, but the Entire Experience That Needs to be Managed

Dai Nguyen — Sun, 26 Jul 2026 15:31:49 +0000

I think “product” is not just what is sold, but the entire experience that needs to be managed

There was quite an interesting moment when I learned about Product Management: I realized that I previously understood the concept of a “product” too narrowly. Before, if someone asked what a product was, I would immediately think of a phone, a car, a book, a software package, or a specific item that could be purchased. But this lesson made me see it differently: a product is not just something on a shelf or an app on a phone. It could be a service, an assembly of several components that deliver what customers want, or even the entire customer experience before, during, and after use.

This is important for anyone exploring Product Management, especially those like me who are stepping into this field from not much prior experience. If you understand a product too simply, you might think a Product Manager just “manages features” or “pushes the team to finish things.” But if you see a product as a lifecycle of experience, the role of a Product Manager becomes broader: understanding customers, categorizing products, choosing appropriate development paths, coordinating with various parties, and continually making decisions in conditions that are not always clear.

1. A product is not just an item: it is what customers experience throughout its lifecycle

The first point that I found memorable is the definition of a product being much broader than everyday talk suggests. A product can be a tangible good, like cars, furniture, laptops, food. But a product can also be a service, like carpet cleaning, lawn care, construction, or software provided as a service. Some places even use the term “offering” to encompass both tangible products and intangible services; in such cases, a “Product Manager” is sometimes called an “Offering Manager.” However, in this learning approach, “product” is used in its broadest sense, including goods, services, solutions, and experiences.

The example of a car in the lesson made it quite easy to understand. Customers do not only “experience the product” when they drive the car after purchasing. They have begun experiencing it earlier: hearing friends talk about it, seeing advertisements, noticing it in movies, reading reviews, test driving. After purchasing, the experience continues through maintenance, repairs, daily use preferences, resale value, or deciding to switch to another model. Even when the car is sold, that experience can influence the next purchase.

For a more everyday example, a coffee shop does not just sell coffee. Customers might be attracted by images on social media, how employees greet them, the aroma of coffee upon entering, the speed of service, power outlets for those working, the music in the shop, and even how the shop handles mistakes with their drinks. All these things create the “product” in terms of experience.

My takeaway advice is: when learning Product Management, don’t start with the question “what features does this product have?” instead start with “what do customers experience, at what touchpoints?” This question helps me see more broadly and avoid just listing functions.

2. Not all products are the same: customers, markets, and approaches vary greatly

Another important part is the way products are categorized. Physical products can be divided by customers, brands, product lines, associated services, or small improvements on previously launched products. It may sound theoretical, but when looking at examples, it’s quite practical: an instant noodle package, a yacht, an office furniture set, and an internal ERP system are all “products,” but managing them cannot be the same.

The first group is consumer products, targeting individual users in everyday life. This could be a car, food, furniture, books, or common household goods. For this group, brands, packaging, emotions, price, distribution channels, and buying habits often play a big role. For instance, when buying a book, I might be influenced by the cover, the introduction, reviews from other readers, and the author’s reputation.

There are also specialized or high-value products, such as yachts, custom sports cars, or tailor-made goods. Here, there are fewer customers, but expectations are often higher. Personalized experience can be as important as the product itself. A closer example is tailoring a suit: the buyer not only needs a fitting suit but also cares about fabric consultation, the number of fittings, delivery time, and the personalized service feeling.

The lesson also mentions products that people usually do not proactively want to purchase, such as funeral-related products or items considered undesirable. This is a group I ponder over a lot, as it shows Product Management does not always revolve around “shopping joy.” There are products that need to be designed with sensitivity, respect, and to alleviate the emotional burden of the customer.

Another group is products sold to businesses, like commercial real estate, printers, furniture, laptops, office equipment. These are made for organizations rather than the general public, so the marketing, sales, pricing, and purchasing decisions are different. An individual may decide on a personal laptop within a day, while a company buying 500 laptops might need an approval process, warranty, security, technical support, and long-term contracts.

Then there are industrial products, which are goods or services serving specific industries. I imagine these as machinery for factories, production management software, line maintenance services, or specialized materials. For this group, a Product Manager needs to understand the industry context, technical standards, operational risks, and the cost of disruption if a product fails.

What I conclude is: even though they are all “products,” the questions to ask can differ based on who the user is and in what circumstances they are purchasing. As a beginner, I could practice by picking a familiar product and asking myself: is it for individuals or businesses, bought frequently or rarely, emotional or primarily effective, who is the user and who pays for it?

3. Services, IT products, internal products: some things aren’t on shelves but still need Product Management

I used to easily visualize a Product Manager working with apps, websites, or consumer goods rather than services. But the lesson emphasizes that services are also products, only differing in being intangible and more action-related rather than a specific good. Carpet cleaning, lawn care, construction, SaaS software are all examples. Both individual consumers and businesses can use services.

For example, a carpet cleaning service is not just “cleaning the carpet.” Customers will care about how easy it is to schedule, punctuality of the employees, safety of chemicals used, how fast the carpet dries, pricing transparency, and how the company deals with dissatisfaction. The same goes for SaaS: a task management software is not just a list of features, but also onboarding, page loading speed, security, customer support, documentation, and how it integrates with other tools.

In IT, products like cloud infrastructure and software can be provided as services. This makes the boundary between “product” and “service” more flexible. A physical server might be considered a good, but cloud infrastructure is a continuous service, where customers expect stability, scalability, security, and pay-per-use.

The lesson also distinguishes between external and internal products. Products aimed at external consumers or businesses are called external products, as they serve customers outside of the organization. But there are also internal products, created to serve the organization itself. Examples include business intelligence, HRIS, CRM, ERP, and internal tools.

I find the internal product section noteworthy because it’s easily overlooked. A lousy internal tool might not immediately lose customers, but it costs employees time, induces data entry errors, complicates coordination, and affects overall business efficiency. For instance, if an internal CRM system is too complex, the sales team might forget to follow up customers; if the HRIS is cumbersome, employees may be hesitant to update information or request leave through incorrect procedures.

A light objection might be: “Do internal products need serious Product Management? After all, the users are company employees, they have to use it.” I understand that thought, but the more I learn, the more I see how dangerous it is. Compulsory use does not mean the product is creating good value. If internal users must use a lousy tool, the costs will translate to wasted time, operational errors, and accumulated frustration.

A practical piece of advice: when looking at a service or internal tool, try sketching a simple “user journey” consisting of before-use, during-use, and after-use. Just these three columns can show us that a product is not just a screen or process but a continuous experience.

4. Waterfall, Agile, and Hybrid: choosing a development method should not follow trends

The next section of the lesson discusses project management frameworks used for product development: traditional Waterfall, Agile, and Hybrid models. What I like here is the lesson doesn’t say Agile is always better than Waterfall. Instead, a Product Manager should understand both, as each model is suitable for different contexts.

Waterfall is appropriate when requirements have been clearly defined, with few expected changes during the development process, and a detailed sequential plan is needed. You can imagine it as building a small bridge that already has a clear design: if you keep changing the design midway, costs and risks will spike. The lesson provided examples like pharmaceutical drugs, printed magazines, and consumer electronics. With pharmaceuticals, the testing, verification, regulatory and safety processes are extremely strict; “trying and fixing continuously” cannot happen as randomly as with a small app.

Agile is more suitable when there is not enough initial clarity or consensus about what a product should feature, how it should function. Agile breaks development into smaller parts, allowing learning and adjustments during work. For example, if a team is developing a note-taking app for language learners, they might not know if users need flashcards, pronunciation recording, study reminders, or an exchange community. Following Agile helps the team try each part, gather feedback, and then adjust instead of trying to predict everything upfront.

The lesson also mentions Stacey Matrix, a model developed by Ralph Stacey, often used by product development teams to contemplate appropriate project management lifecycle. The core involves looking at two elements: the level of consensus on product features/functions, and the technical complexity involved in development. If everyone is highly aligned and technical aspects clear, a sequential method like Waterfall can be reasonable. If there is much uncertainty in both demand and implementation, Agile could be more helpful.

Many industries are increasingly applying Agile, including software, pharmaceuticals, finance, and distribution companies like Amazon. However, I think beginners should be cautious with the phrase “every industry is Agile now.” Agile isn’t a magic wand. If a team claims to be Agile but doesn’t genuinely listen to feedback, doesn’t split work appropriately, doesn’t have decision-making authority, or simply turns sprints into shorter deadlines, then Agile is just a label.

Hybrid emerges when a product has parts fitting Waterfall and parts needing Agile or Scrum. For example, a medical device might have hardware parts requiring strict verification processes, while the user interface software could need testing with doctors and gradual adjustments. In such cases, the Product Manager and Product Owner need tight coordination to synchronize development efforts, avoiding situations where one part follows a fixed plan while another changes constantly with no connection.

The advice I find easy to apply is: don’t ask “should we use Waterfall or Agile?” first; ask “how clear are the requirements, how complex is the technology, are changes during development acceptable?” The answers will lead us to a more suitable framework.

5. What I’m relearning: A Product Manager doesn’t just manage the product but manages the alignment between value, method, and context

After piecing the parts together, I see that Product Management is not a fixed list of tasks. If a product is an experience, if customers may be individuals, businesses, industries, or even internal employees, if development methods can be Waterfall, Agile, or Hybrid, then a Product Manager needs to continually place products in their correct context.

For consumer products, a Product Manager might need to focus on daily needs, emotion, brand, and access channels. For business products, understanding buyers, users, approvers, and operators as possibly different groups is crucial. For services, experiences often lie in service and process. For cloud IT products or SaaS, value comes from stability, scalability, security, and continuous improvement. For internal products, success might mean less operation time, fewer errors, and helping employees work better.

This also makes me view the role of a Product Manager more humbly. A PM isn’t someone who “knows all” or always has the right answers. Perhaps a PM is more like someone who continually clarifies: who the customer is, what problem is worth solving, what type of product it is, whether requirements are clear, what technical risks are involved, which framework to develop in, and how the post-launch experience should continue.

I think Business Acumen is the skill that helps Product Managers avoid getting stuck in “building features”

Dai Nguyen — Wed, 22 Jul 2026 17:03:37 +0000

I think Business Acumen is the skill that helps Product Managers avoid getting stuck in “building features”

There is a situation I find very common when first learning about Product Management: a group discussing products, engineers talking about API and performance, designers discussing user experience, sales mentioning a customer demanding a feature urgently, while the leaders ask: “How does this feature contribute to the business goals this quarter?” If they only hear the part “what the customer wants” and don’t understand “what the business needs”, a Product Manager can easily become someone who just documents requirements and forwards them to the tech team.

After learning from the sharing of Product Managers and experts in videos, I've realized that business acumen is not about talking finance in a “cool” way. For me, business acumen is the ability to connect three things: customer needs, product capabilities, and business outcomes. A PM with business mindset needs to understand how the company makes money, what really pains the customers, how the market is shifting, and why one task should be prioritized over another.

This is especially important for those exploring AI PM or Product Management in general. Because products, especially technology and AI products, can easily get caught up in flashy demos, new models, or smart features. But eventually, the product must still answer: who uses it, for what purpose, is it worth paying for, and does it help the business stay on track?

1. Understand the business before talking about the roadmap

The first point I deduced is that Product Managers need to understand the business's needs and know which work should be prioritized to serve those needs. It sounds obvious, but in reality, it’s not simple. In a company, each department might speak in a different “language”: leadership talks about strategy, finance about costs and profit, marketing about positioning and segmentation, sales about revenue, while engineering speaks of architecture and stability.

A PM with business acumen doesn’t have to be an expert in all these fields but needs to understand enough not to get lost in meetings. More importantly, PM should know how to translate business language into product decisions. For instance, if the leadership says the company wants to increase enterprise customer retention, a PM shouldn’t just note down “need to increase retention.” The task is to ask questions: at what stage do customers leave, due to lack of features, difficult onboarding, or unclear product value? From there, prioritize actions like improving usage reports, adding automatic alerts, optimizing the onboarding flow, or supporting better integration.

The video mentioned SMART: specific, measurable, achievable, relevant, timely. I find the word “relevant” very noteworthy. A feature may be cool, doable, even liked by users, but if it’s not related to the mission, vision, and current goals of the organization, it might not be worth doing immediately. An imaginary example: if a language learning app is focused on increasing the number of paid learners, adding fun 3D avatars might be interesting but not as “relevant” as improving the initial competency test or personalizing the learning path.

PMs also need to understand the organization's strategic portfolio or the set of key initiatives to be achieved. Without understanding the portfolio, PMs can easily optimize locally for their product and deviate from the bigger picture. Practical advice for newcomers like me is: when reading a roadmap, don’t just ask “what features are coming?”, also ask “what are the business goals behind each feature group?” and “which strategic initiative of the company does it align with?”

2. Customers are not just “users,” but part of a specific business context

One idea I really liked in the sharing was that Product Managers should have experience or at least the mindset to work directly with customers. Not to cater to every request, but to understand the environment in which customers operate. Customer needs do not just exist in an empty ticket; they are influenced by industry, processes, regulations, culture, internal policies, and even geography.

An example in the video is very clear: working with a government agency is drastically different from working with a small business in your city, and also from a financial institution. For government agencies, the procurement process can be lengthy, with strict security and compliance requirements, and need comprehensive documentation. For SMBs, they might need quick deployment, understandable pricing, and less complex configurations. For financial companies, reliability, audit logs, access control, and compliance could be critical factors. The same “export report” feature could mean entirely different business implications for different customer groups.

Here, empathy is a core skill. But empathy is not just “caring for the customer” or “listening politely”. As I understand it, empathy in Product Management is the ability to delve into the customer’s operating logic: why they operate in a certain way, why they are constrained, why they ask for a certain feature, and what the business consequences are without that feature. The question “why” becomes a powerful tool.

An imaginary example: a customer requests a “download all data to Excel” button. If the PM only listens superficially, the team may rush to create an export function. However, asking “why do you need to export to Excel?” might reveal they need to reconcile numbers between two systems at the end of the month. In that case, a better solution could be direct integration, reconciliation dashboards, or data discrepancy alerts, not just an export button.

However, a mild counterpoint to keep in mind: it’s not that whatever customers say should be done. Customers often describe solutions they think of, but the PM needs to find the real problem. Newcomers can practice by, after each case study reading or hypothetical interview, writing down three lines: what the customer said they want, what the root issue might be, and what the business impact would be if resolved.

3. Business acumen demands recognizing market, value, and monetization

A PM needs to understand not just the functional and non-functional requirements of a product. Functional requirements are what the product can do, like login, search, report creation. Non-functional requirements are how well the product performs, like security, performance, scalability, reliability. But stopping there means the PM only understands “what to build” and not necessarily “why this is worth building in the current market.”

Therefore, PMs must recognize competitive context and market trends. If competitors are shifting to a self-service model, if customers increasingly expect AI integration, if the market is more sensitive to data privacy, then the roadmap cannot remain static. Competitive analysis is not about copying competitors, but understanding what choices customers have and where your product differentiates.

There is a concept here called product instinct. I understand it as a relatively sharp sense of what has value to customers, what attracts them, and what they are willing to pay for. But this “instinct” shouldn’t be mythologized. For beginners, product instinct can be honed by observing real products: why I pay for this app but not that one, why a feature keeps me coming back daily, why a pricing package makes sense to me.

A very practical part of business acumen is understanding pricing and licensing. In technology, on-premise and SaaS models have different pricing logic. On-premise often involves setups at the customer's infrastructure, licensing, maintenance, deployment, long-term support. SaaS typically charges by subscription, user count, usage levels, feature packages, or data scale. If a PM doesn’t understand pricing, it’s easy to design a cost-heavy feature with no way to recover its value.

An imagined example: an AI product adds a feature for automatic document analysis. If each analysis run incurs high model cost, PMs need to think about usage limits, premium packages, or ways to optimize processing costs. If not, the more users, the more the company loses. This is where business acumen links with technical acumen: understanding the technology enough to know operating costs, understanding business enough to know how to package value.

Strategic planning is also an important skill. PMs need to know how to create short-term and long-term roadmaps: what issue to solve this quarter, what capability to expand in the next six months, what position the product aims to occupy in the market a year from now. Simple advice for beginners is when looking at a feature, try placing it into three time frames: what is the immediate impact, what does it pave way for next, and if not done, what future risks loom?

4. Data, finance, and stakeholders: the “tricky” part but unavoidable

One point that somewhat surprised me was that business acumen is not just about market intuition or customer talks. PMs need to know how to read data, interpret reports, and understand basic financial metrics. Data can come from user research, including qualitative like interviews, observations, open feedback; or quantitative like conversion rate, retention, churn, usage time, feature activation count. There are also business KPIs, financial reports, and other internal documents.

The key is not to turn PMs into data scientists or accountants. I believe the needed skill is knowing what the data suggests and asking the right questions. For example, if a dashboard shows many signups but low returns after the first week, a PM should ask: do they not see the value, is onboarding too long, is the main feature hard to find, or are marketing expectations misaligned? If financial reports show rising support costs, a PM should ask: is the product too hard to use, is documentation lacking, or do new customer segments need different support?

PMs also need to communicate with senior management, executives, and VPs. This isn’t about “talking fancy”, but the ability to present product decisions in business language. With the tech team, PMs can talk about requirements, trade-offs, backlog. With leaders, PMs need to clearly convey impacts on revenue, growth, customer retention, costs, risks, and strategic priorities. Then, PMs must translate those business expectations back into technical requirements, prioritization criteria, and specific tasks for the product team.

Stakeholders are also a crucial part. A point emphasized in the video is that PMs need to understand which stakeholders will collaborate to turn product ideas into success. Stakeholders could be sales, marketing, customer success, legal, finance, engineering, design, data, support, or leadership. If PMs don’t know who influences, who provides information, who implements, who bears risk, a product can fail not because of a bad idea, but due to poor coordination.

Finance is perhaps the aspect most newcomers, including myself, are most hesitant about. But concepts like internal rate of return, net present value, return on investment, and payback aren’t just for making financial reports look good. They help PMs evaluate whether a product investment is worthwhile, how quickly it recoups costs, and whether future benefits are significant enough compared to current costs. An imagined example: if an automation feature helps reduce 500 support hours monthly, a PM should know how to estimate development costs, operating costs, savings, payback period, and impact on customer experience.

The counter-argument here is: “Does a PM need to be so proficient in finance as to calculate everything?” I think not. A PM doesn’t need to replace the finance team. But a PM should understand enough to participate in discussions, know when to ask experts, and not make product decisions entirely based on intuition. A practical way to learn is to pick a familiar product, try writing a simple hypothesis: where does the company make money from, what are the main costs, which metrics demonstrate the product’s health, and which new features could improve those metrics.

5. For AI PMs, business acumen helps avoid “fascinating technology but forgetting value”

Applying these concepts to AI PM, I find business acumen even more crucial. AI can easily create an impressive vibe: smooth chatbot responses, fast classification models, and smart-sounding suggestions. But a PM with a business mindset will ask further: which business problem does this AI feature solve, do customers trust the results, what are the consequences of mistakes, is the inference cost sustainable, is the data secure enough, and are customers willing to pay for that level of value?

An imagined example: a recruitment platform wants to add AI for scoring CVs. Technically, it can be built. But business acumen forces a PM to look wider: does the recruiter need to save time or improve candidate quality? Are candidates being evaluated unfairly? Is there a competitor doing this better in the market? In which price package should this feature belong? Are KPIs the number of CVs processed, reduced hiring time, or increased correct hire rate? By merely saying “add AI scoring”, the product might shine during a demo but flounder during real deployment.

I believe the maturity of a PM is not in always having immediate answers. It lies in asking the right questions amidst many pressures: customers want it fast, sales want deals closed, engineering wants a clean solution, leadership wants growth, finance wants cost control. Business acumen helps PMs avoid being completely swayed to one side.

If you're also self-learning like me, you can start very small. When reading an article about a product, ask yourself: what segment does this product serve, why do customers pay for its value, how can the company measure success with metrics, who are the replacement competitors, and if I were the PM, what would I prioritize next quarter? Doing this exercise regularly, I believe the ability to “think like a PM” will become much clearer than merely learning framework names.

Conclusion: A good PM doesn’t just ask “what to do”, but “why it’s worth doing”

What I realized after this learning part is that business acumen is not an auxiliary skill but an integral layer of Product Management. It’s the mindset that helps PMs connect disparate elements: company strategy, mission, and vision.

Why I Think Business Acumen Is the Product Manager’s “Translation Skill”

Dai Nguyen — Tue, 21 Jul 2026 17:15:12 +0000

Why I Think Business Acumen Is the Product Manager’s “Translation Skill”

I used to think product management was mostly about understanding users, writing requirements, and keeping a roadmap organized. Then I studied business acumen in the product manager role, and the picture became much bigger. A product manager is not just asking, “What should we build?” They are also asking, “Why should this exist for the business, why would customers care, and how do we help teams move in the same direction?”

The definition that stayed with me is simple: business acumen is the ability to understand and manage business situations in a way that creates a positive outcome for the organization. For a product manager, that means connecting customer needs, market reality, financial logic, technical constraints, and company strategy into decisions that make sense.

My current opinion is this: business acumen is the product manager’s translation skill. It helps translate executive goals into product direction, customer pain into product concepts, financial metrics into priorities, and technical work into business value. If you are new to product management, especially AI product management, this matters because it prevents you from seeing the product only as a feature list. A product exists inside a business system, and business acumen helps you understand that system without losing empathy for users or respect for builders.

1. Analytical Thinking: Learning to See the Product from Multiple Angles

One part of business acumen that feels very practical to me is analytical capability. A product manager uses data-driven decision-making to understand problems from different angles, not just from personal opinion or the loudest stakeholder in the room.

For example, imagine a language-learning app where many users sign up but stop using it after three days. A beginner might immediately suggest adding more lessons or redesigning the homepage. But a more analytical product manager would first ask: Where exactly do users drop off? Is it after onboarding? After the first quiz? After seeing the subscription screen? This is where spreadsheets, business intelligence tools, dashboards, and sometimes basic programming knowledge can help.

I like the idea that a product manager does not need to be the deepest engineer in the room, but does need a moderate level of technical understanding. That technical awareness helps them ask better questions, understand trade-offs, and create instructions that technical team members can actually use. For instance, if a PM knows the basics of how event tracking works, they can better request data such as “lesson_started,” “quiz_completed,” or “subscription_prompt_seen” instead of vaguely asking, “Can we track engagement?”

Analytical work also helps connect the dots between user behavior and wider business questions. The same data that shows how users interact with the product can also reveal market trends, support competitive analysis, and improve forecasting. If a competitor launches a cheaper plan and your conversion rate drops, that is not just a UX issue. It may be a pricing, positioning, or market perception issue.

My advice for someone new is to practice asking three layers of questions when looking at product data:

What is happening?
Why might it be happening?
What business decision could this inform?

A gentle counterpoint is worth mentioning: data should not become a shield against judgment. Not every important signal appears neatly in a dashboard. A frustrated customer interview, a sales team’s repeated objection, or a support ticket pattern can reveal something numbers alone may miss. So I see analytical capability not as “let the spreadsheet decide,” but as using evidence to make better human decisions.

2. Financial Literacy: Understanding Whether the Product Makes Business Sense

Financial literacy can sound intimidating if, like me, you did not originally approach product management from a finance-first mindset. But the core idea is not that every PM must become a CFO. It is that a product manager should understand how a product contributes to the company’s health.

The lesson introduced several common financial metrics: cash flow, profit, return on investment, internal rate of return, net present value, and payback. At first, these terms can feel abstract. I found it easier to think of them through a simple everyday analogy.

Suppose you want to buy a coffee machine for a small office. The machine costs money upfront. You then compare that cost with the savings from not buying coffee outside every day. You might ask: How long until the machine “pays back” its cost? Is the saving worth the initial investment? Does it improve the team’s daily experience enough to justify the expense? That is a simple version of thinking about payback, return, and value over time.

In product management, the same logic applies at a bigger scale. If a team wants to build a new AI-powered recommendation feature, the PM should understand the expected business impact. Will it increase retention? Will it improve conversion? Will it reduce support costs? Will it create a premium feature customers are willing to pay for? The product may be technically impressive, but business acumen asks whether it helps generate cash flow, profit, or strategic advantage.

The input also emphasized that financial metrics help explain how a product makes the company unique and profitable. That point matters because not every profitable product is unique, and not every unique product is profitable. A product manager has to live in the tension between differentiation and sustainability.

For beginners, I would suggest learning the basic meaning of these terms without getting lost in complex formulas at first:

Cash flow: Is money coming in and going out in a healthy way?
Profit: After costs, is the product actually making money?
ROI: Was the investment worth the return?
IRR: How attractive is the return rate of an investment over time?
NPV: What is the value today of future benefits, after considering time and cost?
Payback: How long until the investment recovers its cost?

Even a simple habit helps: when you hear a feature idea, ask, “What business outcome would justify building this?” That question can change the conversation from “this sounds cool” to “this creates measurable value.”

3. Marketing Savvy: Knowing Who the Product Is For and Why They Should Care

The marketing side of product management was another reminder that a product does not succeed just because it exists. It needs to be understood, positioned, and valued by the right audience. The product manager’s responsibilities often intersect with sales, especially when the question becomes: Are we serving current customers, future customers, or both?

For example, imagine a company building project management software. Current users may want better reporting because they already manage complex workflows inside the tool. Future customers, however, may care more about easy onboarding because they have not yet committed to switching from a competitor. If the PM only listens to current users, the product might become powerful but hard to adopt. If the PM only chases future users, loyal customers may feel neglected.

This is where market research becomes essential. A product manager studies customer needs, competitor behavior, pricing expectations, buying triggers, and market gaps. But the best part of the lesson for me was the idea of creating value from both the firm’s point of view and the customer’s point of view.

A customer might value convenience, trust, speed, or lower risk. A company might value revenue growth, retention, market share, or operational efficiency. A strong product concept should ideally satisfy both. For example, a self-service onboarding flow may help customers start faster while also reducing the company’s support burden. That is value on both sides.

Marketing savvy also helps explain how the business can position the product to delight customers. “Delight” does not always mean adding flashy features. Sometimes delight is clarity. A simple pricing page can delight a confused buyer. A reliable export button can delight an operations manager. A well-timed notification can delight someone who nearly forgot an important task.

My practical advice: if you are learning product management, pick a product you use often and write down three things:

Who is the current target customer?
Who might be the future target customer?
What promise is the product making to them?

This exercise trains you to see beyond the interface and notice the business story behind the product.

4. Strategic Planning and Adaptability: Roadmaps Meet Reality

The part about strategy made me think about how easy it is to romanticize roadmaps. A roadmap can look clean in a slide deck: Q1 discovery, Q2 build, Q3 launch, Q4 scale. But business reality rarely respects that neat structure.

A product manager uses business acumen to understand how the product aligns with the company’s overall strategy. If the company’s strategy is to move upmarket, the product roadmap may need stronger admin controls, security features, and enterprise integrations. If the company’s strategy is international expansion, the roadmap may need localization, compliance work, and region-specific payment methods.

The lesson also mentioned designing a program to facilitate this alignment. I interpret that as creating the operating rhythm that keeps product work calibrated with business goals: roadmap reviews, stakeholder updates, prioritization criteria, success metrics, and cross-functional planning.

But strategic planning is only half of the story. The other half is adaptability. Product managers may need to adjust a carefully designed roadmap because of revised budgets, reprioritized company assets, supply chain deficiencies, new government regulations, domestic or international compliance changes, or many other unexpected factors.

A simple analogy is planning a road trip. You may choose the route, estimate fuel costs, book hotels, and decide where to stop. But if a storm closes a road, a hotel cancels, or fuel prices spike, the plan has to change. The goal is not to worship the original route. The goal is to arrive safely and intelligently.

In product work, resiliency helps carry the product lifecycle from inception to completion. That lifecycle includes early idea formation, validation, development, launch, management, and sometimes retirement. A resilient PM does not panic when the roadmap changes. They help the team understand what changed, why it changed, and what decision comes next.

For someone new, I think a useful habit is to separate strategy, roadmap, and tasks:

Strategy explains why the direction matters.
Roadmap explains what major outcomes or bets come next.
Tasks explain the work needed to move forward.

When reality changes, tasks may change often, roadmaps may change sometimes, but strategy should only change when the underlying business context truly shifts.

5. Leadership and Communication: Moving Upward and Downward with Trust

The lesson connected leadership directly with business acumen, and that connection makes sense to me. A product manager often has responsibility without full formal authority. That means influence matters. Leadership is not just giving instructions; it is creating clarity, trust, and momentum.

The traits listed were strategic thinking, resilience, trustworthiness, empowerment, accountability, and capable communication. What I found especially useful was the idea that a PM works both upward and downward in the organizational chain.

Working upward toward executives, the product manager acts as an evangelist for the product vision. That does not mean exaggerating or overselling. It means clearly explaining why the product direction matters, how it supports business strategy, and what cross-functional teams need to execute. A PM also gives justified praise to the people involved in creating, deploying, and managing the product. I like the word “justified” here because praise should be specific and earned, not performative.

Working downstream, the PM translates executive strategy into solutions that respect the cadence of multiple teams. Engineering, design, marketing, sales, customer support, legal, and operations do not all work in the same way or at the same speed. A PM with business acumen does not simply pass pressure downward. They translate, sequence, clarify, and protect focus where possible.

This is where accountability, trustworthiness, and resiliency become practical. Over time, a PM who communicates honestly and follows through can earn a reputation that helps clear bureaucratic roadblocks for implementation teams. For example, if a team needs a decision from legal before launch, a trusted PM may be able to escalate clearly, explain the business impact, and help unblock the work.

Communication itself is a major component of business acumen. It appears in presentations, updates, meetings, stakeholder management, informal conversations, customer communications, written correspondence, and daily team discussions. The lesson highlighted empathy, simplicity, quality, and engagement as important communication qualities.

I think those four words are worth slowing down for:

Empathy means understanding what the other person cares about.
Simplicity means removing unnecessary complexity.
Quality means being accurate, thoughtful, and prepared.
Engagement means making communication useful enough that people want to pay attention.

A practical example: if an executive asks for a product update, they may not need every technical detail. They may need risks, decisions, metrics, and business impact. If an engineer asks for clarification, they may need acceptance criteria, edge cases, and priority. If a customer asks what changed, they may need benefits in plain language. Same product, different audience, different communication.

My advice for beginners is to practice rewriting the same product idea for three audiences: an executive, an engineer, and a customer. This exercise quickly reveals whether you truly understand the idea or are only repeating product vocabulary.

Conclusion: Business Acumen Makes Product Thinking More Complete

After studying this topic, I no longer see business acumen as a vague corporate phrase. I see it as a practical set of skills that helps a product manager make better decisions: analytical capability to understand what is happening, financial literacy to judge whether work makes business sense, marketing savvy to connect with customers and markets, strategic planning to align with company direction, adaptability to handle real-world changes, leadership to create trust, and communication to move ideas across the organization.

What encourages me is that business acumen is learnable. You can start small: read a dashboard more carefully, learn one financial metric, compare two competitors, ask how a feature supports strategy, or practice explaining one product decision to different audiences.

If you are also learning product management, I would love to know: which part of business acumen feels most challenging to you right now: finance, strategy, communication, data, or market thinking? Try picking one area this week and applying it to a product you already use.

A recent AI PM update I found relevant: according to Computer.org, AI/ML product managers increasingly need skills such as strategic thinking, customer focus, communication, leadership, collaboration, data-driven decision-making, technical understanding, ownership, adaptability, and business acumen; Institute of Product Management similarly emphasizes connecting technical capabilities to business outcomes, identifying high-impact opportunities, and making decisions under uncertainty; and Grauntx AI notes that the AI product manager role is expanding, which makes this kind of business acumen even more relevant for people exploring AI PM today.

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

Dai Nguyen — Mon, 20 Jul 2026 11:05:05 +0000

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.

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?"