How to save a SaaS product that is unsustainable

[[355134]]

I have briefly mentioned this topic before, and today I will discuss it in more depth with you. At present, most SaaS companies in China are driven by sales and customer demand. It is difficult to refuse customized development, and it is easy to complete the project. Unless there is a team with strong product power and business insight to do it, otherwise after a few years of accumulation, the product will become bloated.

Once a product becomes bloated, it will encounter many problems:

• Maintenance costs are getting higher
• User experience is getting worse
• The accumulated customers have turned from resources into ropes, and the difficulty and workload of adjustments are increasing.

In this case, it is very passive to deal with the competition from some new market players. Moreover, if the experience is poor, customers will gradually leave, and the team is powerless to do anything about it, thus falling into a dilemma. This is also the current situation of most B-end product companies in China.

Should we refactor the existing product or start from scratch to develop a new one? At this time, the company faces a difficult decision. Basically, all R&D teams will suggest starting from scratch. From the perspective of R&D, this is a simpler and more efficient way. We don’t have to worry about the original disgusting code, and the team morale will be higher. However, from the perspective of the company, several factors need to be considered:

The development cost and development cycle of the new system.

It takes a fairly long time for a new system to go from development to online use by a small number of customers and then to maturity and stability.

Migration costs for old customers.

This cost includes the BD, implementation, training, and after-sales costs invested in the migration process, as well as the costs invested by the customer.

During the parallel period, some bugs or requirements are involved, which requires development costs on both sides.

We need two teams to deal with different product lines, including development, implementation, training, and after-sales. This makes recruitment, training, and expansion more difficult. In addition, the products between the two product lines are highly coupled, which requires a lot of communication work.

Generally speaking, the migration cost of B-end products is extremely high, and the cost for customers to change their usage habits is also extremely high. In addition, there are always some customers who are unwilling to migrate, and the inevitable outcome is to maintain two systems for a long time. It is difficult for people who have not experienced it to imagine such a price and cost. Migrating old customers will be a lot of work for them; if you don’t migrate old customers, they will be neglected and hurt to a certain extent, which will affect your reputation.

Unless there are very few customers, or the entire migration can be basically guaranteed to be relatively low-cost, I strongly recommend not starting from scratch to develop a new set. The cost is extremely high. In addition to multiplying all costs by 2, there are also migration costs and customer costs. The migration and implementation of each customer may be a complex project.

Therefore, the cost of developing a new product is definitely exponentially higher than rebuilding the existing product. After many companies choose this option, they are not satisfied with the new product and cannot migrate the old product, wasting a lot of time and resources. I have rarely found successful cases.

So if we need to reconstruct a system in a very simple way, how should we do it? I think we can refer to the following ideas and principles:

1: Be prepared to be a good person.

As I mentioned in a previous article, people are the most critical factor in the success of things. To do a good job of butchering a cow, several roles are very important, including database architect, solution architect, and functional architect. Not every role requires a person, but someone must take on the corresponding role. For example, the database is the cornerstone of B-side products. Once an error occurs, the cost of adjustment is very high. The database architect needs to be one or more people who understand database design technology, have a good understanding of business development and business details, and have a forward-looking attitude to collaborate. The solution architect actually needs to be one or more people who understand the business and have an understanding of technology.

B-end products are an interdisciplinary subject. It is relatively easy to find people who understand both business and technology. It is more difficult to find people who understand both business and technology and can combine them organically. Such people are currently a scarce resource in China. Generally speaking, in such interdisciplinary subjects, it is easier for technical people to learn business than for business people to learn technology. The company should select the right people to train in this direction.

If it is difficult to find the right person in a short period of time, it is best to have an external consultant to conduct a certain degree of review.

2: Roughly design the ideal product form.

To determine the path of product reconstruction, it is necessary to design the final general architecture of the product, mainly the functional architecture and system architecture, and determine some core business design ideas and principles. Only by repeatedly polishing can a more satisfactory answer be obtained. Only when you know what the end point is, can you think about the best path forward.

3: Choose the refactoring priorities carefully.

For product reconstruction, the choice of path and priority is extremely important. Finding the most reasonable and labor-saving path is a great test for the team. It is difficult to have a fixed answer here, but there are some principles to follow:

Prioritize foundational core architecture adjustments.

The core of refactoring is to make the database architecture, product function architecture, and page architecture correct. Whether it is the database, function, or page architecture, it is actually about finding the most reasonable way, that is, finding a balance between user experience and product growth. Generally speaking, it is best for users to see enough content they care about with enough pages, but the product is growing, and if the architecture classification is not well divided, the functions or pages will be very crowded and cannot be expanded, so it is necessary to find the best balance between experience and growth.

Some core database tables and core functional architectures need to be adjusted as a priority. Any work done on the wrong database or wrong functional architecture will be useless and you have to start over again.

Prioritize the reconstruction of core or particularly bad functions

Some frequently used core modules or particularly poor functions should be refactored first. This type of reconstruction is of the greatest value to users, and customers have sufficient motivation to cooperate.

Prioritize the reconstruction of modules with high new demand.

Products are not static. When we are refactoring products, we will definitely face a large number of external demands that continue to pour in. For functional modules with many new demands, it is better to start over rather than spending a lot of time on the wrong functional foundation to meet new demands. In fact, the so-called refactoring often involves rewriting modules and functions one by one, breaking down major risks using agile and butchering methods.

4: Pursue excellence and don’t repeat the same mistakes. Every opportunity to reconstruct is an opportunity for rebirth.

Needless to say, every time you refactor a module, it is a chance for rebirth. We cannot use one pit to fill another pit. We must at least achieve a design score of 85 or above before we start, and don't blindly pursue speed.

5: Do your best to subtract. Every successful subtraction is a victory.

When refactoring a bloated system, you must do everything you can to reduce it during the refactoring and rewriting process. You can reduce modules, functions, and even the display of a field or a search condition to the extreme. Good refactoring must be accompanied by a lot of reduction.

From the customer's perspective, each upgrade after reconstruction is a torture for those who are already familiar with the historical system. If the torture is repeated too many times, customers will easily become frustrated. From the perspective of user experience and word of mouth, the following suggestions are made on the iteration arrangement:

1: Each iteration and upgrade allows customers to continue to enjoy sweet benefits.

For each iteration and upgrade, the reconstructed new version experience must be much better than the original version, or have new features that can solve customer pain points, so that users will be motivated to upgrade. When designing and arranging each iteration plan, you must fully consider the motivation of users to upgrade, otherwise you will encounter a lot of resistance.

2: During the migration and upgrade process, we try to make it unaware to the customers and require no training, thus reducing their investment costs.

The upgrade after each reconstruction is often accompanied by data migration. This burden should not be placed on the customer. The implementation team will help the customer complete it. In addition, the functions after each reconstruction should basically require no training, and the customer basically does not need to invest in implementation training costs.

3: Carry out grayscale testing to confirm that the new function is feasible before launching a full release.

Each major refactoring requires a certain period of grayscale testing, allowing some typical customers to use the refactored modules first to ensure that there are no problems before full release, so as to minimize customer troubles. Each trouble will lead to distrust and subsequent non-cooperation, and the product reputation will deteriorate.

4: Only necessary functions are opened to new customers to reduce the cost of subsequent migration.

This is a small tip. For some non-essential functions in old products that are not well done, during the reconstruction process, they should not be opened to the increasing number of new customers through permission processing, so as to avoid increasing the migration cost later.

Reconstruction is difficult; simplicity is difficult; life is difficult; but most people can only find inner calm and live a simple life after experiencing enough problems.