How do you incubate a product from a project?

An important source of revenue for G-end products is to incubate products through customized projects, then package them and sell them to a second customer. So how to incubate a product from a project? The author summarizes the relevant content, hoping to inspire you.

One of the important sources of G-end products is to incubate products through customized projects, package them and then sell them to second and third customers.

As the saying goes: in a TO G project, if you haven't done a pre-sales product, you are often not a good project manager.

Especially when encountering in-depth business problems that need to be explained to Party A, the product needs to be unshirkable; when the project schedule is seriously compressed and there are problems with the progress of personnel tasks, the product manager must have no hesitation; when there is no clue about the hardware selection of the integrated list, even if the product is full of righteous indignation, it is still necessary to go; when the project matters are messy and fighting fires everywhere, the leader has to let you consider the productization of the project and launch nine major products for sales training as soon as possible.

Oh my God, is the product manager an "ancient beast" with three heads and six arms?

If an enterprise wants to develop and an individual wants to raise his salary, he has to "change the wheel on the high speed" (there is no time to stop), "eat what is in the bowl, think about the pot, look at the field" (do the project, think about the product, look at the sales order).

Someone is going to say, how can so many things be done and done well?

What I understand: There are many things, either they can't sort it out and can't see clearly, or they have poor ability and slow work, or they don't have enough money and play tricks.

Without further ado, I'm going to talk about how to make a product out of a project.

1. Why do you want to incubate products from the project?

The underlying logic of TOG industry projects: policy brings political performance, and political performance gives birth to policy.

The core influencing factor of G-end customers to do projects is political performance, which comes from catering to policy needs on the one hand, and creating policy ideas on the other hand.

Where there is a policy document, there is a product opportunity hidden behind it, which is determined by the characteristics of the G-end industry.

However, in the "virgin land" where there is no policy document, if you want to grow a product, in most cases, it comes from the thoughtfulness, reform and innovation, and whimsical ideas of a few customers. So, the project is the second shortcut to the product opportunity. (The first is policy interpretation)

From the perspective of enterprises, the project system will also reduce the R&D risk of enterprises.

The characteristics of G-end products are: it is a linear growth, it is difficult to break out on a large scale in a short period of time, even if there are construction projects required by policies, it may take three years and five years for organs at all levels across the country to complete the construction. In this way, for the enterprise, the return cycle is too long, if you take the liberty of making an investment in the direction of a product in the early stage, it is likely that you will not catch anything, and you will go straight to the water.

From the perspective of a product manager, the G-end market belongs to a specific field, and if you have not worked in this industry, you will not be able to find the way at all, and you will not be able to think of what customers need.

Therefore, the product opportunities that are "patted on the head" by the product manager or analyzed through online information are in most cases a life-and-death situation.

To put it simply, incubating products from the project is another low-cost and high-survival product strategy in addition to "policy-oriented" in the G-end market.

2. What is the difficulty in incubating products from the project?

1. The threshold for obtaining effective demand from customers is high

First of all, the entry threshold of our industry is very high, and you can't ask people everywhere like you can do C-end products, and you can empathize with them. You have to go to the front line to meet customers one by one in order to get the customer's demand information.

Secondly, you go to meet customers with sales, and many customers don't have the leisure to talk about your needs at all, and they come up to talk about the products you want to sell to him, and want to get some valuable demand information from his mouth, no way. Even if there is, it may be that you have said a bunch of "right" nonsense, mentioning some "tricycle to heaven" needs, and you have a deep sense of powerlessness.

Finally, the product users in the G-end industry are not decision-makers, and this alone has halved the success rate of our customer demand research. The ideas of the leaders and the needs of the grassroots personnel may be completely different, and the products you make from the research needs of the grassroots users cannot impress the leaders who can make purchasing decisions, and in the end it is a bamboo basket for nothing.

2. There are few customers who are willing to polish products together

The project incubates products, not only the direction can be completed, it does not mean that if you find a customer to do the project, you will definitely be able to incubate the product, this idea is to young to simple.

