I often hear from people who have been in product roles for six months, a year, sometimes even longer, and still feel they have not gained much. Some say nobody is mentoring them. Some say there are too few opportunities. Some simply ask what they should do next.
My first reaction is usually a helpless smile, followed by one unsentimental thought: you probably earned this confusion.
That is not a matter of arrogance. The real problem is that many people claim they are learning, but they do not treat learning seriously. Good methods have been discussed again and again: how to learn, how to practice, how to move from zero to one as a junior product manager. Yet plenty of people who have already worked for a year are still stuck at the question of how to begin.
Learning product management is not something you can do casually. You have to take notes, connect scattered ideas, and turn fragmented reading into a usable system of practice. After half a year in a product role, I was already able to produce a full series on writing product requirements documents. At the time, there were almost no practical PRD case studies available online. That series summarized a working method from real practice, and some companies even applied it internally as part of their product process. It was also copied by someone named Liu Wenzhi into training material.
The point is not that I had some special talent. The point is much simpler: I loved products, I loved tinkering with things, and I had curiosity.
These three things sound ordinary, but they decide whether a product manager grows slowly, gives up halfway, or enters a period of rough, fast, almost wild growth.
Loving the product itself
A product role is an unusually proactive job. You have to learn proactively, build industry knowledge proactively, think about innovation proactively, and push execution proactively. Almost nothing happens by itself.
If you do not have real interest in the work, and only choose the role because it seems like a stable way to make a living, product management will be exhausting. It is not a job where you can wait for someone else to arrange every step and then expect to grow quickly.
Real interest leaks into everyday life. It changes how you look at software, services, technology, users, markets, and even ordinary experiences outside work. Some people may see that as childish enthusiasm. But if that enthusiasm lasts for years, it becomes an advantage.
Loving the act of tinkering
There is a well-known passage from Outliers: people we call geniuses do not become extraordinary because they are born far above everyone else, but because they put in sustained effort. Ten thousand hours of practice is often described as the necessary path from ordinary to exceptional.
The “10,000-hour rule” is not magic, but it does point to a basic truth: growth requires a large amount of real practice.
During my own growth period, work and study took at least twelve hours a day, and this continued for five or six years. During the first year of an iHerb-related project, sleep was limited to about six hours a day; apart from eating, nearly all remaining time went into the project. Only in later years, after many things became familiar and efficiency improved, did more free time appear.
If you count only eight working hours a day as practice, reaching ten thousand hours takes three or four years. But even during work hours, there are meetings, interruptions, miscellaneous tasks, and plenty of wandering attention. Whether a person really gets eight solid hours of useful practice each day is questionable.
Reading industry news after work or browsing other people’s articles does not count as real tinkering. That is input. Input alone is almost useless. Knowledge that you can output is what becomes your experience, and tinkering is one of the best ways to create output.
If you cannot enter a professional state quickly during your learning period, a one- or two-year adjustment phase may already be enough to make you quit. Without love for the work, and without the willingness to make trouble for yourself, there is little reason to choose product management.
Curiosity is harder to fake
Love can be misleading. Just as when we like a person, many external factors can distort our judgment. Curiosity is more fundamental. It is an instinctive psychological tendency, an internal motive for learning, a force that drives a person to seek knowledge, and an important trait of creative people.
A product manager who is genuinely curious does not want to miss important information. When seeing an interesting product or technology, curiosity should push you to ask: what environment does it operate in, what principle makes it work, what business model supports it, who uses it, and why?
When you encounter an unfamiliar term or field, curiosity should make you investigate its real meaning, market environment, competitors, and industry chain.
When you read an industry article or a knowledge-sharing piece, curiosity should make you examine its background, related opinions, structure of argument, and whether it contains independent thinking.
If none of these questions arise, and there is no urge to understand something thoroughly, it is hard to talk about product creation or innovation. Feeling that something is new is not curiosity. Passively learning because someone tells you to is not curiosity either. That kind of “interest” only becomes more tiring over time.
There is also a kind of person who never researches anything independently but asks questions about everything. It can look like strong eagerness to learn, but often it is just dependence. For example, if several open-source programs are listed for people to study, and someone immediately asks for the official websites and download links instead of searching the names, that is not serious learning. If a person is too lazy even to find the official site, it is hard to believe they will later install the program, configure the environment, and study how it works.
Effort needs a method
None of these ideas are new. Ancient sayings about hard study, school slogans about daily progress, and modern discussions of the 10,000-hour rule all point toward the same thing: spend time struggling with yourself, sometimes almost cruelly.
But in a complex modern environment, effort alone is not enough. We need effort with a method. In other words, deliberate practice.
Psychologist K. Anders Ericsson’s research emphasized that the key factor separating excellent performance from average performance is neither raw talent nor ordinary experience, but the degree of deliberate practice.
For product managers, deliberate practice can be discussed through three functional stages: functional product manager, operational product manager, and managerial product manager.
1. The functional product manager
A functional product manager mainly designs functions. This is usually the stage for beginners or people not long after entry. Product assistants and product specialists also fall into this type.
At this stage, a product manager generally needs to master two things: the common tools used in product work, and the user roles and functional structures behind common product patterns. If you understand these two areas well, you can usually handle the work of a functional product manager.
1.1 Know common product patterns
There are many product-pattern terms, and new ones keep appearing. Common examples include BBS, CMS, Blog, SNS, C2C, B2C, B2B, and B2B2C. In more recent years, terms such as P2P, ranking-list models, and Magic-style models have appeared. You should also understand technical model terms such as IaaS, PaaS, SaaS, Usenet, IRC, and Mailing List.
The purpose of learning these patterns is not to memorize terminology. It is to understand what permission roles and functional structures exist inside different product architectures, what products represent these patterns, and how their business models and operations work.
You should even look for open-source programs that represent these patterns, install them, play with them, and spend time understanding their product logic.
Technology is built on inheritance. The lack of product-level innovation in parts of the Chinese internet industry is related to the fact that many people lack an understanding of earlier network products. Some excellent modern products inherited useful ideas from old ones. Slack, for instance, absorbed strengths from IRC; WeChat public accounts inherited some technical logic from mailing lists.
Understanding history is basic training for a product manager. If you want to build an O2O product, at the very least you should know the B2C pattern well, and ideally understand the broader set of e-commerce patterns too.
1.2 Understand product architecture design
Product planning and product design are essentially architecture planning and architecture design. This is especially important for functional product managers.
To understand product architecture, you need to understand the formula:
algorithm + data structure = program
You can also use prototypes to understand architecture. Prototype practice can help you reconstruct product logic in three steps.
The first step is imitation. Choose several products you know well, preferably small and elegant ones rather than huge products with many functions. Draw their prototypes by copying them. Through imitation, you restore the product structure and page elements, and break down the system layer, data layer, business layer, framework layer, and presentation layer. In many fields, becoming skilled begins with copying strong works, whether famous paintings or model essays. Websites, apps, and internet products are no different. If you can fully reproduce a product and think through its choices in color, copywriting, and process, your own growth will accelerate.
The second step is reconstruction. Find several products that frustrate you as a user. Rebuild them and draw new prototypes. Add your own thinking, remove unnecessary parts, and explore possible highlights. At this stage, you are no longer merely restoring the original logic. You are outputting a product. Your knowledge begins to settle into experience.
The third step is creation. Find a real need from work or life that you believe has value, then satisfy that need through an internet product and draw your own prototype. At this stage, it is better to use an MVP approach for the first version. This is a practical way to test whether you can output product value.
2. The operational product manager
An operational product manager must think globally about the product. This role is responsible for overall planning and design, can independently complete a series of product-planning tasks, and must also consider future operations and expansion.
This means the role is not limited to product implementation. It also involves market and operations thinking. Product and operations cannot really be separated: product determines the breadth of operations, while operations determine the depth of the product.
Operations represent market and business ability. This is where the product manager’s soft power appears. Many job descriptions do not clearly state this requirement, but interviews will test it by discussing industries, domains, and competitors.
A functional product manager demonstrates hard skills such as product architecture and user experience. These can be deliberately practiced in a relatively short period. Soft skills, however, must be earned through real tinkering.
2.1 Build experience by running your own experiments
The era of personal webmasters was a time of wild growth across the internet. It is worth studying because it shows how much people can learn by building and operating things themselves.
Whether you work in a large company or a small one, a product manager has to keep experimenting independently in order to accumulate experience. One practical method is to set aside a fixed amount of salary each month as a project fund. For example, save 1,000 yuan a month for after-hours projects. When you have an idea, use that fund to operate the project. If it fails, treat the money as tuition; you learned from it. If it gains traction, invest more. If it succeeds, it may even bring a return.
When you personally lead a small project, you practice a full range of knowledge: product, design, technology, operations, and more. You also accumulate hidden experience, such as how to choose outsourcing services, how to understand a specific field, and how to judge a market environment.
A product manager who has never independently controlled and operated a project from beginning to end cannot really claim to understand business, let alone claim professional competence. Without that experience, it is hard to call oneself a qualified product manager.
The knowledge accumulated at the functional stage becomes crucial here, especially familiarity with product patterns and open-source programs. One of the most important aspects of product thinking is meeting a need at the lowest possible cost.
Why do people with more experience often earn higher salaries? Because rich experience can greatly reduce costs—not only the cost of implementing a requirement, but also the user’s cost of using the product.
Suppose you need to build a pregnancy reminder app for a mother-and-baby product. At the early stage, you could first use WeChat to create a functional service account, accumulate users, and later expand into an independent app. This reduces both implementation cost and user cost, while also using WeChat’s existing user base to spread and acquire users quickly. But that is only a strategic product plan, not the deepest form of product thinking.
True product thinking asks how to meet this WeChat public-account requirement at the lowest cost.
A conventional approach might be to develop a CMS with push functions. The product information structure would be a timeline feed, pushing pregnancy reminder content according to the user’s stage. But an experienced product manager would not necessarily do that, because there are many ways to satisfy a requirement, and the lowest-cost method is often the most competitive.
The lowest-cost method could be this: pregnancy has 40 weeks, so create 40 mobile-friendly topic pages. According to the user’s stage, push a graphic-message link to the corresponding topic page. This not only improves the flexibility of content, but also allows the same content to be shared on PC. Technically, only a customized function for pushing graphic-message links is needed. No CMS needs to be developed, so the implementation cost is clearly lower.
Because a personal project fund is limited, product implementation must force you to think about low-cost solutions. Use the open-source programs and template-engine knowledge you have accumulated. Compare your needs with existing programs, reduce development tasks as much as possible, and lower spending.
A concrete example: I once experimented with an overseas-shopping price-comparison product. Based on the product requirements, I eventually used ECShop as the main program and LocoySpider as the price collector. For implementation, I outsourced customization and improvement of ECShop’s product structure for 2,000 yuan, so that the product information of a B2C store could support multiple prices, with fields such as store name, link, and price under each price attribute. Front-end design and coding cost 1,000 yuan. Rules and scheduled tasks for price collection cost 500 yuan. The total was 3,500 yuan, and with that I built a price-comparison product.
During later operation, I practiced operational knowledge, iterated several versions based on user feedback, and built additional functions such as order-combination and ranking lists based on the same dataset. Those later requirements no longer needed the project fund because the price-comparison program itself had begun producing monthly revenue, even exceeding my salary at the time. But it remained a side project, not a startup; priorities must be distinguished clearly.
Persistent tinkering can accelerate professional growth enormously. It gives you room to apply and practice the knowledge of an operational product manager. In earlier years, many experiments may produce no visible result, but they still accumulate real practical experience. Later, when market experience becomes richer, new projects are more likely to achieve decent results. With those experiences, workplace decisions become more accurate, control over the environment improves, and product efficiency rises.
2.2 Without tinkering, experience stays shallow
The value of tinkering is that it lets you practice marketing and operations. This is not only for product managers. All makers should learn some marketing. When building something, you should ask: Who will use it? Where are the users? If users do not use what I build, what are they using now? What if nobody notices what I build? How can I make users pay attention to it?
Whether in a large company or a small company, relying only on the work itself for self-improvement is extremely limited.
A newcomer in product management will feel that any company teaches a lot, because a blank sheet of paper reacts to even a few strokes. But after you become familiar with product work and can complete existing tasks smoothly, only then does real self-improvement begin.
Large companies are characterized by detailed division of labor, distributed authority, and process control. Work must be broken into many links so that no matter how many people come and go at each link, business progress is not affected. Under this structure, each person becomes a screw. The business ability you can learn is limited. If you switch to another company with different processes and divisions of labor, many of the abilities you mastered may become almost useless. People who stay in large companies for more than five years can easily become overconfident but weak in execution, like lab mice in a greenhouse: their survival ability declines while their self-evaluation remains high.
Small companies are characterized by changing situations, messy work, and unclear processes. That lack of standardization can actually be a good practice environment. There are fewer rigid restrictions, messy work exposes you to a wider range of knowledge, and chaotic processes train adaptability. But this environment is not systematic. It requires strong ability to summarize and organize experience. Without a capable guide, many people get lost.
So regardless of company size, tinkering is necessary. In any environment or field, once you stay long enough, you become familiar, and familiarity creates inertia. Once inertia forms, energy fades and stability begins to feel comfortable. That is dangerous.
Tinkering is not making noise for the sake of noise. It is a way to keep yourself active and prevent yourself from living too comfortably. It is closer to a form of self-imposed difficulty.
In sports, excellent athletes do not merely practice until an action becomes muscle memory. The best athletes can still change that muscle memory under unusual circumstances. For someone who has repeated one movement until it becomes automatic, changing in a special situation is extremely difficult. Product managers need the same ability: use tinkering to break through their own “muscle memory” and add more copies of experience.
3. The managerial product manager
A managerial product manager leans toward administrative management, such as product department manager or product director. In general, this means managing people and managing work.
Managing people varies from case to case. Different company cultures and personal preferences lead to different approaches. It is not a simple subject.
Managing work is more goal-oriented. It includes product-line management, communication and coordination of company resources, and connecting product with business. This requires strong strategic thinking and decisiveness.
Before mastering efficient work methods, even the best tools are useless. Before choosing so-called productivity tools for a team or for yourself, first ask whether you already have an efficient workflow. It is like sports: what you spend time learning is how to play the game. Buying the best racket, ball, or knee pads will not magically turn you into an athlete.
To manage work, you must first know how to do work. A manager may not need to execute every detail personally, but must at least know how something is implemented, how tasks should be assigned, and how progress should be followed up.
The first product-manager function, the functional product manager, trains us to know how to do things. The second, the operational product manager, trains us to know how to do the right things. That is where strategic thinking and judgment develop.
Once you know how to do things and how to choose the right things to do, you also know what tasks exist. Managing work then becomes a goal-oriented process of assigning those tasks to team members and coordinating completion together. In reality, after mastering the first two types of capability, developing into a managerial product manager becomes a natural result.
One final point about career planning: when choosing a company or a job, a product manager should first ask, “What can I do for it?” rather than “Does this company have a future?”