A picture ๐ of the opening
I've talked about this topic intermittently before, but it's not very systematic and coherent, so I'm trying to make it clear at once today. Although the content of this article is particularly hard and slightly longer (about 7000 words), it is free for public welfare reasons! So welcome to read and forward it to friends in need
BTW: From the beginning of this article, our public account can finally leave a comment! Welcome readers to bubble and advise hahaha~
Getting to the point, I'm going to talk about 3 points in order for today's content:
- What exactly is a data product: including job definitions and refutation of misconceptions
- What are the cool points of making data products: from the perspective of income, body feeling, career life, etc
- Who should consider trying: my own experience and the cases I have seen
I hope that you will abandon some of the previous prejudices and misconceptions, and at least patiently read the first part first
1. What exactly is a data product?
When it comes to data products, many people think of the basic data kanban (BI), a small number of people will think of the data platform, and some people will think of burying and data indicator system construction, in short, it is more confusing. In fact, not only do outsiders have a lot of misunderstandings about data products, but even if they are doing data products, few can clearly explain what this position does. The reason is very simple, even practitioners rarely see and experience the full picture of data products, so blind people touch the elephant and generalize in an endless stream. Today, I'm going to try to explain it all at once, and if you can understand the following content, you will know more about data products than many data product managers who have been in the industry for 3 years
"Definition of Data Product"
This has been mentioned in the previous article, so the focus is on interpretation. Let's start with the definition:
"In each link of the whole data chain (acquisition, storage, management, processing, analysis, application), the product form for individual or enterprise users to reduce costs, increase efficiency, and promote revenue is a data product."
Maybe many people can't see anything special just by looking at the definition, so let's interpret it a little:
โ The "data full link" data product must be for the data link, which can be simply summarized into six links, namely data acquisition, storage, management, processing, analysis, and application; At the same time, data products are not only for a certain link in the chain, for example, not only data products are called data products for analysis and application, but also for other links
โ Since the "product form" is called a data product, it must first be a product. Here I chose a relatively narrow definition of product, especially to limit it to the familiar APP, web page and other carriers in the Internet world, which is the kind of product that can be operated and experienced. In this way, it can be distinguished from non-product forms such as data analysis reports, model strategies, interface services, etc., which cannot be intuitively perceived by users, so as to avoid making subsequent discussions too divergent
โ "Individual or business user" data products not only serve enterprise users, but also directly serve ordinary individual users. In addition, enterprise users are also divided into internal and external enterprises, and early data products may serve more internal enterprises, but with the enrichment of the form and value of data products, there will be more and more data products directly facing external enterprise or individual users
โ "Promoting revenue" We are often familiar with the value role of data products in reducing costs and increasing efficiency, because there are indeed more such data products, but we also have the misunderstanding that data products can only help people save money behind the scenes, and cannot go to the front of the stage to help people make money, but they are not, but we have not seen it
"Some Common Misconceptions"
With the above positive definition and interpretation, can we also learn and sell now, and try to criticize the popular misunderstanding of data products in the market?
โ Myth 1: Data products are BI Kanban? BI, data kanban, and reports are just one form of data products, such as the data collection link can have a buried point management platform, the data processing link can have a data middle platform/portrait label platform, and the data application link can use Taobao business advisor/huge cloud map and other styles
โ Myth 2: Data products are mostly for internal use? As a well-known data product, Baidu Index has always been open to the outside world, and it is not only toB, but also directly used by many people
โ Myth 3: Data products can only reduce costs and increase efficiency? Many data products are developed and sold commercially, especially in the field of advertising and marketing
โ Myth 4: Do data products have to analyze data? By definition, if a data product is in the acquisition and storage phase, it doesn't necessarily have to analyze the data. Most of this misconception stems from the data analyst community, which believes that analysis is the ultimate goal of data. Actually, problem solving, analysis is just one way. If there is no need for analysis and just the transfer of data is valuable, then it can be a data product after productization, such as Qichacha and Octopus
"What to do on a daily basis"
We know from the definition of a data product that a data product can be roughly divided into at least 3 layers:
โ Basic layer: corresponding to data acquisition and storage. Specifically, the things to do may include, but are not limited to, data burying, data interface design, data quality monitoring, data governance, etc.;
โ Middle layer: corresponding to data management and processing. The specific work content can imagine a data middle platform, which is more of a platform, modularization and automation of the data production and construction process. For example, crowd portrait labels, product category attribute construction, etc.;
โ Application layer: corresponding to data analysis and application links. The work content at this level is relatively rich, and it is also closer to the imagination of data analysts, such as online, automated, and productized many offline data analysis reports.
I plan to take the daily life of a data product manager at the application layer with relatively rich work content as an example, which can be summarized in an abstract manner as follows, and then introduced one by one:
โ "Product Research - User Research" Whether it is a new product or an important function of an existing product, you need to do a good job of user research. Sometimes the demand may come directly from the docking partner, and there is no way to directly communicate with the original demand proposer, but it is also necessary to ask clearly when receiving the demand, and the core is still the sentence "who and what problem to solve". In terms of understanding the real needs of users, there have been many books by product managers that have discussed it, so I will not repeat it here
โ "Product Research - Competitive Product Analysis" can be combined with user research here, if you can find the original user, you can directly ask them what problems they have with the use of existing competing products, and it is too easy for users to complain that a thing is not easy to use~ What is particularly taboo here is to directly copy the function of competing products, even if it seems to be exactly the same business, different companies will have their uniqueness, and they may not be able to completely replicate. And I personally believe that data products are in a chaotic initial stage, even if the Taobao business staff has been put into production very early, there are still many problems, and direct copying may not be able to copy the essence, but may copy the problem
โ The ideal output summary of the "Product Research - Product Planning" research link is actually product planning, especially for a new data product, which needs to be depicted clearly through user research, competitive product analysis, etc., what is the new product and what its value is. After that, in order to complete this new product, what pace should be completed, how long should each step take, what stage goal should be achieved, and how to measure its value in the end. If it is a new feature of an existing product, you can also think about whether there is room and room for evolution of this function in the future, or is it a simple one-shot deal? Here we should also pay attention to avoid that kind of dogmatic over-planning, we must know that the future is full of variables, and product planning is just similar to life planning or career planning. Planning is just for us to have a relatively clear backbone, and we can continue to adjust and optimize in the future, rather than shackling our hands and feet
โ "Product Design - Functional Structure" After the product planning is completed, it is followed by a very realistic landing link, which needs to clarify what are the functions to be developed in the first version? One important point for data products is that for complex data products like Taobao Business Advisor, data product managers in the early days were often used to allocating functions in the same way as building a data analysis index system, and the division between different functional modules was relatively clear, but in reality they were often integrated with each other. The design of the functional structure can be more daring, with the solution of some specific problems as the starting point and the end as the beginning of the organizational function. It's really better to help users solve problems than to help users analyze problems
โ "Product Design - Interaction Logic" is one level below the functional structure, which is the interaction design of a specific functional structure interface. If it is not a data product, it can actually be handed over to the designer to play, but the data product is still slightly difficult and needs to be run in together. Because data products often involve the display and interpretation of data, especially the data visualization part, designers are good at looking at general functions and presentations from the perspective of user experience, but how to cooperate with data, especially a set of data, to present a complete information and story, still needs the help of students with professional data background
โ "Product Design - Data Model"In the above example, we have found that some data products are not simply the construction of some data indicators, but also involve relatively complex strategies, models and even algorithms. Of course, there is also a broad view, that using a set of data indicator system to portray a business is also a data model. In short, this link is unique to data products, and it is also one of the concrete manifestations of the "data" part of data products
โ "Requirements Review-Production Ratio Evaluation" Many people say that product managers and R&D love and kill each other, and it is true, but the core is what everyone is arguing about. Is it arguing about whether this thing should be done, or arguing about what to do with this thing. I think the former is more necessary, but it's not necessarily a quarrel. My relationship with R&D has always been relatively harmonious, because I am used to explaining the requirements in detail, and even I will invite front-line users and demanders to participate in the review meetings organized by me in stages. Feedback on the voices of the next line before the review, especially the recognition of the value of the product. Everyone needs to be recognized, especially R&D, they are far away from front-line needs and business for a long time, and it is easy to lose the sense of meaning of work after a long time. When we convey the needs and values clearly, many times R&D is tied to the product. In this case, the evaluation of the production ratio is very important for the sake of the effect of the data product, and the product manager can take this link as an examination of his own needs understanding and thinking, so that the value can be more and more clear
โ "Needs Review-Feasibility Assessment" After discussing what needs to be done and what is worth doing, the next step is feasibility. How to make it land, here seems to be more of the responsibility of R&D students, but the data product manager also needs to be involved in the whole process. Although some technical problems do not need to be developed and implemented by themselves, they need to grasp the direction and not deviate, so that R&D can fully understand the business scenarios behind the technical problems, so as to choose the appropriate method
โ "Requirements Review - Workload Assessment" When everyone agrees to do this, it is necessary to evaluate the workload. Sometimes there are many ways to solve a problem, there are temporary solutions and systematic solutions, but the time cost is different, and here you can make a trade-off according to the current business demand rhythm
โ "Data Experimentation - Data Preparation"For data products with complex data models, you need to prepare the data to be trained in advance, just like the process of a strategic product manager. However, even if it seems to be a simple data indicator statistics, what data are relied on behind these indicators also needs to be investigated and communicated in advance. Sometimes there is a problem with the caliber of the data, which will affect the deviation of the calculation of all subsequent indicators, which is a big matter and must be taken seriously
โ "Data Experiment-Model Construction" After you have the data, you can discuss how to implement it with data analysts and algorithm engineers according to the data model design scheme in the product design process. The details that need to be noted here are that the model should not be greedy for complexity and advanced, and deep learning is not necessarily better than statistical models, and sometimes more interpretive business models are often better. If you have time, compare the effects of multiple models, and if the difference is not large, then give priority to the solution that is easy for users to understand and has strong interpretability
โ In the initial stage of "Data Experiment - Offline Verification", in order to quickly verify the effect, we only need to do offline data experiments. However, even if the experiment is successful, the evaluation method needs to be defined at the beginning. If this link is completed, it is necessary to introduce students from the engineering side of R&D to consider how to deploy a stand-alone and offline model online. Especially for algorithmic models, the implementation of stand-alone and online versions is quite different
โ "Development Launch - Project Management" does not mean that it will be easy later, because there will be unexpected situations at any time during the development process. For example, as the R&D students find that they did not consider some problems clearly when evaluating the requirements before, the overall time needs to be delayed, which will lead to the delivery time not meeting the user's expectations, what should I do? It's either overtime or cutting demand, what else can be done, the product manager needs to make a decision immediately; Sometimes, with the development of the project, R&D students will find some blind spots that no one has considered in advance, which may be a functional design problem or a flaw in the data model. It can't be helped, sometimes it's easier to think about finding the problem in a comprehensive way. This situation should actually be celebrated, otherwise it will not be good if it is discovered by users after it is launched. At this time, it is necessary for the product manager and R&D students to cooperate to find a way to remedy this problem and add some patches to the original requirements to optimize the requirements
โ "Development Launch-Test Acceptance" is about to be completed, regardless of whether there are test students or not, the product manager needs to go into battle to check and verify in person. In particular, many data indicators and data effects in data products are very business scenarios, and simple testing and R&D students cannot judge whether the calculation results are in line with the actual situation
โ After the launch of "Development Launch-Online Evaluation", users may have various questions, and feedback will follow. Not only can you measure the effect of the product from this perspective, but you can also combine the previously formulated indicators to see if it has met expectations after a period of time. The online assessment is also the beginning of the next iteration, putting the product on the path of continuous optimization
After the summary and introduction, it is mentioned that if it is a data product at the basic layer, it may have less investment in the two links of product research and product design, and more consideration and investment at the technical level. We can roughly understand that the closer you get to the analysis/application layer, the more the corresponding data product manager needs to understand the product and the user; On the other hand, the closer you get to the acquisition/storage layer, the more technical the corresponding data product manager needs to know. However, generally speaking, the closer the data product manager is to the application layer, the closer to the business, and the stronger the sense of daily gain. This discussion can be briefly summarized in the figure below
2. What are the cool points of making data products?
Now that we have a clear idea of what a data product is, we can move on to the most relevant part of the day, talking about the cool points of being a data product manager, which is the main driving force for transforming from data analysis to data products. Of course, I won't just pick the good ones and generalize, but also talk about the restrictions in passing. Cool points can be carried out from the dimensions of salary income, actual experience, and professional life
โ Salary: As a member of the product manager, the salary of the data product manager is considered to be in the middle and upper range of the product category, after all, the ratio of supply and demand is not as exaggerated as that of ordinary C-end products. According to the salary ranking of different types of work in a general sense, R&D > product > operation > others, to compare the salary with the number of points, it depends on whether the corresponding company puts the number of points in R&D or others
โ Actual experience: The actual feeling after doing this position can be expanded from three dimensions: sense of achievement, growth and overtime intensity. Frankly speaking, many business decisions can either not rely on data (relying on insight into the industry and human nature), or can rely on more macro data (business strategy contribution, not the turn to count points), so many times counting points always has a feeling of being a tool person. Compared with this situation, data products, especially those at the application layer, will be better
In terms of achievement, at least there is something that can be seen and touched, at least knowing that someone uses it and what value it has after using it
In terms of growth, in the future, you can become a member of the B-end product family, and there will be more plays; If you are upward, you will also have the opportunity to become a business leader (at least it is rare to see a business leader with a few backgrounds)
In terms of overtime intensity, many times product managers need to be aware of the owner and need to be responsible for their own products, so it will not be much less than a few points of overtime. But the expensive overtime work is all for yourself, not like Shufen, which has to work for products and operations many times. And if the partner's R&D is strong, many technical details are taken care of, and the product manager often does not have so many shifts to add, more at the beginning and the end of the two periods
โ Career life: When we talk about career life, we are actually talking about the dependence of the position on experience and the substitutability of the people in the position. The closer the position is to the business, the easier it is to accumulate the knowledge of the industry, and then accumulate the knowledge of users from the perspective of the industry. At the same time, the more positions that do not deal with people, unless they are top-notch, they need to be beaten by the comparison of large AI models. What humans and machines can fight is more of an emotional dimension, and pure logic and rationality are not an easy path
In summary, the cool points that you can enjoy as a data product manager will include but are not limited to: higher income, better job fulfillment, growth and moderate overtime, and relatively longer career life. But all of this has restrictive conditions, that is, at the beginning, choose data products that are closer to the application layer, or the middle platform type, and try to avoid the basic layer. Many data product managers who do data acquisition and storage often joke that they are tool people, and they have to constantly connect with customers to follow up and answer many details of data access, which is far away from the final business. There is also a type of data product manager who is nailed to do data reports/kanbans every day, because they are restricted from positioning more monitoring business, so the actual work content is not much different from that of data analysts (you must know that many data analysts will also build kanban boards in their actual work)
3. Who can try it?
Okay, we've covered that much, and today I'm going to end by talking about who can try out Transformation Data Product Managers. I'll talk about my personal experience first, and then I'll talk about what I've seen, all for your reference
"Personal Experience"
I've been working for 10 years, and I did data analysis in my first year after graduating, and I felt bored about that year. From the beginning of the ambition, to the end of the fatigue. I remember that before I finally mentioned leaving, I had a communication with the leader, and I said that I felt that the things I produce every day are in the form of Excel or email replies to a few data, and there are very few PPTs that are formed. The subtext is that there is too much data extraction and monitoring, and there is little opportunity to do thematic analysis. I observed this situation at the time, and it was not something that would happen to me as a newcomer, and there were several senior analysts in the department at that time, and there were not many opportunities for thematic analysis on a daily basis. It's more about undertaking and dismantling needs, and the biggest advantage is that you don't have to do a lot of trivial and boring things
So I resolutely chose to change jobs and change jobs, and found a friend to recommend one of the BAT to make data products, and I was lucky enough to get access to data products at the application layer that can be commercialized and sold externally. When I was a data product manager at the beginning, I worked with major customers in different industries to understand their business pain points. On the one hand, we are constantly translating these problems into functional modules in data products. It was the happiest time of my long career
Looking back, the success of many people in the workplace will largely depend on luck. Many data product managers are trapped in data burying, data access, and data kanban at the beginning, resulting in limited and discounted understanding of data products. In the case of some choices, it is better to choose the widest road possible, and the future will not be so twisted
"Other People's Cases"
In addition to myself, there are also many data peers who have gradually transformed into other data positions in 3-5 years, such as strategic products, data operations, etc. Recalling the cases of switching to data products, it is more meaningful to start from internal transfers, because today's job market has rarely considered changing careers with zero experience......
A former colleague switched from technical data analysis to data warehouse governance data products, because his previous work was more about dealing with data access and post-access governance, but it was more offline and manual. When everything is familiar, change your identity and productize these key nodes online, which is not so big compared to the gap
Another former colleague has transferred from the number of business analysis to the data products at the application layer, and the general path is similar to the data analysis of the e-commerce business and the transfer to Taobao business consultant. In the early stage, many of these data products are stacked with business indicators to form kanban, and in the middle and later stages, they are more integrated and closer to marketing, so the corresponding business analysis experience gives him the opportunity to get on the bus
"Closing Recommendations"
Based on my own experience and observation cases, I personally believe that when you meet the following points, you can consider job transfer data products:
โ Desire for a sense of achievement: unwilling to be a tool person who is far away from value for a long time
โ Loves to learn about business: Interested in the complex real world and business
โ Like things that are not very logical: but not full of logical and non-emotional parts, after all, product managers need to think about people's needs
โ Irritability for more than half a year: If the first 3 are positive incentives, then this one is a negative motivation. If you've been working on your current data analytics job for half a year, it's time to see how to transform
It's just that these are all about mentality and mood, and if you really want to transform, you must also have solid basic skills, and we will talk about it later if we have the opportunity