Finding target customers who are willing to work with you to polish your products is the key to making products.

Some customized projects are completely wishful thinking on the part of the leader, and the director or staff member of the business department who is responsible for the needs of you is forced to take up his post, either you are right about everything and you can do anything, or this has to be decided by the leader, and the leader can do it. In this case, it is difficult for you to get the real pain points of customers, and you will not be able to sort out the complete needs of the product from 0~1.

Only the project that can be used by the first target customer has the opportunity to be productized, if a project is completed and the press conference is opened, the press release is issued, and no one opens the system, do you think there will be a second customer who will rush to open another press conference with no new ideas to buy this product?

Therefore, if you encounter a customer who is really rushing to solve the problem and intends to use it, you must cherish it. This will be a very high-quality customer resource.

3. There are big differences in the needs of G-end users

When it comes to G-end customers, it is definitely Party A of Party A, and we have to obediently follow the needs they propose.

Therefore, it is sometimes difficult for product managers to verify whether the requirement is a customer's individual requirement or a generic requirement. If the customized needs of a few customers are productized, it is easy to lead to too many functions and bloated shapes of the product.

What about the customers? This project has to be built with a lot of money, all the functions have to be available, and it has to be different from others.

I want to do all the needs I can think of, I want to want it, I want it, the money can't be spent in vain, and if I do more, I feel that it is worth it, and even earned. At the same time, we have to make flowers, for the sake of differentiation and differentiation, we must make something different, or the leader thinks that this project is copied from what others have done, so what do you have to do, how to publicize.

In addition, the country is so large, and the economic environment, policy environment, and market environment are also different from place to place, and the idea of making local characteristics will directly kill what you have productized on other local projects.

4. Product manager is not competent and has cognitive limitations

Although a reproducible project is the basis of productization, it is not easy to turn a project into a product, and what is the most important determining factor?

When you are in charge of a custom project, you are the project manager. What is the project manager more concerned about? It's more about the balance between schedule, cost, quality, and resources.

To incubate a product from a project, you become a product manager, and you have to consider the abstraction of the general requirements of the product, the expansion of various functions, and the design of interactive experiences.

It's completely a matter of two directions, and it's easy to cut out and mess up when stuffed into your head.

Secondly, when we do the project, the first thing to do is to do the research and combing of the project requirements. This process is a great test of the product manager's ability, and each function is actually a mapping of the corresponding business scenario.

If the product manager's understanding of the customer's needs is skewed due to personal ability, the information collection in the demand research stage is incomplete, and the analysis and understanding are not thorough. Then, the final project is either not intended to be used by the customer at all, or it has to face frequent changes after the launch.

Without a deep understanding of the industry and a thorough analysis of the business requirements, the product manager will not be able to discern which requirements are the main tasks and which are only side tasks.

Lack of productization capabilities: often passively accept needs, will not reject and guide customer needs, lack of awareness and forward-looking functional planning, and repeated changes after the project is launched.

3. The key three steps of how to commercialize the project

First of all, it is important to clarify the goal of productization: productization is not the ultimate goal, but to improve the rapid delivery ability of the project through productization. So as to reduce the cost of the project and improve the profitability of the enterprise.

Productization is not a technical problem, but a complex management problem.

The process of productization is actually to obtain the maximum project benefit with the minimum input cost. We don't necessarily have to redesign and develop a new product or reinvent the wheel, that's something that only big companies and big platforms do. All we need to do is think about how to reduce the cost of the next project from the project.

1. Refine core functions and verify value points

If you want your product to be attractive, you must first figure out what your customers really want.

It's like looking for a thread in a mess, you have to pull out the common requirements in different projects, analyze and analyze them, and find out the most eye-catching "thread" - that is, the core function of the product.

For the product, ten chicken rib functions are not as good as one core function.

On the contrary, the chicken rib function increases the complexity of the product, making the system more fragile, and once some small functions are abnormal, it may lead to the collapse of the product's reputation in the hearts of customers. There is time to do ten chicken rib functions, it is better to make one more really valuable function.

