A must-read article for both product and operations professionals: 7 years of experience in the industry!
I graduated in 2009 and started working in the Internet industry. It has been exactly 7 years now. During these seven years, in addition to writing code, I have done almost all product/ operation- related jobs in the Internet industry to a greater or lesser extent, and the years of experience are almost the same, three and a half years in product and three and a half years in operations, so that I am often laughed at as a jack of all trades. A year and a half ago, I wrote an article summarizing operations : "What are the differences between advanced operations and ordinary operations? 》 , many friends came to talk to me. Some people talked about confusion and bewilderment, some talked about career development, some talked about whether to change careers, and some talked about specific work issues. I tried my best to respond and discuss with them all. But I feel very guilty now. I think what I said before is no longer suitable for this new era. So I want to talk about something different, and my understanding of the development trends of products and operations. There is a very interesting new thing in the field of technology (not really new, the concept has been proposed for several years) called microservices. This microservice is not a concept like WeChat doing micro-business, but an innovation at the technical architecture level in the development field. I don’t write code either, but out of interest in technology and for fun, I bought some books and read them, and I found them to be a treasure. If you are interested in specific things, you can take a look at the two books "Microservice Architecture and Design" and "Microservice Design". My understanding of this thing is that this kind of development architecture completely decouples the previous package framework, and each application is decomposed into a corresponding dedicated service. To give an example that may not be very appropriate, when we look at traditional classified information websites such as 58.com, the information publishers and information acquirers are supported by the same system. This is based on the logic that everyone can be a publisher and a acquirer at the same time. Now, express ride apps such as Uber and Didi have been split into dedicated driver and passenger sides. Do you think there are drivers who are also passengers? Of course, but why not combine them? Because separating them can better focus on providing separate experiences for drivers and passengers. Of course, in actual technical development, this decoupling is not as simple as the correspondence between 58 and Didi. Since we are discussing product and operation issues today, we will not go into details. The reason why I want to introduce this concept first is that I think that in the field of product operations , in the next 3-5 years, there may be career changes that are very similar to microservices, that is, the "complete decoupling" of non-development work. I gave this concept a name, called "de-professionalization of product operations." Abbreviated as de-professionalism of pm. First, let’s take a look at the traditional division of products and operations in the work of the Internet industry.product: Product planning | Demand analysis | Project management | Competitive product analysis | Prototype design | Data analysis | Document writing | Communication and collaboration operations: Market research| User operation |Channel distribution|Brand communication| Community activities|Content operation|Business development|Event operationFor the sake of easy correspondence, I will write 8 of each and not more than that. Based on this classification, it seems easy for us to conclude whether a person's job can be considered product or operation. For example, if your core job in the company is to invest in various advertising platforms, or you are responsible for publishing articles on Sina Weibo / WeChat public accounts , or you visit partners one by one to discuss cooperation projects, then you are undoubtedly a 100% operations staff. For example, your daily job is to collect requirements and then produce prototypes, communicate business logic with developers every day, and even have to write SQL and run data yourself. Axure is your most commonly used software. At this stage, you seem to be a 100% product person. But from my feeling over the past year or so, this kind of 100% pure work that can be easily defined is becoming less and less. Many of my classmates who have communicated with me always say as their first sentence: "I don’t know whether I am considered a product manager or an operations manager. I always feel like I do a lot of things." I believe this idea lingers in many people's minds, causing them to be confused about their personal skill development and career path. Question: Am I considered a product manager or an operations manager? Derivative question 1: Is my career development direction product or operation? Derivative question 2: If I am a product/operation person, should I do those operations/product things, how should I do them, and what should I learn to do them better? Derivative Questions n…. … And it is not just the front-line executors who have this confusion, but more managers as well. How do you plan a career path for a younger brother who seems to be working hard? If this guy gets promoted again, where should he be placed and what title should he be given? If these problems are not solved properly, talent loss will often occur. To be honest, this kind of trouble was not much three years ago. But times have changed. In Internet companies, design, development, and functional departments such as finance, human resources, and legal affairs all have positions with very clear career paths. Suppose we talk about a newly graduated designer. His career development path is to gradually become a master in the industry from a small designer. Of course, in the process of his development, it is inevitable that there will be some expansion. In the end, he may have to understand some of graphic design, UI, advertising, web pages, apps, etc., but in time, he will definitely become a master who is particularly proficient in x and y in the design industry and exist as an industry leader. The same is true for development. A programmer will be characterized after working for about three years. He will have a label, such as "back-end Java engineer". The direction of his skill development may become increasingly different from that of a "data mining Python engineer". Four or five years later, they may be experts in completely different fields, and it will be difficult to switch between them (of course, the gap is not that big. It's mainly because the pitfalls they have encountered in these seven years will be very different). Not to mention human resources, finance and legal affairs, the path is very clear: specialist - manager - director - director of an even better company - CXO of an even better company. What we are talking about is essentially because the "depth" (to quote a word from architecture) of these jobs is very deep. The difference between a person who has been working in recruitment for ten years and a person who has just graduated and has been working in recruitment for one year can be very, very huge. In their career development path, there is sufficient motivation and opportunity for learning within the circle, as well as a clear path for promotion in rank/salary. But products and operations are not. Among these jobs on the Internet, there is no job as profound as "graphic design". In other words, there is no such job that you can do for your whole life and become a "master of xx". Suppose a classmate named Xiao A, who just graduated this year, went to a company to do channel distribution. At the beginning, this company only opened an account for search engine promotion, and Xiao A was responsible for SEM . Xiao A did a good job, and after a year or two, the boss promoted Xiao A and hired a few more subordinates to be responsible for search engines, display ads, new media ads, etc. Xiao A was promoted to channel manager. What's the next step? Can Xiao A work as a channel manager until he is 60 years old? In traditional industries, this is possible, especially in the traditional channels, where various distributors meet regularly to drink. These are all offline businesses, and you can learn as you live. In the Internet industry, it is a bit difficult, because a normal-minded and hardworking person can become an expert in search engines in about a year, and content operations can be completed in about 8 months. By collecting requirements from various departments and drawing prototypes, you should be able to master it in less than half a year. Then what? The pain of many of the students who communicated with me came from the fact that “I am already very familiar with what I am doing now, but due to environmental limitations, I cannot expand further.” Then they would ask me what I will do next and in which direction to expand. For product operations jobs, our career path is not vertical. No matter how good a copywriter is, it is impossible for him to write for his whole life. Even if he works for a public relations company that specializes in copywriting, his career path is to become the director, vice president of that company, or even to become the CEO of his own public relations company. Many students in the field of technical development and design will struggle with a question: I have been working for x years, should I switch to management, or continue to study my own career direction? This problem does not exist for product operations, because the depth of a single job is limited, so it is natural to transfer to management. The reason I have said so much above is to first realize that "there are limitations on the depth of product operation work." Then let’s look at the 16 jobs mentioned above. Product: Product planning | Demand analysis | Project management | Competitive product analysis | Prototype design | Data analysis | Document writing | Communication and collaboration Operation: Market research | User operation | Channel distribution | Brand communication | Community activities | Content operation | Business development | Event operationIf you have been working for more than 3 years, look at how much work you have done and see if you clearly think you belong to product/operation, but end up doing a lot of operation/product work. The operation of developing a push activity page by yourself with your own prototype is almost as much as the product of doing market research yourself. Especially in smaller companies, you have more coverage across boundaries. Large companies led by BAT are committed to professionalizing their personnel. For example, one person is responsible for research, and one person is responsible for maintaining a small group of users. However, this kind of specialization naturally creates a conflict with the career development of people in the position. From the company's perspective, we hope to have stable personnel and stable output. A media monitor who has been working for a year is always better than an intern who just came in and knows nothing. But there is no way to pay more for this job without being promoted to management, because to put it cruelly, "this job is worth the money", and for the benefit of company management, specialization is an inevitable result. From a personal perspective, I hope to have better career development, with both title and salary rising steadily. Therefore, if you have worked for 1-2 years and want to get more salary, since there is no way to expand vertically (the company cannot offer a high salary to someone who only does media monitoring), you can only expand more business horizontally. If you expand horizontally within the company, you will face the problem of becoming a manager (otherwise you will steal other people's jobs), and promotion within the company is limited after all, so you will jump to another company to become a manager. Therefore, taking a management position is a natural outcome for product operations personnel, it’s just a matter of how big the management is. However, it is impossible for a company to put everyone into management positions, which creates a natural contradiction. This contradiction has existed for a long time, but it has become more serious in the past one or two years. What I have seen is that in the product operation industry, the tools that people use in their daily lives are becoming more and more convenient and easy to use. You can use strinkly to quickly make a cool landing page, use mikecrm to quickly organize a user survey form, use Modao to quickly assemble an app prototype, and there are also extremely fast h5 page creation tools like epub360. The ease of use of tools has lowered the threshold for job types and diversified the means of work, which means that the boundaries between various product and operation jobs will become increasingly blurred. For example, an operations classmate named Xiao A wants to make an h5 that can spread virally, but the R&D department says they are short of money, the product department says they are busy with work, and the design department says they have to schedule. In a fit of rage, Xiao A made one himself using a bunch of combination kits and ready-made frameworks. After it ran, he got the data to prove that this approach was feasible, so he persuaded his boss to invest more resources to make a good product. Xiao A does not depend on anyone, which to some extent has taken away many people's jobs. Many things can now be done by "doing it yourself", which is a great thing for those who are capable and constantly eager to learn. If you are a technician or have a technical background, you will easily think of a concept called "full stack engineer". Yes, that's what I'm talking about. So here I want to call "de-professionalized product operation" "full-stack PM" (copying the concept). PM means product & marketing in Baidu, not product manager . Based on full-stack PM, there are more possibilities in business architecture, and the contradiction between company needs and personal career path that we just discussed may also be resolved. The new company structure will most likely not be like the current one, where there is a product department led by a product director, and an operations department led by an operations director. The two sides are like water and fire, and often argue and shirk responsibility. Instead, just like the changes made to microservices at the architectural level, the company's business is broken down and divided into finer granularity than it is now, and each fine-grained business is promoted by a full-stack PM. If you encounter something you are not familiar with professionally, full-stack PMs can learn and ponder from each other, and then continue to explore. This is difficult to describe in words, so I'll draw a few pictures for you to see. This is the traditional product operation pyramid structure. This independent product can be big or small. If it is big, then there may be different departments at the bottom. If it is small, then one person will do many things and have to take on multiple roles. The problem with the traditional pyramid structure is that when the product inevitably grows, it will gradually turn from one person performing multiple duties into a pyramid that requires specialization. The variables here are: 1. Is this person qualified to be a manager at the beginning? 2. Can the newly recruited person surpass the original person in a specific job? So I guess this may be the case in the future (in fact, many companies are already using it, including some independent products of bat). Here, the product is independently divided into several business lines. Each business line has several full-stack PMs who can do everything to unify the product and operation work, led by a more senior PM. The specific granularity of the breakdown depends on business requirements. Then everyone has the authority to independently design products, coordinate R&D, bring them to market, and contact users. We no longer distinguish between product and operation work, but only look at what the business line itself needs. I think there are several main advantages to doing this: 1. Flexible manpower allocation: Full-stack PMs from different business lines can be replaced or seconded at any time, but each person’s skill focus may be different. But this emphasis is different from the "specialization" in the traditional architecture. Two full-stack PMs with three years of experience may have their main skills above 80 points, but they may have several skills at 90 or 100 points. This is reasonable and should be encouraged. 2. It is more conducive to management positions and better career development: In such a structure, every full-stack PM will inevitably become a manager in the future. Because of the diversity of their skills, they can take over different business lines of different products very quickly. Moreover, due to the refinement of business lines, it is easier to overlap in large industries. And if there are not so many management pits in the company, the way to get promoted is to become a senior product operations manager. To a certain extent, independently leading the creation and development of a product is already a big enough step forward. Of course there are also disadvantages. For example, you need at least one senior full-stack PM to be the person in charge of this business line (relative to the granularity of the business line). There are few such people in the market. But I think that in three to five years, as tools become more convenient and methods become more diversified, many things will be learned very quickly, and there will be more and more full-stack PMs. Another disadvantage is that some jobs that really require specialization are not suitable as full-stack, but this is also simple, they can be extracted as independent support. Of course, this is just a generalized model, and there are many details to discuss specifically. Here is an example: ABC Company is a company that has just received Series B financing. The company’s main product is a football betting app (since this is hypothetical, let’s discuss something illegal). The company's app mainly has three major independent business lines: football information, football betting and gambling fan community. The traditional structure (especially when the company is small) is likely to have a product department, and then there are several product managers in the product department, who are responsible for the product design and follow-up of these business functions. There is also an operations department. Some people are responsible for collecting football information and inviting some senior football writers to write articles. Some people are responsible for monitoring daily guessing data and odds support. Some people are responsible for being active in the gambling fan community, finding some UGC, engaging in offline social activities , etc. Let's not do this. We first divide users into three groups according to their attributes: the five major leagues group, the Chinese Super League group and other groups. Each group's full-stack PM is responsible for everything their respective users might do. For example, the PM of the five major league groups needs to be involved in product design, user operations, guiding recharge and betting, and activating subsequent discussions, etc. Although users are fragmented (people who care about the Premier League may not watch the Chinese Super League at all), user behaviors are not fragmented. A gambling fan may first read the information, then place a bet, and then go to the fan community to read posts, and so on. Once there is a big event like the European Cup, we can draw a group of people from each of the three groups to work on a project specifically called the European Cup. This project also involves full-stack PMs, who will be responsible for everything from the design, development and launch of the European Cup product to the promotion and operation of odds calculations and the organization of fan activities. This idea is actually not new at all. Project-based work has existed since ancient times, but the significance of a full-stack PM is to treat all daily tasks as a special project (just like microservices) and normalize the project. Then another question arises here: how detailed should the business groups be divided into? My inclination is to classify by users and determine based on the degree of user overlap. For example, if necessary, the five major leagues can be divided into the Premier League and non-Premier League (after all, Premier League fans are more commercial and like gambling with more money), and two groups can be used to follow up. In order to ensure the uniformity of the product as a whole (for example, you cannot have the Premier League and the Chinese Super League use very different UI interfaces, although the colors can be changed), each group needs to routinely unify and determine standards (a bit like a company's requirements for code standards in technical development, which is necessary) Speaking of this, you may think it is a bit idealistic and theoretical, but the fact is that many companies are already doing this even though they don’t say so or require it. Especially for companies headed by BAT, if you look at their new businesses launched in the past year, almost all of them were full-stack PMs transferred from other old departments in the early stages. As the business develops smoothly, some graduate interns with insufficient work experience will be recruited to do some basic segmentation work, but after a period of time, many people have acquired all the skills and abilities from collecting requirements, drawing prototypes, following up on development to promotion and operation and iteration of functions after product launch. In their own words, this is called "being forced". We are always forced to learn something, so if the cost of learning is getting lower and lower, it is better to take the initiative to learn. If the career advancement is not deep enough, then go in a broader direction. Because product operation work is different from the more in-depth professions such as design/development, full-stack PM will be the general trend of product operation talents in the future Internet. So don’t limit yourself to the question of product or operation. For a certain wave of specific users, you are both the product and the operation. What you need to do is to make your users feel that your product is valuable and continue to use it. It doesn’t matter whether it is functional improvement or event planning. There will always be some jobs that are not even sure whether you need to hire a dedicated person to do this. This is when a full-stack PM is valuable, because if you don’t understand certain specific things or learn them quickly to the point of understanding, you may even be cheated if you outsource them. Of course, a certain degree of professional accumulation in a certain sub-field of product operation is very necessary. Therefore, new product operators with less than 2 years of work experience should still focus on accumulating 2-3 core skills, so that they have a basic guarantee from practice to methodology, and then expand other skill points. So in the end, I give the following definition of full stack PM: In Internet-related work, you need to be able to use a variety of skills and tools and, based on the ability to learn quickly, be able to independently complete the entire process of product planning and design, development and launch, and operation and promotion . For those who become full-stack PMs, their work is not to become a senior expert craftsman, but to "get one thing done." In order to "accomplish something", I will learn all relevant skills while keeping the learning cost under control. If you are committed to becoming an expert/craftsman/artisan, product operations work in the Internet industry may not be a good choice for you. Isn’t the founder of every company the first full-stack PM? Next, let’s talk about the skill tree and learning path of a full-stack PM. Before discussing the details, I want to point out that "full-stack PM" is not a concept I made up out of thin air. It is the actual situation of product operations personnel in many Internet companies today. Although we borrow the "full stack" from "full-stack engineer", it is different from the development field after all. I will talk about the specific differences later. Therefore, you don’t have to apply some of the concepts and conclusions of full-stack engineers. The difference is really huge. The biggest difference between a full-stack PM and the product/operation and job separation within product/operation under the current management structure is its jack-of-all-trades attribute, that is, “knowing everything”. But the panacea is just an appearance. Behind the appearance of the panacea is actually a super strong "learning ability". But when it comes to learning, there is always an input and an output. Given limited time, what are the basics that can lay a better foundation for learning other things in the future and make learning other things easier? This is the issue we are going to focus on this time. First of all, in line with the principle of starting from the end, we must clarify the core value and competitiveness of "full-stack PM" before discussing how to build and cultivate these values and competitiveness. Any Internet product must be innovative and constantly try and error in the direction of innovation. When it comes to trial and error, there are high and low costs. You directly recruit a senior xx, and then recruit a few senior xx and a few junior xx (xx refers to various fragmented positions such as channel operation, product manager, new media operation , etc.), and they are paid hundreds of thousands of yuan a month without doing anything. Then you find that it doesn’t work, no one uses the product or the market environment is not suitable, so you cut the team or transfer them to other positions - this is trial and error, high-cost trial and error. You find someone and let him explore first, regardless of whether he is willing or not (there is a high probability that he is unwilling, after all, it may be far from what he thinks is his main career direction), let him try it from scratch and learn step by step. The cost of learning for several months is too high (after all, many things he has not been exposed to before), and then he misses the market opportunity. This is also a kind of trial and error, a low-cost trial and error. Strategically speaking, both taking big actions and taking small steps are options. When a giant company wants to make something, it has sufficient resources, so of course it will go all out, wishing to dominate the market with all its might. When a small startup company wants to make something new, it has limited resources, so of course it has to take small steps and move fast, trying to verify whether the new thing is reliable with minimal investment. So the level of cost is actually not important. What is important is whether, with these cost investments, we can verify the result that “there is potential in this direction, so continue to increase cost investment”, and then determine whether these costs are worth it? The answer is obviously not certain. And I think that a full-stack PM and a team led by a full-stack PM will be a good way to balance these costs. Invest a controllable number of full-stack PMs with limited resources until these new businesses are sufficient to verify whether to increase investment or cut them, and then move forward. If they increase investment, it will simply become a new business or a new department. If they cut it off, it doesn’t matter, they can still do other things. This is better than hiring a bunch of professionals only to find out there is no work in this field and they are unable to transfer internally, which results in the tragedy of having to lay off employees (or waiting for everyone to resign). I believe many people have experienced this scene. Therefore, the core value of full-stack PM lies in two points: 1. Save costs to the greatest extent possible in the early stages of the development of innovative businesses; 2. In the middle and late stages of business development, there are managers who can take a bird’s-eye view of the overall situation. Cost advantage and ability to grasp the global business have become the biggest competitive advantages of full-stack PMs compared to ordinary teams and managers. (Have you ever met a manager from xx background who doesn’t understand oo but still gives orders to △△? You know what I mean.) This is actually very easy to understand. I will discuss the specific cost accounting and management methods in subsequent chapters, so I won’t go into details here. (In fact, there is another hidden value, which is to prevent the core resources of the product from being overly concentrated on 1-2 core positions. It is like not putting all your eggs in one basket, because it is actually very simple for a full-stack PM to replace another full-stack PM. We will talk about this later.) So around this core value, let’s take a look at how the talent tree of a full-stack PM should be constructed. (The full talent chart is attached, don’t look at this first, read it after you finish reading) First of all, at the very beginning, there are three core basic skill directions and the corresponding core approaches: 1) Product design (core approach: prototype design) - think about users from a distance. 2) Acquire users (core approach: channel placement) – stand in the middle and observe users. 3) Get in-depth understanding of users (core approach: user operation) – Listen closely to users. Under the three major directions, based on these core approaches, we can expand to all aspects of the entire Internet product operation, and the foundation accumulated in these works will become a guarantee for rapid learning. Under the current job division mechanism, we can easily see product personnel who are far away from users, channel personnel who mechanically deliver KPIs, and operations personnel who talk about user growth every day. Just like the blind men and the elephant, everyone understands it differently. You are a product manager, and in your eyes user feedback is only about size and priority, not about individual living things; you are a channel manager, and for you there is only the path of cost-download-activation, and you may not care at all who the user is; you are an operations manager, and you think user feedback is important, and you consider issues reported by a thousand users and issues reported by a hundred thousand users to be equally important. Even if we occasionally pretend to do some user research and interviews, can these things really solve the problem? We all know it. So we need a full-stack PM who can equally perceive users from different distances. What they need to do is not to draw beautiful high-fidelity prototypes, construct complex product logic, or master perfect channel traffic details and build a super perfect loyal user community. What they need to do is to achieve 70 points in each aspect. Yes, not 80 points (okay) or 60 points (just passing), but "70 points" that is neither good nor bad but barely usable. And at this point, the more average the ability, the better. No matter what your previous job was or what your strengths were, if you want to be an excellent full-stack PM, you need to have as balanced abilities as possible in these three core areas. Because the more average your abilities are, the easier it is for you to return your view of the problem to the simplest logical relationship between user and product. Any direction that goes too far beyond other abilities may give you a biased perspective on understanding this relationship due to the distance from the user. What you need to break is the concept of "looking at users and the problems they cause from the perspective of products/channels/operations" and re-establish a research method that pays close attention to the [user-product] relationship process. That is, don't be user-centric, but rather discover and solve problems based on the process by which users become familiar with the product. Some students with a technical background may suddenly think: Isn’t this the difference between object-oriented and process-oriented? I can only say that it really looks like one. (PS: The more average the better here, which does not conflict with what I said in the previous chapter, "mastering certain specific skills to 90 or 100 points." After all, there are always some things we learn and master faster and better than others. This is just the proficiency of some specific practical skills.) Next, let’s take a look at these three skill areas and see what basics you should master and why you should master them. 1. Product Design There are several specific skills in the direction of product design: 1) Demand analysis - master the basic demand analysis methods [May involve (just an example, in fact, there are far more): form tool - MikeCRM; data acquisition tool - Baidu Index, competitive product reference - IT Orange, industry report - iResearch, etc.] 2) Prototype design – draw a sketch of a feasible product prototype [May involve: Prototyping tools - Axure, Visio, Moknife, epub360, paper and pen) 3) Logical architecture - product logic of the prototype backend [May involve: mindmanager/xmind, office (data parameter document), visio] 4) Communication and collaboration - communicate with programmers/designers, etc. [May involve: demand management tools - Trello, NetEase Cloud Collaboration, Teambition, etc.; communication tools - mouth, email, ppt/keynote] The most important thing here is prototype design, which I think is the core approach to "product design". So you may not have done the other ones, and may not be proficient in them, but if you want to become a qualified full-stack PM, you must be able to make very good prototype products. The "good" here does not mean how beautiful or neat your work is, but that the logic is clear and simple enough to meet the needs of users. As you continue to delve into prototype design, you will naturally touch the door to demand analysis, logical architecture, communication and collaboration, or other product capabilities. Because you will repeatedly think about what the user will ultimately see, whether it is good, and whether I like it. When you are thinking about "what should be given to users", other skills are just to better achieve this goal. If you continue to improve in the area of "what users want", then other skills and abilities will naturally be improved. Therefore, in the general direction of product design, following the path of prototype design, you will eventually: ——Know where and how to get data to support demand analysis; ——Be able to describe the basic sketch of the final product presentation; ——Be able to sort out the logical relationship and data flow between the various elements of the product; ——Be able to get the R&D/designer classmates to help put the designed things online. You just need to be able to do it, and be skilled and proficient in the use of specific tools. You can say that you are capable of using Keynote to make a beautiful slide, but in terms of the results, you have to consider the input-output ratio. After all, there are many other things waiting for you to do. (Of course, if you hold a product launch conference and countless reporters, media, and users come, then it is worthwhile for you to invest in making something beautiful - provided that you can't find a master who specializes in making slides to help you, otherwise it is better to hand it over to them.) 2. Get users Within the broad framework of user acquisition, there are countless subdivided positions. There are endless skills and methods to acquire users, but among them, why is channel delivery the best core approach? What is channel distribution? To put it simply, it means spending money to buy traffic. You spend some advertising money, and as long as it is not a scam channel, there will always be some traffic coming to your product. As for whether they will download, activate or register, that is another question. You say that I have made a product for xx user group, and now the product is online. What could be faster than going directly to the place where xx user group gathers to get some traffic to verify whether your product is useful? Or your product may be further subdivided into several categories of users (whether you divide it by gender, city or industry). Then buying 1,000 traffics separately to look at the conversion funnel will definitely reflect the impressions of strangers more intuitively than you painstakingly find some specific users to try it out. Because what you need is data, and directly spending money to buy volume can help you obtain data faster to verify whether you should continue to invest in or cut what you are doing now. A powerful channel delivery capability will help you spend the least money and buy the user behavior data you want as quickly as possible. Based on this, there are several points you must achieve. 1) Be proficient in the operation of 1-2 mainstream advertising platforms (Baidu bidding, Sina Fans Link , Tencent Guangdian Link , etc.) and related advertising experience (a total cost of 1 million RMB for PC + mobile platform is considered a passing experience); this job can help you quickly establish an understanding of the size of the user group, acquisition price, conversion rate , etc. Many times, you don’t need to spend a penny. Just looking at the exposure of the purchased keywords or ad spaces is enough to confirm some of your ideas. Even if the company does not have the conditions to launch the campaign for the time being, I think it is entirely possible to find a friend's company or set up an account on your own to conduct research. Baidu's http://www2.baidu.com, Tencent's http://e.qq.com, Sina Weibo's http://tui.weibo.com and Taobao Express can be carefully studied, and other platforms can also take a look. However, in terms of traffic promotion toB services, there are some literary and artistic websites' advertising backends, which I can only describe as unprofessional. 2) The ability to independently design and complete landingpage (landing page, sales page, activity page), including design (here is related to the prototyping ability of product direction, and every excellent prototype designer may be a first-class landing page designer), writing copy, setting conversion paths, etc.; 3) Make good use of tools for data analysis (conversion analysis tools: Google analytics, Baidu statistics; app monitoring tools: application radar, app annie, etc.); proficient in data statistics and analysis methods (ab test, cross-analysis, regression analysis); 4) It is very common to be able to negotiate with channels in a casual manner. Channel providers include but are not limited to: forums, QQ groups, PC media, app app stores (if your product is an app), and even channel providers include other departments within your company. It is possible to quickly get enough verified traffic at the minimum cost. Of course, you say that you have the relationship with the xx website and you don’t have to spend money to buy it for free. This is of course the best, but not spending money does not mean that you can use crappy landingpages and unreasonable conversion paths to waste your traffic. So we found that when you want to better build your "channel delivery" capabilities, you slowly learn core abilities such as channel expansion, data analysis, copywriting, cooperation negotiation, event design, etc., and these abilities are a great help to you in new media, business BD, KOL expansion (i.e., invite opinion leaders), soft article marketing , etc., and it is also the basis for being competent for full-stack pm at the user level. 3. Go deep into users Many people say that users are very smart. Some people also say that users are stupid. Some people also say that users are stupid but you have to make them feel smart. Some people also say that users are smart but you should treat them as lazy and stupid fools. These are the simplest conclusions that blind people can draw from the way they touch elephants. Users are not an abstract generalized concept, and users are not numbers and kpis on statistical tools. Users are a collection of real individuals. We need to get close to users, understand and listen to users, but we cannot be too close to them, otherwise it is easy to be infected and burned by their emotions. Because the butt determines the head, the closer you are to the user, the more likely the pain, dissatisfaction, and complaints of the user you see, the more likely it is to become your pain, dissatisfaction and complaints, and then interfere with you and affect your judgment of what you want to do. Under the function of separation, the conflict between products and operations often comes from different degrees of proximity to users. Of course, a full stack pm, because you also need to penetrate into users, you will inevitably be infected by users. But precisely because you are full stack pm, you won’t get too close, and you will also get enough distance and the opportunity to “jump out and see the problem”. This is certainly contradictory, but this kind of switching is undoubtedly helpful to the product-user relationship itself. There are many ways to go deep into the general direction of users. You look at the behavior data of users in the product, you have face-to-face interviews with users, you hold regular meetings to organize KOL discussions, you communicate with users sincerely on social media, you are an excellent customer service to solve all kinds of messy problems of users... These are all methods to penetrate the user, but there is no more effective and direct way to directly operate a group of loyal user groups. Most products will have a number of loyal users of varying numbers, and all you have to do is gather a group of loyal guards you have covered. The way to gather can be a Q group, a Zhihu follower, or a Weibo and WeChat. They will give you suggestions and feedback questions regularly, and you will also listen to their complaints and communicate their feelings and your thoughts. User operation is the most core means to penetrate into users. You need to use this as a basis to keep the distance between you and the users from being too far away. So if you keep learning and growing in the way of user operations, what will you get? 1) Get the fastest feedback on demand for new versions/changes/function iterations, and even these feedbacks have begun when your prototype design comes out. (link to product design) 2) The first batch of data was obtained based on the distribution and spread of personal social networks of loyal users. (link to get users) 3) Obtain the voice of users of purchasing products and consuming products themselves, understand the problems and pains of front-line executors, and better conduct team management and training. (link to management skills – this will be said separately) 4) The addition, hierarchy, incentives and punishments of loyal users will be more conducive to you to build user rules within a larger global scope. 5) You will be familiar with the gameplay of a lot of communication tools such as qq, yy, Sina Weibo, WeChat official accounts, etc., and you may also have to learn how to mine user behaviors such as databases such as mysql.Of course, there are many more. Your pre-research questionnaire, test of some major function changes, interviews with specific users, and ways to keep connected with users can all start from the basic loyal user operation. There are many things that seem more cold-blooded about this, such as "private forces" that cannot make users become managers, especially some resource-based users (such as campus promotion , ground promotion channels, sales networks, etc.). As a full stack pm, it is a very advantageous precaution to maintain proper contact with some core users. Don’t forget that if your business line has ground promotion or sales, they are also your users. I won’t go into this. In short, we focus on "process relationships" rather than users. It seems good to be user-centered, but unless the organization has a strong, absolutely authoritative person to control it (like Jobs did), it will create endless barriers and fights when each department determines its head because of the different ways of contacting users/distances with users. Think about it, are you now? To summarize it with a sketch, I probably want to express this meaning (the picture is relatively simple, and I don’t have time to draw it well for the time being. In addition to the three core functional personnel in the left picture, there should be other types, just say it) OK, that's all. Many of the methods I mentioned above will be lower and lower as the tools are further optimized and routines are standardized (a lot of products and teams are committed to achieving this goal). A few years ago, the mindmanager was a high threshold for teaching. Now the learning cost of tutorials and articles on the street has been greatly reduced. In this case, we will find that the value of certain positions is getting lower and lower (such as Baidu Sem, product assistant/specialist, basic user operation, etc.), as low as an intern or a new student who has just graduated for less than one year can quickly achieve 80 or even 90 points. As long as your company is not a core dependence on a certain position, there is no need to achieve 100 points (it is not wrong to strive for excellence, but depends on the input-output ratio). So what about product operation for more than one year or more? What do they do? Can you still only work as a basic position? Then your career development and income will be bound to the mechanical module and cannot move. So from an executor who only does one thing - expanding to "sub-full stack pm" (referring to pm that specializes in product design, acquire users, or penetrates into the general directions of users. Sorry, I created the words again, but I really don't know how to express this intermediate state) - upgrade to innovation that can independently expand/support business - becoming the business leader to lead the team to continue to innovate in the next step... This process is a must for all product operators in the current split state. Of course, if the existing company management structure is still divided by the original functional business department, it is of course not applicable. The organizational structure almost necessarily requires innovation, and this point should be no distinction between large and small enterprises. Large companies always have innovative new businesses, so they naturally need full stack pm. Small companies themselves are constantly trying and making mistakes, so everyone should be full stack pm. The only confusion may occur in medium-sized companies. On the one hand, people with professional abilities need to make up for the professional positions and consolidate the country that has been built, and on the other hand, they need to keep running non-stop. Under the current market talent structure, it is not enough to support a sufficient full-stack pm team (the team is very important, because the best learning object for full-stack pm is another full-stack pm). This issue of company management is something that existing managers in every Internet company may pay attention to, and I will talk about this issue later. Specializing in direction and skills fish bone diagram (you can draw a little grass first, the core meaning is to constantly touch and learn new related skills under the guidance of the three troops of "prototyping", "channel delivery" and "user operation".) As for what you learn in specific skills, each product is different, just like it. Some concepts are clear: 1. Product: When we are discussing the concepts of product design, user-product process relationship, etc., the "product" refers to your business line and what you are going to do. When we are discussing product capabilities and product personnel, we refer to positions that now focus on demand analysis, prototype design, communication and other work. 2. Operation: Large-scale operations actually cover channel + user operations, but let’s narrowly define it and discuss channel deployment and operation separately. Behind channel deployment represents a large number of tickets and "acquisition of users", which is what we commonly call "new recruitment". Behind "user operation" is a major operational work related to what we commonly call "retention" + "promotion". 3. Actually, I don’t want to mention the above two concepts anymore. They are all concepts under the original user-centered product operation concept. But there is nothing we can do. The reversal of concepts takes time. I prefer to use the "product"" specific work in the product stage" to carry out structured and specific work. You don't have to worry about this personal idea. Your APP |
>>: How to use the Tik Tok mini program? How to activate the Douyin mini program?
Recommend
How do I view server logs? How to view website logs?
For a website optimization SEO personnel, it is v...
How many of these 10 tips for promoting mini programs do you know?
If you care about mini programs , then you should...
How to carry out a more complex “S-level content” operation? ?
Content-based platforms usually produce or introd...
How much does it cost to develop an Anyang cosmetics mini program? Anyang cosmetics mini program development price inquiry
How much is the quotation for cosmetics developme...
Cailianshe Selected VIP Column – All-Weather Investment Trends 2022
Cailianshe Selected VIP Column – All-Weather Inve...
2021 Wandering "Sublimation Chat Training Camp 2.0" The Second Love Secrets and the Strongest Chat Course
A big class! 2021 Wandering "Sublimation Cha...
How to manage active users?
User operation is a relatively lengthy process. W...
Does your oCPC advertising really work?
oCPC is now a familiar concept. You may not have ...
Where can I check Douyin credit score? What are the rules?
Now many friends have opened accounts on Douyin. ...
Douban traffic flow course, learned how to easily attract 300 accurate traffic per day
When people mention Douban, the first thing that ...
What is the meaning of Wenchang Tower? What is the function of Wenchang Tower?
Wenchang Tower can promote academic success. Many...
How to do user recall? 10 strategies!
In fact, whether it is recalling users who have a...
See how the two skill selling platforms "Tingke" and "Kongjia" operate differently!
With every opportunity for consumption upgrade, w...
6 elements, how to trick consumers into placing orders step by step?
Our consumption behavior is 100% controlled. Why ...
Kaikeba Digital Business Analysis and Management Elite Class 01
Introduction to the resources of the 1st session ...