Whether a platform is mature or not has many considerations, such as whether the platform is stable, whether it is easy to expand, and whether it can support complex business well. In my opinion, to judge whether the platform supports the business well, in addition to the above points, it also depends on whether it supports the new small business well.
For a rapidly developing industry, innovative businesses are released every year or even every month. If the entry threshold of the platform is high, each innovative business needs to spend a lot of time in research and development, integration, and debugging to run on the platform, and it is likely to lose a valuable window of opportunity.
The platform can not only support mature businesses, but also support the rapid trial of new small businesses
New small businesses have a law of growth. In the early stage of business model verification, the required gameplay is relatively simple, and it is hoped that rapid trial can be released frequently. Let's take the e-commerce field as an example. Under the mature e-commerce system, there are many complex and huge platforms, such as trading platforms, commodity platforms, and marketing platforms. Although these platforms support various business models and gameplay well, for new small businesses, these models and gameplay are not applicable in the early stage. They hope that the platform can make some tailoring according to their own requirements.
Let's take the business of "auto finance" as an example. In the months of trial and error of the initial concept, this business does not need to provide coupons, nor does it involve the process of physical logistics and delivery, nor does it involve gold standard-related assets. content. Instead of following the platform’s weekly release rhythm, he wants to be able to iterate quickly and self-publish early on. But this very reasonable requirement is difficult to meet on the early trading platforms:
- The order placement process of the early trading platforms was hard-coded. The whole process, no matter what business, must be connected with the preferential system, logistics system, card and coupon platform and other systems. When developing a new business, it is necessary to ensure that the integration of the entire order placing process with these services will not cause call exceptions. Once an exception occurs, it is necessary to coordinate with the relevant system to see how to shield the error.
- The commodity unit price calculation logic is not well decoupled in the platform, nor does it provide an extensible mechanism. The unit price of the auto finance business comes from a micro-loan system. In the end, this business can only be hard-coded, where the platform calculates the unit price of goods, and mixes it with other business codes to write related calculation logic. Because this part of the code may affect other businesses, before the code is released online, it must undergo strict network-wide regression verification to ensure that it will not affect other businesses or cause capital losses.
- Therefore, the release rhythm of the auto finance business must also follow the rhythm of the platform version, and can only be released after patiently waiting for the weekly network-wide regression verification, and cannot be released at any time according to one's own wishes.
The technical staff of the auto finance business team do not know the implementation details of each platform. They believe that these platforms are mature and powerful. These requirements should be very simple, and they should be integrated and released in a week or two. But in the end, after repeated communication between the business and the platform team, clarification of requirements, and evaluation of the plan, it was discovered that the functions that were thought to be supported by "as a matter of course" were originally uncertain or unsupported. The plan has also changed from the previous one or two weeks to at least three months, and the workload has also changed from the previous 2 person weeks to 4 person months, and the delivery time promised in the previous business is also imminent...
Such stories are repeated every day. How can the platform not become a bottleneck supporting the business team? The key lies in:
- Whether the capabilities of the platform can be externalized and exposed, business teams in various industries can clearly know what capabilities the platform has;
- Whether the external scalability provided by the platform is sufficient, and the business team can customize business logic in a self-service and non-intrusive manner
- The business logic customized by each industry cannot affect each other, and the business customization of each industry can be released independently and independently;
The platform needs to support the business in a reusable mode and help the development of the business
Story 1: A product and platform conversation about business needs
An e-commerce platform currently supports a large number of vertical industries. These industries have roughly the same main transaction process, but have their own industry characteristics in some branch scenarios. There was once an industry where products communicated with platform designers to see if the platform could meet business demands.
Platform: "What do you want to do in your business? What functions do you need? What specific scenarios and constraints are there?"
Business: "Well, our business is nothing special. Our business scenarios and rules are basically the same as XX supermarket business, but there are some differences in these places...blablabla..."
platform:"......"
The above dialogue scenario occurs frequently between the business team and the platform team. When the students on the platform further asked: "Which scenarios are the same between you and the XX supermarket business?" When this question is asked, the business team often does not know what the "XX supermarket" business is.
Platform: "This section of XX supermarket has customized business logic, do you also need it?".
Business: "Well, I'm not sure about this business logic, so I shouldn't need it."
The business team in this industry only sees that XX supermarket has a certain degree of business similarity with them, but they only understand some external performances of XX supermarket's business model and business scenarios.
Story 2: The process from a demand analysis to the launch
When I first joined the trading platform, I was in charge of a demand called the second-stage logistics of Village Amoy. This demand roughly refers to the delivery of orders that some courier companies could not deliver to the village before, to the village Taoist station in the county, and then the village Taoist partner in the village Taoist station is responsible for secondary distribution, including the delivery of the village to the village. , At the same time, the partner of Village Tao will charge a fee for the second delivery as a commission. This requirement differs from the previous transaction fulfillment process in these ways:
- The logistics distribution is divided into two stages, the first stage is the courier company responsible for the distribution, and the second stage is the village Tao partner responsible for the distribution;
- The total logistics cost consists of two parts, one part is paid to the courier company, and the other part is paid to the village Taoist partner;
- Once the Village Tao partner starts to deliver, the delivery service has already taken effect, and the delivery fee will be charged to the Village Tao partner. If there is a return or exchange of goods in the later stage, the partner of Village Tao will not refund the delivery fee that has been incurred;
- ……
This requirement is indeed not very complicated. I followed my senior brother from the trading team to participate in the requirement review meeting and the technical solution review meeting. After introducing the business requirements of the product, my brother thought for a while, and mentioned that this requirement is very similar to the requirement for "freight insurance" that he had done before. For example, the fee is divided into two, and once the service is performed, it will not be refunded; the fee is two different payees, and so on. Then, the conclusion of the technical solution is that the requirement refers to the technical solution of the previous "freight insurance" requirement.
The product is very happy, my boss is very happy, and I am also very happy. After all, a very similar requirement has already been done, which is definitely technically feasible, and it can also be used for reference. It seems that this requirement can be solved in a week.
After returning to my seat, I began to inquire how the previous requirement of "freight insurance" was designed and implemented. Suddenly, I found that the main designer who had done the "freight insurance" before had retired from the arena. There are not many other colleagues who have participated in this requirement before and do not know much about the details. The last suggestion you can give me is "search for the word insurance and see where the code has this keyword". In the end, it turned out that this trick was not very effective. In the transaction order system, I found more than 2,000 places with this keyword. After inspection, I found that most of them have nothing to do with "freight insurance". Moreover, some services that supported "freight insurance" at that time have been restructured and taken offline and replaced by another service/system.
In the end, I can only honestly return to the original business requirements, start to do scene analysis, start to design the main entity objects, analyze the processing sequence, and define the main upstream and downstream services and related interface parameters. It was estimated that the demand to be completed in a week was finally completed by two people for more than a month.
Stories like this happen every day. For example, a pre-sale game has been made in China, and the international team also hopes to introduce pre-sale on its own platform. In the end, it was found that there is no other package that has been formed, has nothing to do with the industry, and is highly abstracted and reusable. There are only some original requirements description documents that can be used for reference, and based on these original requirements documents, analysis, design, coding, and testing are done again.
Therefore, how the platform can accumulate assets that can be quickly reused at the scene level is the key to helping new small businesses go online quickly and agilely!
For information on how to precipitate scene-level reusable assets based on Lattice, see: UseCase Precipitation and Reuse
中文版：https://www.ryu.xin/2021/07/22/lattice-small-biz-support/
Top comments (0)