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.
Top comments (0)