I used to be a mobile Internet entrepreneur, and now I am doing venture capital investment in the software field. I often encounter a problem at work: how to measure the technical threshold of a product. I have abstracted a methodology for measuring technical thresholds. This framework is most applicable to software products, and this is the area I am most familiar with. But this thinking framework is also partially applicable to hardware products such as chips, medical equipment, consumer electronics, and robots.
First, give a definition to the technical threshold. If a competitor wants to make a product that is exactly the same as ours, what employees he needs to hire; what difficulties he needs to overcome, what pits to step on, and what work to do; how much money and time is needed to build the product. The process of replicating a product usually reflects the technical threshold of a product.
This is of course a narrow definition of the technical threshold. Because the opponent may not necessarily bring the exact same product experience after re-engraving all the technical aspects of the product. In addition to technical aspects, product experience often has many other determinants: data precipitation in the product, data improvements to algorithms and models, such as short video recommendations, you may not be as accurate as headlines; the process of using the product by a large number of users For example, a re-enacted QQ, but there is no way to cold start without user use and social relations in the early stage; the influence of brand and price on user mentality, such as the effect of famous teachers in education products, will be better for paid conversions. Will allow users to recognize the effect of education more. These factors are undoubtedly the company's competition threshold, and even in the long run it is more important than the pure technical threshold of core competitiveness. But this article will focus more on the purely technical threshold itself, which is the most important step for many startups from 0 to 1.
The technical threshold of most products consists of three aspects: System Design, Engineering and Know-how.
System design refers to the architecture design of the system and the macro-technical decisions in it. Software system design is an abstraction of complex things, and better design represents a more beautiful product experience and faster product development. For example, if we want to design a SaaS product for medical clinical trials, we need to abstract all participants, all processes, and all policies in the entire clinical trial to form a system model and a data model. This kind of system design requires the designer to have a good understanding of the industry and the meaning behind various requirements, as well as the designer's very experience in system design. A good system design can adapt to more needs, and can also be expanded more easily in the later stage.
Complex system design usually takes many factors into consideration and trade off. It is often said that there is no perfect system, because many factors hold back each other, and satisfying A will sacrifice B. Therefore, the biggest test of the architecture design is to deal with many mutually restrictive factors at the same time. It is a very vivid metaphor to press the gourd to start a dipper; the second is to have a deep understanding and anticipation of product requirements. The product must define the most important usage scenarios, and the important scenarios are the first to be satisfied when designing the system. At the same time, the product designer must also consider the possible future development direction of the product, and put the scalability into the consideration of the system design in advance. System design and product design are completed simultaneously, find suitable product positioning, what to do and what not to do, and what changes will happen to the market in the future. All the best system designers usually need to work with the product manager who understands and anticipates the needs best, or the two are simply combined.
The threshold for project realization first comes from the workload in the project, which is man-months in software engineering terms. For example, very complex software such as Office, DingTalk, and databases require a large team of engineers to develop for a long time. The second is the scarcity of engineers needed for software development. The realization of complex systems and algorithms often requires very skilled engineers, and it is not just a matter of recruiting engineers to be competent.
Know-how refers to algorithms, know-how, and industry insights. The Know-how threshold is essentially the scarcity of cognition. Cognitive scarcity is often the characteristic of a thing when it emerges, for example: new AI algorithms, new operation and maintenance methods. When new technologies first appeared, relatively few people had mastered them, so they had a high threshold for cognition. Such cognitive scarcity often has a time window. As time goes by, cognition will spread from the best technical team to a wider group of people. For example, deep learning was very scarce before 2015. After 2020, it has even begun to be surplus in first-tier companies, but it is still scarce in second- and third-tier companies and traditional industries.
There are many skill fields in software development, and some technical fields are rarely mastered by engineers. This is also a kind of know-how. Generally, the closer the software to the bottom layer and the hardware, the more scarce its engineers. For example, compilers, operating system kernels, graphics and images are relatively specialized fields, and engineers with these skills are very scarce in the market. A software project that requires scarce technical capabilities obviously has a higher threshold.
Among various software products, Infrastructure software is a kind of high-threshold software that I like very much. Because they are often very complex systems, such as storage systems and databases. These systems involve many complex algorithms and mechanisms, both algorithmic know-how and system design thresholds. The core system of many basic software does not require a particularly large technical team in the early stage, but requires early members to have a high technical level. Even in large companies, it is difficult to use large teams and large budgets to accelerate the core R&D of basic software. Therefore, if a start-up company can gather around ten high-level engineers, it will basically compete on an equal footing with large companies in software core research and development.
Some software closer to the hardware has a high threshold. For example, the software in the smart network card, because FPGA talents are relatively scarce, there are very few talents who have worked as network cards.
The industry application of SaaS also has a considerable technical threshold. The industry SaaS design needs to combine industry know-how to do a very good system design. In addition, many industry designs have very rich functions, which are also the accumulation of the workload of engineering realization.
The above is my thinking framework for measuring the technical threshold of software products. There will definitely be shortcomings. Welcome to exchange and discuss.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。