For most SaaS companies, the degree of product standardization determines the life or death of the enterprise. Today, we will look at how to do standardized design for SaaS from 0 to 1 from the perspective of a product manager.
Due to limited space, this article will not elaborate on basic skills such as how to draw flowcharts and how to make prototypes, but will focus on explaining the key points of achieving SaaS standardized design.To make it easier for everyone to understand, this article will use a case as a thread to demonstrate step by step how to design a SaaS product from 0 to 1.
01 Differences Between SaaS and Self-Use Systems
Although both are B-end products, the differences between SaaS and self-developed systems are very obvious.Fundamentally speaking, SaaS products need to serve many enterprises: as few as dozens, and as many as tens of thousands. Therefore, the inclusiveness of the business needs to be very strong. The cost is that product iteration speed is relatively slow.Because a self-developed system serves only one enterprise, it emphasizes close service, so the requirements for product inclusiveness are relatively low, but it strongly emphasizes iteration speed.Although the logic of SaaS and self-developed products is similar, there are certain differences in the requirements for product manager capabilities.For details, please refer to the figure below:Internal B-end product managers are more of an auxiliary role. Therefore, they place more emphasis on deep participation in and support of the business, and achieve company goals by coordinating and even driving business departments.SaaS product managers are different. Because they are responsible for commercialized products, which are the core link for the company to achieve revenue and profitability, they place more emphasis on the product's own architectural capabilities and design capabilities.Personally, I believe that one important criterion for measuring the quality of a SaaS product manager is: as the number of users continues to increase, will product functions be overturned or substantially modified, that is, can more additions be made and fewer subtractions and changes be made.02 The Significance of StandardizationProduct standardization is crucial to SaaS companies.I once heard a regional director of a well-known SaaS company say that a million-level project was negotiated very well, and it was agreed to be delivered and launched in 4 months.But by the 3rd month, the client demanded a complete redo, requiring development to be redone according to the client's actual business. This sales director complained: "Everything was discussed so well earlier, we were going to use a standardized product. But in the later stages of the project, the client said the product couldn't meet business needs. I really don't understand."This isa typical case of product capability being unable to support sales capability. If there are many such projects, it will be very difficult for the SaaS company to be profitable.Specifically, SaaS standardization has the following three important significances:The largest cost investment for a SaaS company is R&D cost. If every project is delivered through configuration, this meansthat as the number of users increases, R&D costs will be gradually diluted, ultimately forming economies of scale. Therefore, standardization is one of the keys to profitability for SaaS companies.2. Accumulate best practicesWhat B-end clients truly want to buy is "industry best practices."Even if a SaaS company has rich industry experience and understands the business strategies and execution plans of industry benchmarks, if the SaaS product cannot reflect and support these "best practices," then the cost of promotion and execution will be very high.So-called standardization is actuallydistilling the solutions of leading enterprises and then solidifying them into the system. These solidified solutions are the soul of the SaaS system。3. Accumulate product capabilityIf SaaS companies rely on operations rather than products to ensure "customer success," then the value of both the product and the product manager will be greatly diminished.Standardization will continuously enhance the product's configuration capabilities, making the product increasingly heavy and its value higher and higher. Only a heavy B-end product can temper and reflect the product capabilities of a product manager.
03 Standardization StrategyThe standardization strategy is an important component of the SaaS product strategy. The complete SaaS product strategy will not be elaborated here; interested readers can follow the official account: ToB老人家, and read the article "SaaS from 0 to 1, Product Strategy Determines Success or Failure."
The SaaS standardization strategy can be divided into three parts, namely:
1. Product version standardization strategyThe most important strategy for standardization is to determine "which customers' needs are not met."The traditional software era of "one product conquers the world" has passed. Even if we want to capture multiple market segments, we must carefully judge whether to meet all customers' needs through "one industry version."For example, in the fast-moving consumer goods industry, the management models of distributors and manufacturers differ considerably. For distributors, the management of organization and permissions is relatively simple, and does not involve strict external account management; while brand owners have complex multi-organization management needs, including the management of external organizations and accounts.For another example, the pricing system of distributors is relatively simple; customers of different levels may have corresponding price lists, and some customers will sign specific price agreements; but the pricing system of brand owners is much more complex, as different branches, different regions, and different business district levels all affect the specific price. This is because the "price structure" is the lifeline of brand owners, so fine-grained control is necessary.Differences in needs between FMCG distributors and brand ownersOf course, this is not to say that we absolutely cannot meet the needs of multiple industries in one version. The past success of SAP and Oracle has already proven that this can be achieved.However, what SaaS prides itself on is a sufficiently "highly available" system. An overly bloated product will greatly increase customers' usage costs.Conversely, "one version meets all needs" is of course incorrect. But if versions are blindly expanded horizontally, it will also bring a heavy R&D burden to the SaaS company.For example, when we face customers in the "over-the-counter drugs" industry, is it necessary to divide out a version? Although it is not the fast-moving consumer goods industry, "over-the-counter drugs" is learning from the distribution model of the fast-moving consumer goods industry. In this case, if what we provide is a distribution SaaS product, then for the time being there is no need to separately divide out an industry version for "over-the-counter drugs."2. Functional layer standardization strategyThe second most important standardization strategy is deciding "which functions should not be standardized."For most SaaS, more than 90% of functions can be standardized at the product level, but perhaps 10% of functions are difficult to standardize. It is also very important to distinguish clearly which functions can be "standardized at the product level."For example, small and medium-sized enterprises have relatively simple reporting needs, so reporting functions are relatively easy to standardize; but for tens-of-billions-level enterprises, reporting is a highly complex and non-negotiable need, so for SaaS companies that do not yet have BI or PaaS products, temporary customization is also a feasible option.3. Development layer standardization strategyFor functions that cannot be "standardized at the functional layer," we need to find a way to standardize them at the development layer,that is, what we usually call PaaS, now popularly called "low-code."Low-code is a very "ancient" thing. When I was still at Oracle, I frequently used Oracle's low-code capabilities—we also called it personalization. Through it, we could change field attributes and also embed SQL or even packages.In other words, even traditional software capable of flexible secondary development relies heavily on low-code. Not to mention SaaS companies, for which secondary development is relatively difficult.Therefore, if a SaaS company is determined to grow big, PaaS capability is not an optional topic, but a mandatory one.However, building a self-developed PaaS platform is indeed an expensive undertaking, and not all SaaS startups can easily afford it. The good news is that China's SaaS is entering the platform era, and the gradually enhanced low-code capabilities of DingTalk and WeCom are expected to help SaaS companies achieve "PaaS freedom" at low cost.04 Difficulties in standardization designCompared with self-developed systems, the design of SaaS products relies more on long-term planning. This is the core of SaaS design and also the difficulty of SaaS design.Emphasis on long-term planning is mainly due to two reasons.1. Control development costsBecause standardization emphasizes configuration capability, the development effort required for the same feature may be several times that of a self-developed system.Once a poorly designed feature is developed, it can cause astonishing waste of development resources.2. Facilitates continuous iterationMore importantly, as a "public product," SaaS must maintain simplicity: if the system is filled with a bunch of useless features, and a few enterprises insist on using them, it will hinder system iteration. Readers can think about this: when planned new features conflict with these useless features, how should the product manager handle it?Therefore, good SaaS design is to do as much "addition" as possible, and avoid "subtraction" and "modification."Of course, standardized design also has requirements for the product manager themselves. I often use the analogy thatso-called standardized design is like placing pieces on a chessboard: the chessboard is the architectural capability the product manager possesses, and the pieces are the specific requirements. Without the chessboard, it is impossible to place the pieces correctly.
05 Standardized Design StepsFrom the design process perspective, standardized design can follow these four steps:1. Strategy layer sortingSo-called strategy layer sorting is to sort out the business from a relatively macro level. Specifically, it includes the following steps:1.1 Clarify the business scopeAn enterprise's business can be divided into front-office, middle-office, and back-office business. Front-office business includes mall apps, etc., middle-office business includes CRM, order management, logistics management, etc., and back-office business includes HR, finance, etc.We first need to clarify,which part of the business requirements the first version of the SaaS product is mainly meant to satisfy. Only after defining the boundaries can we match the company's strategy and resources.A well-known FMCG manufacturer approached a SaaS company (referred to as Company A), hoping to develop a mobile APP for managing sales personnel. After communication, SaaS product manager Xiao Li realized that the client's needs were actually distribution management, including sales order management, sales personnel management, and store management, etc.Although Company A had a distribution management system serving FMCG 'distributors', it had long struggled to enter the more profitable and more stable-revenue FMCG 'brand owners' market. This was a very good opportunity.1.2 Sort out business strategiesThe so-called business strategy is essentially the company's playbook. For example, in offline distribution business, does the user enterprise adopt deep distribution? Or does it also have direct sales? Only by understanding the client's business strategy can we clarify the approach to product R&D.In addition, we must understand that SaaS is used by many clients in an industry. Therefore, we also need to sort out the business strategies of the industry in which the enterprise operates. In this way, on the one hand, we canmatch the client's business strategy to the industry's business strategies, making it easier for us to grasp the essence and ensure the product's generality; on the other hand, we can also consider future expansion directions comprehensively and lay a good architectural foundation in advance.For example, common strategies in FMCG offline distribution include large-scale wholesale, multi-level distribution, deep distribution, direct sales, vehicle sales, etc., and deep distribution is further divided into manufacturer coverage mode and distributor coverage mode. As a product manager, it is necessary to comprehensively sort out these models in order to be fully confident during product design.After communicating with the client, Xiao Li found that this FMCG manufacturer mainly adopted three business strategies: large-scale wholesale, direct sales, and deep distribution. These are relatively classic playbooks in the industry, so these three distribution models could be developed first, while also taking into account future expansion to multi-level distribution and vehicle sales.Large-scale wholesale is when the manufacturer sells goods to wholesalers, who then carry out secondary distribution. Although the large-scale wholesale model is a relatively extensive distribution method, when the manufacturer's management capability is insufficient, adopting the large-scale wholesale model can achieve rapid distribution, so it is still a common distribution model.About 40% of sales in the FMCG industry are completed through modern trade channels represented by large supermarkets. These large supermarkets are often regional chains or even national chains, and can establish brand image, but the entry threshold is high and the negotiation process is complex. Therefore, FMCG manufacturers often cooperate with them directly.Deep distribution is an important direction for FMCG distribution. Companies implementing deep distribution usually already have a certain scale and management capability. They divide regions, designate distributors for exclusive operation, and emphasize terminal store coverage rate, display, and new product penetration rate, etc.For companies, deep distribution can maximize the potential of terminal stores, increase sales of new products and high-margin goods, and effectively block competitors. Therefore, this model has always been a key distribution model for large FMCG companies such as Yili, Master Kong, and Coca-Cola.1.3 Sort out business difficultiesCompared with traditional software, SaaS is a latecomer.According to the product replacement formula: new product value > old product value + replacement cost, customers will only consider purchasing if SaaS provides greater value. To put it another way,even without competing traditional software, SaaS must solve "problems that could not be solved before" in order to gain a firm foothold in fierce competition.Therefore,sorting out business difficulties clearly and understanding "why customers choose us" is very important work, allowing us to concentrate resources on the most critical functions.rather than dispersing resources to build functions that customers are willing to use but that do not constitute a "differentiated competitive advantage."After communicating with the customer, Xiao Li learned that the customer had actually already spent millions to implement a CRM system from a well-known international brand, but the mobile user experience was very poor. In addition to not being highly usable and requiring repeated training to get started, the low operating efficiency and slow response speed also made system promotion very difficult.The reason the customer chose Company A to develop the distribution system was that after experiencing Company A's mobile product, they believed the product's user experience was excellent and could solve the biggest problem in promoting the current system.After learning the customer's demands, Xiao Li realized: for this SaaS system aimed at FMCG manufacturers, the design focus should be on the mobile end.The FMCG industry generally has the problem of low education levels among sales staff and difficult management. If the mobile end can greatly improve employee efficiency and reduce the difficulty of employee use, then this SaaS product will be hugely attractive to FMCG brand owners.2. Business layer analysisFor business layer analysis, the most effective approach is to draw a business flowchart.The key point of the flowchart is that the product manager must help the client clarify the business and requirements, avoiding confusion and omissions. The key to achieving this is that the product manager must have certain architectural capabilities, that is, know how a typical process should flow.If it is SaaS for large clients, then it is recommended to stay at the client site for a period of time. Large clients have relatively detailed requirements, and on-site communication can improve communication efficiency.If it is SaaS for small clients, then it is recommended that you first find a few seed users and, through the flowchart, ensure that version 1.0 is an MVP (minimum viable product) they can accept.The details of drawing flowcharts are basic skills, so they will not be elaborated here. Below is a flowchart I once drew for everyone's reference.At first, the FMCG company thought its requirements were very simple, mainly that sales personnel enter sales orders on the mobile end, and then transmit them in real time to the existing ERP system through an interface, as shown below:Xiao Li did not rush to draw a conclusion, but drew a typical distribution management process on the blackboard, and then sorted it out one by one according to the process steps, as shown below:After sorting it out, Xiao Li quickly discovered that for large clients such as regional chain stores, the manufacturer adopted a direct sales strategy in which manufacturer salespeople visit and the factory ships directly; for small clients such as non-chain convenience stores, it adopted a deep distribution strategy in which manufacturer salespeople visit and distributors ship. Therefore, the client actually had two different sales management processes, as shown below:Once the process was clarified, the design approach also became clear. At the same time, Xiao Li's professional requirements analysis method was also recognized by the client, and the client's leader expressed an intention to cooperate on the spot.3. Multi-organization architecture designThe development of enterprise business is based on mutual collaboration and mutual supervision among multiple departments.When users use the SaaS system, process flow and data security must comply with the enterprise's requirements for collaboration and control.This requires us to design the organization, role, and permission functions well. Among these, the most difficult is multi-organization architecture design.For example, a beverage company, in order to expand its sales scale, established branch companies in City A and City B, each responsible for production and sales in a major region. To facilitate management and motivate the branch teams, the company decided that the two branches would independently account for profits and distribute dividends based on the profits achieved.To support the independent accounting of the two branches and prevent data leakage, the beverage company's IT team decided to establish a "profit center organization" for each of the two branches. Under the "profit center organization," corresponding "roles" were established, and corresponding "functions" such as sales orders, shipping functions, etc., were assigned. Finally, the corresponding "roles" were assigned to the employees of the two branches respectively.In this way, the revenue and profit data generated by the sales orders created by employees of Company A will all be counted under Company A. Moreover, data such as sales orders, revenue, and profits can only be viewed by employees of Company A. The same applies to Company B.The multi-organization architecture actually reflects the division of responsibilities, rights, and interests within an enterprise, and determines the strategies for inter-organizational collaboration and risk control. As an enterprise grows larger, its organizational structure becomes more complex, and its control requirements become higher. Therefore, the more a SaaS product targets large enterprises, the more attention it needs to pay to the design of multi-organization architecture.Of course, if it is a SaaS product targeting small enterprises, the multi-organization architecture is relatively simple; everyone just needs to design role and permission management well.Regarding the detailed content of multi-organization architecture design, I have specially written an article. Everyone can follow the official account: ToB Laorenjia, and read "Essential for B-end Senior PMs: Multi-Organization Architecture Design."Xiao Li discovered through analysis that the customer has 2 independently accounted business departments, and each business department has several distributors under it. For directly operated KA stores, only the corresponding business department can manage data and handle business; for convenience stores managed by distributors, only the corresponding distributor can manage data and handle business. At the same time, the business department to which the distributor belongs also has management rights over the data related to these convenience stores.Xiao Li designed the "profit center" organization type and created two profit center organizations: Jiangdong Business Department and Jiangnan Business Department. Distributor A, Distributor B, and KA Store C all belong to the customer (with different customer types). A "belonging organization" field was added to the customer information, and through this field, these 3 "customer records" were all assigned to Jiangdong Business Department. In this way, only personnel from Jiangdong Business Department can see their records and business data.For convenience stores a, b, c, and d, they are associated with the corresponding distributors in a similar way, ensuring the isolation of business information between distributors.4. Product Function DesignAs the main body of SaaS design, product function design can be divided into application architecture design and detailed function design.4.1 Application Architecture DesignThe so-called application architecture design is the overall structure diagram of each system application.Compared with self-developed products,The application architecture design of SaaS is more critical. A reasonable application architecture can reduce functional duplication, avoid data chaos, and lower the difficulty of system expansion. Once functional modules are built on an unreasonable application architecture and a certain number of enterprise customers are acquired, the cost of modification becomes very high.Relatively speaking, the error correction cost of self-developed products is much lower. After all, only one enterprise is using it, and as long as it is negotiated with the business department, it is not impossible to overturn and rebuild.For product managers, the focus of application architecture design should be achieving low coupling and high reuse.So-called low coupling means dividing functions into multiple system applications according to business relevance.System applications interact through APIs. In this way, the upgrade of a single application has much less impact on other applications, thereby improving the agility of the system. For example, sales order management, warehouse management, and CRM can be independent applications and assigned to different teams when necessary.So-called high reuse means extracting the functions shared by various modules and forming them into a separate system application.In this way, on the one hand, it ensures consistency of information sources; on the other hand, it simplifies the system and avoids duplicate development. For example, customer information is used in system applications such as sales order management, CRM, and TMS (transportation management), so it is necessary to make it an independent application.Although there is no standard answer for application architecture design, in fact, whether it is a traditional Oracle ERP system or the emerging major e-commerce and SaaS systems, there are very mature application architecture designs. Studying competitors more and making appropriate adjustments based on actual conditions is a good method for application architecture design.Considering that Company A already has an independent customer information system and also a mature product management system, Xiao Li decided to directly reuse these systems. To meet the needs of brand owners, Xiao Li added some new functions, such as business district management and price strategy management.In fact, in reusing the customer information management and product management modules, Xiao Li also had a long-term consideration, namely that in the future the brand owner version and the distributor version may be connected to form a transactional SaaS product. If the two versions share one set of basic data functions, it will facilitate future data integration and process integration.SaaS detailed function design greatly tests a product manager's system experience.In terms of design process, SaaS function design also follows the general B-end product design process, as shown in the figure below:However, the SaaS system faces the specific needs of multiple enterprises, and these specific needs always appear to be vastly different; what is more difficult is that product managers cannot determine what kind of enterprises they will face in the future, and therefore cannot predict all requirements.In this case, product managers may face various awkward situations, such as:
Feature upgrades require major modifications to existing features, and developers complain
Feature upgrades change the original experience, and customers complain
After the feature goes live, no one uses it, and the team complains
After the feature goes live, customers say the requirements have changed, and all kinds of people complain
ThereforeDetailed SaaS feature design greatly tests a product manager's planning and deep thinking abilities.Specifically, SaaS product managers need to do the following well:1) Long-term planning, cautious designA SaaS from 0 to 1 often starts from the needs of a small group of customers.When the number of customers is small and there are not many features, product design lacks constraints and can easily grow wildly.For example, buy-one-get-one-free is a commonly used promotional method in the consumer goods industry. In some cases, gifts need to be associated with the main product, such as buying 5 large bottles of cola and getting 1 small bottle of cola free. For design and operational convenience, the product manager may choose to directly add fields on the order line to reflect the gift name and quantity.This design may not cause problems when facing simple requirements. But once more complex situations are encountered, such as 1) needing to manage gift shipment; 2) buy 5 get 2, buying 5 large bottles of cola and getting 2 types of gifts; 3) needing to integrate with an ERP system, etc., problems will arise.The correct approach is to place both the main product and the gift in independent order lines, with the same fields, and use the "gift" field to identify whether the order line is a gift (checked means it is a gift).Therefore,As a SaaS product manager, one cannot only focus on the immediate requirements, but should take a long-term view and consider things as comprehensively as possible.In addition, a SaaS product manager must admit: even with a full understanding of all requirements, we still cannot determine the priority of all requirements.Therefore, in general, product managers can only select the most valuable requirements to satisfy first. Moreover, every design should be an MVP, so as to avoid prematurely developing features that are not needed for the time being.This is the principle of cautious design in SaaS.2） Deep thinking, the spirit of getting to the bottom of thingsThe cost of correcting errors in SaaS design is far higher than that of self-developed products.However, SaaS product managers are often relatively far from customers and it is not easy for them to deeply participate in customers' daily operations.Relatively speaking, in the project-based model of the traditional software era, requirements designers could be stationed at a customer site for months to conduct requirements research and system development; while product managers of self-developed products are almost always communicating with the business side every day.The R&D teams of SaaS companies are large, and it is impossible to station them all at customer sites, so product managers often need to balance both ends: they must thoroughly understand customer requirements and also do a good job in design so that R&D can work smoothly.In this situation,SaaS product managers must possess the "spirit of getting to the bottom of things": getting to the bottom of every customer requirement and investigating its essence.I have always adhered to one principle: always believe that a customer has a pain point, but never believe that a customer has a correct answer. I also give this principle to everyone.3) Survey competing products and grapple with detailsWhy can SaaS seize the market of traditional software? The most important reason is not that SaaS is cheaper, but that SaaS was born with mobile and social attributes.However, mobile design is several times more difficult than PC design. The reason is not only that phone screens are smaller, but also that mobile operations take place outdoors, the scenarios are more complex, and the requirements for experience and efficiency are also higher.For example, in the fast-moving consumer goods van sales business, to complete a day's visit tasks, the average time a salesperson can spend visiting a customer must not exceed 5 minutes. To save time, the salesperson needs to unload goods while using a mobile phone to place orders. Therefore, the 'enter sales order' page must be simple and efficient enough.For example, when entering the product quantity, you can directly enter multi-unit quantities (without selecting a unit), such as '1 box/3 bottles'. And allow the quantity to be increased or decreased through plus and minus signs.In this way, when the salesperson unloads 1 box and 3 bottles of yogurt (assuming 1 box of yogurt has 9 bottles), he does not need to calculate '1 box and 3 bottles equals 12 bottles' before entering it into the system. This can greatly improve the salesperson's operational efficiency.To do a good job in SaaS interaction design, in addition to fully communicating and discussing with UE colleagues, it is more important to research and learn from competitors.As the saying goes, among any three people walking, one can be my teacher, let alone when we are designing SaaS from 0 to 1?
When designing reports, the customer had several core statistical reports that had been used for 5 years, and the customer's leadership hoped that the new reports would still follow the previous statistical logic.However, after careful analysis, Xiao Li found that the previous logic was not optimal.Because the customer's departments and personnel are adjusted every year, and the original report calculated sales performance based on the 'order-personnel-department' correspondence. This led to an unfair performance basis when comparing the same period, because the historical year and the latest year were not on a fair footing.For example, last year's Department A had 10 people and managed area a; this year's Department A has 20 people and manages area b. If you simply compare last year's Department A performance with this year's Department A performance, it is actually unfair.Xiao Li communicated with the customer's project leader. Since this customer is one of the top companies in the fast-moving consumer goods industry, and the project leader was also a fairly confident leader, Xiao Li's suggestion did not receive much attention at first.But Xiao Li persisted in communicating with the customer, pointing out that 'under the distribution model, only convenience stores and the corresponding regions are relatively stable. Therefore, we should compare the performance of area c, which Department A is responsible for this year, with the performance of area c last year. Only then is it truly fair.'
In the end, the customer's leader was persuaded by Xiao Li, and he praised Xiao Li in front of everyone. With the cooperation of the customer's leader, the project progressed very smoothly and was eventually successfully launched. Xiao Li also used this project to complete the SaaS from 0 to 1. Soon after, he sold this SaaS product to other major customers, helping the company successfully achieve a breakthrough in the major customer market.
The design of SaaS products places great emphasis on the product manager's architectural ability.Regarding how to cultivate architectural capabilities, everyone can follow the official account: ToB Laorenjia, read the article "My Practice: How to Improve B2B Product Architecture Capabilities".If I were to summarize this article in one sentence, it would be: Draw the chessboard well, place the chess pieces well.Wishing everyone, design a SaaS product that changes the world.