How to verify this core function? It's very simple, you can ask customers to verify, if this product has only one function, which one do you need the most? If this product only retains this one function, will you pay for it?

Judging whether a customized demand is the demand of most customers and identifying universal needs is an important ability for product managers, which requires the precipitation of industry experience and continuous thinking and summary.

If the customized needs of a small number of customers are productized, it will lead to a bunch of pseudo-demand functions piled up in the product, which will not arouse the interest of customers and waste a lot of time and energy.

2. Minimum feasibility design to speed up the iteration cycle

There is a big difference between TO G products and other products, and there is a big difference in customer needs.

Because of the different needs of customers at different levels and the different cognition of needs, there will be great differences in the understanding of users with different functions for the same function. For example, what leaders want to see is data analysis, and data can be filled in by hand, while grassroots users are concerned about not increasing their workload, and it is best not to fill in too many things.

Therefore, after the TOG product or project is launched for the first time, customers will ask a series of questions.

Therefore, ToG products or projects are very suitable for MVP (Minimum Viable Product) design ideas, and the first product online version only needs to be complete in the core business process and business modules. Adopt a small version for multiple iterations, test with customers for an extended cycle, continue to solicit opinions, and discuss repeatedly so that the final product is likely to win customer satisfaction.

The world's martial arts are only fast and unbreakable, and productized cultivation requires rapid iteration as the driving force. Making a product can't be implemented in a one-stop process of requirements, design, development, testing, and deployment like a project. This approach is inherently contrary to agile product development.

Two of the most important concepts in the idea of product iteration are periodicity and completeness.

• Periodicity requires that on the premise of clarifying the overall goal of the product, the product goal should be decomposed, and the design, development, testing, and deployment should be carried out according to a certain cycle. Feedback is collected through debriefings and used as part of the next phase of product optimization.
• Completeness requires that each iteration of the product report is based on a complete process, that is, we are required to quickly build a complete product skeleton, and constantly improve the function on this basis, so as to avoid falling into various details of the design as soon as it comes up.

3. Project-based products first, market-oriented products later

In our entire product planning and evolution, we should not put too much emphasis on product standardization and blindly reject new customization needs.

This is especially true when the market is not very stable in the direction of existing products, and once too much emphasis is placed on productization, then more market opportunities will be missed. However, it is not possible to ignore the product at all, which often becomes a project implementation team, and cannot effectively accumulate products and expand on a large scale.

There are only two purposes for making products, one is to support the landing of more projects, and the other is to support the rapid delivery of projects. Simply put, it's about increasing revenue and reducing costs. Therefore, the products we make can be simply divided into project-based products and market-oriented products.

It is difficult for G-end customers to deal with the past with a set of standard products, and there will be a large number of needs that are not covered by your products in the project. What customers need is a complete solution, not a single-point weapon, so it is also necessary to integrate the functional points of other manufacturers' products or create project-based products.

Project-based products are not the main products, do not have to invest too many resources, and continue to improve with the project, but with it, you can easily cover customer needs, and evolve our standard market-oriented products in the process of landing multiple projects.

Project-based products and market-based products are the products of time stages, and the two will also transform each other due to changes in the environment.

When a project-based product shows great market potential, we can increase investment and transform it into a market-based product, and conversely, if a market-based product encounters a sales bottleneck or decreased competitiveness, we can also adjust the strategy in time and downgrade it to a project-based product to find new market opportunities.

Final words

Incubate the product from the project, and support the project from the product.

The boundaries between products and projects are not static, we always strive for the smallest cost of project delivery, and the same is true for the goal of making products. So, don't mind if you're a product manager or a project manager, the role is a title in itself and shouldn't be an obstacle to creating value in your work.

A qualified G-end product manager must have the ability to launch products from the project and complete the whole process of products from 0~1.

Author: Wu Lin, To G Enterprise Product Director

This article was originally published by @武林 in Everyone is a product manager, and it is forbidden to reprint without the permission of the author.

Image from Unsplash, based on the CC0 license.

The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.