Product R&D tells us how to logically design a usable tool, but it can't tell us if the tool is actually easy to use. For a large enterprise-level To-B product, having a product and being easy to use are two different things. The same is true for a specific CMDB product. For those involved in product development, they always have to think about: who is actually going to use it; and what are they going to use it for. But if they think more about the tool itself, problems will arise. Therefore, on the basis of respecting the commonalities, it is necessary to recognize and understand the specific needs of a certain segment of users, to reconnect with the users, to listen to their stories, to feel their difficulties, and to solve their specific problems in order to broaden the vision of product design.

In the To C market, we often hear the phrase "users vote with their feet". "Feet are an iconic representation of user experience. Where the feet are moving, users will move in that direction. In the To-B market, the feet don't move as fast. For example, the CMDB has been in use for more than a decade, and users have been "tethered" to it for more than a decade. At an internal CMDB sharing session, a colleague asked a question: "Why has CMDB come back into people's focus? What are the reasons?" This is not a difficult question to answer because there is nothing mysterious about CMDB. Even if there is now a small wave of CMDB construction, it is a natural result of normal cyclical development. "General things are considered useful by everyone, but no one finds them particularly easy to use". This sentence can be used to summarize the situation of buying commercial CMDB for construction ten years ago and using it until now.

From another perspective, when users complain that it is not easy to use, it is not necessarily not easy to use. Commercial CMDB products are designed to meet the common needs of users, and commonality should account for 80%. In China, the actual application of commercial CMDB may only account for 20% of this 80%.

We have raised the following three questions about the small wave of CMDB construction:

1. What is the purpose of the new round of CMDB construction?

2. Is the new round of CMDB construction still mainly driven by products?

3. How should the relationship between user experience, consumption scenarios and products be considered in the new round of CMDB construction?

Regarding the first question, many people have a clear idea. Even if they haven't thought it through clearly, they can just follow the trend. At least there is a purpose. Regarding the second question, I think it needs to be clearly thought through: Is moving from a commercial CMDB to an open source CMDB a reason to rebuild? Will changing the CMDB vendor solve the problem of not being able to use it well? Regarding the third question, this is actually the real pain point of this small wave of CMDB building. Those who clearly understand the relationship between user experience, usage scenarios and products are not far from creating a "useful CMDB". When I communicate with customers about CMDB, the word I hear most often is: consumption scenarios. This word has become a consensus in CMDB construction.

Then a question arises: Who sorts out and designs the consumption scenarios? Is it the vendor? Is it the customer? It could be. However, there is another group of people who are also suitable. That's right, it's the consultants! This is also the reason why customers value consulting when we discuss several CMDB projects lately. Because they have all suffered losses by going straight to CMDB products without careful selection. In the past, user experience and usage scenarios were weakened or even ignored. Relying solely on the product itself, how can it meet the expectation of being "easy to use"! The product solves the problem of whether it can be used in terms of functional logic. Whether it is easy to use needs to be designed around user experience and usage scenarios, and then perceived and recognized by customers.

In upcoming CMDB projects, we will establish a closer interactive relationship between user experience, usage scenarios, and products. By combining management requirements with the necessary technical means, we will help customers to solve the most pressing problem of using it well in a conscientious and down-to-earth way.