22 The Way of Product Design, Five Levels of DevOps Product Design #

Hello, I’m Shi Xuefeng.

In the previous lecture, we talked about the three stages of enterprise DevOps platform construction. So, what exactly makes a platform product good? I don’t know if you have thought about this question, but I have been thinking about it over the years as a product manager. It wasn’t until I heard about the five elements of user experience mentioned by Liang Ning in his column that I realized that regardless of the product, it is actually designed to solve specific problems for a group of specific people in specific scenarios.

So, back to our DevOps product, we can refer to Liang Ning’s ideas and take a look at the five levels of DevOps product design experience: strategic existence level, capability circle level, resource structure level, role framework level, and perception level.

I know all these proprietary terms can be overwhelming, but don’t worry, I will explain each one step by step.

Level One: Strategic Existence Layer #

When deciding to develop a DevOps product, the fundamental question we need to answer is: what pain points does this product solve? In other words, what do we want users to gain from this product? Clearly, the differences in target users and pain points will fundamentally result in significant gaps between two sets of DevOps products.

For example, many large companies in the industry have been deeply cultivating internal DevOps platforms for many years and have had many good practices. However, when they prepare to open these internal platforms to external users and provide them to consumer users, they would find that there are serious adaptation issues.

Sometimes, internal and external product teams have independent sets of products, and the version provided externally may even be several years behind the internal version. This is caused by the different user groups. Consumer users are relatively lightweight and mostly need specific functionalities, while internally, due to years of accumulation, there are a large number of existing processes, systems, and rules that need to be taken into account. Therefore, the entire product is heavy and even a completely closed system, making it difficult to connect with users’ existing platforms.

Therefore, I have seen many product teams that position their initial products not based on user needs, but on their competitors. In other words, they start by imitating similar products in the industry that are doing relatively well, incorporating product design, functional modules, user interaction, etc., and mindlessly reference similar products, claiming that they at least have to catch up with the industry’s mainstream level. As a result, the team is increasingly moving away from the right track.

Of course, there is nothing wrong with drawing on the advanced experiences of similar products in itself. After all, these experiences have been tested by the market and users, and the risk of deviating is relatively small. However, the problem is that the experiences of similar products cannot serve as the strategy for our own product.

Amazon’s CEO, Jeff Bezos, once said a very famous quote: “To build a strategy on unchanging things.” For example, if a competitor launches a new feature or they change their direction, should our strategy change accordingly, and continue to catch up? This is a question that product teams should deeply think about.

Taking the e-commerce industry I am in as an example, our product always emphasizes user experience, but good product design and user experience are never because competitors have made fancy changes. Instead, they always focus on those enduring things, namely more, faster, better, and cheaper. Because no matter when, users choose to shop on your platform, it certainly won’t be because your product is more expensive than others, right? The same logic applies to DevOps products.

So, is there anything that can be permanently unchanging as the strategic positioning of DevOps products? Obviously, there is, and that is: efficiency, quality, cost, and security. Ultimately, any function of a product should serve the strategy. For example, when solving the efficiency problem, the focus is on accelerating the build process, while an elastic resource pool naturally pays more attention to the cost aspect. At any time, if your product can achieve excellence in a certain aspect, congratulations, you have found the foundation of your own product.

Clarify the target users, define rigid requirements, serve typical scenarios, and ultimately excel in a certain aspect. These are the questions we need to think about first when preparing to develop a DevOps product. Regardless of whether it is an internal product or an external product, the logic is the same.

Second Level: Circle of Capabilities #

Strategy is great, but it doesn’t put food on the table. In order to achieve strategic goals, we need to do something, and that’s where the need for productization of capabilities comes in. Productization refers to the process of analyzing, designing, experimenting, and ultimately implementing a strategy or idea through a product.

Very few companies have the courage to invest in a hundred-person team to develop a DevOps product from the start. In most cases, it is usually a couple of ambitious young people who start with a simple feature. The scarcity of resources means that we are always in a state of not being able to feed enough, and at this time, the most important thing is to focus on what to do and not do.

We must be clear about what our product’s core competitiveness is and what our boundaries and bottom lines are that we will not touch at this stage. When we confine ourselves within this circle, at least in the short term, our goals can be focused.

Of course, as the value of the product is realized, resources will expand accordingly, and at that point, we can adjust and expand our circle of capabilities. But ultimately, these capabilities exist to achieve our product strategy, and we must never forget that.

Let me give you a practical example to explain this issue. When we started the continuous delivery pipeline project within the company, our small team of four people faced a collaborative development team of thousands. Within each business area, there are many product tools and platforms providing services, but what is lacking is integration between platforms.

For companies, a complete end-to-end development collaboration platform may seem ideal, but to achieve such a thing requires a huge investment and can potentially conflict with existing tool platforms, turning it into a zero-sum game.

A zero-sum game is when the sum of all players’ resources remains constant, but the way resources are allocated changes during the game.

In the current example, if the potential user base of a platform is fixed, when one side moves forward, there will inevitably be another side that moves backward. Obviously, this is not something our “small team” can achieve at this stage.

Therefore, we have defined a circle of capabilities for our product, and its boundary is not to replace existing tool platforms, but rather to focus on bridging the gaps. In doing so, existing platforms can still provide services independently, and they can also be integrated with our platform through standardized plugins, making our platform an additional entry point, which contributes to the expansion of our user base.

For us, the injection of these platform capabilities also extends the outer edge of our circle of capabilities, and users of these existing platforms become our potential user base. This win-win model has proven to be effective, and the platform has achieved great success.

When exchanging product ideas with many friends, I always mention the theory of the main channel and moat. The so-called main channel is the core competency of the product, directly reflecting the specific implementation of the product strategy. For a pipeline product, this capability comes from covering the software delivery process, and regardless of any future products you develop, this main path is unavoidable. This provides an environment and soil for the product to thrive. And the moat is the irreplaceability of your product, or the high cost that needs to be paid to replace your product.

Let’s go back to the example of the pipeline product. Our moat comes from the accumulation of user data on the one hand, and on the other hand, from the integration of these external capabilities. You see, as more platforms are integrated, our product’s moat becomes harder to overcome, considering the long-term perspective of the circle of capabilities.

Level Three: Resource Structure #

After addressing the questions of “why” and “what to do,” we now need to evaluate our own advantages in terms of resources.

Resources, as mentioned earlier, are always scarce, but this is fair for everyone. Therefore, the ability to integrate and mobilize resources becomes a core competitive advantage. When you have no competitors, it is not difficult for users to choose your product because you have solved a pain point problem and there are no better options.

However, in reality, both internally and externally, we are surrounded by a competitive environment. At the beginning, the ability to attract users may seem ridiculous, but most of the time it relies on users taking advantage of your resources that they do not possess.

For example, for a long time, building and packaging an app was done on a local computer, which comes with risks. But there were no better options. Especially when facing a closed ecosystem like iOS, virtualization and dynamic implementation is not an easy task and may even violate Apple’s rules and boundaries.

At this point, if your product applies for a batch of servers and deploys them in a standardized manner in a production data center, these resources become one of the core capabilities of the product.

As more and more users come to take advantage of these resources, the product’s ability to integrate large-scale resources will continue to improve, thereby further reducing the average usage cost. This creates a positive feedback loop.

Apart from the tangible machines, the resources contained in a product can also include many other aspects. For example, hard strengths such as speed, number of machines, and rich accumulation of technology in a single field. There are also mandatory elements such as approval channels, security rules, and soft factors like user habits and data accumulation.

For internal DevOps products, there is another crucial resource, which is leadership support. We have discussed this in depth in the 6th article of this column, so I won’t go into detail again.

Fourth Level: Role Framework Level #

When users start using your product, don’t forget that they are here to solve problems, and behind each problem is a scenario and the user’s role in that scenario. It is meaningless to discuss the problem without considering the context and role of the user.

Therefore, we always say that we need to look at the problem from the user’s perspective, solve their problem in their current scenario, rather than observing from a distance or taking a God’s eye view of the whole situation.

For example, when you and other departments are arguing fiercely over the design of a feature and it almost turns into a real-life showdown, and then your leader walks into the meeting room, guess what happens? The tension is instantly relieved, as if nothing happened just now. Is it because we have strong emotional management skills? Actually, no. This is mainly because the context we are in has changed, and our role has also changed.

Another example is in product development. When we are developing a pipeline product, we provide a branch parameter functionality to meet the needs of different branch building tasks. However, when collecting feedback, all we receive is negative voices. Does this mean it’s a “pseudo-requirement”?

Actually, it’s not. Through actual data, we can see that many users have already started using this feature. Isn’t this taking advantage and being clever? The problem lies in the fact that we did not think about this problem from the user’s role framework at that time.

Because the branch functionality requires manual input from the user, but the branch name is long and prone to errors, and the user has to copy and paste it from another system or locally every time. When this scenario occurs once, it’s not a big deal, but if each person has to do it dozens of times every day, it becomes a big problem. The solution is actually very simple, just add a history information or automatic association feature.

So you see, sometimes we don’t need great creativity and disruption, micro-innovations based on the core scenario can also have a positive effect.

In the end, it can be summarized in one sentence: Don’t design your product only for professionals to use.

To accommodate flexibility, many products provide a lot of configurations, but for the current scenario, most of these configurations are not important. Products should provide abstraction to shield many details, instead of exposing too many details, and even a good product itself serves as a user manual. In the current era of scarce attention, the importance of this cannot be ignored.

Fifth Level: Perception Layer #

Now, let’s take a look at the last level: the perception layer, which is the closest level to the user.

There’s no denying that we live in an era where appearance matters. However, products are ultimately meant to be used by people, not just seen by them. Therefore, many people even emphasize that for internal products, UI is not important at all, as long as the product does its job.

However, let’s think from a different perspective: do you want to interact with a product every day that is poorly designed and lacks any aesthetic sense?

The answer is most likely no. But for many DevOps product managers, this is the most difficult aspect. This is because no one is inherently a DevOps product manager; many people come from a different background, such as development, testing, or even being a boss.

Having non-professionals do professional work, as expected, often results in product designs that can be described as “anti-human”.

Regarding this level, I have two suggestions:

1. Communicate more with front-end engineers. Nowadays, front-end frameworks are very mature, and based on templates, we can quickly build a platform. Moreover, the framework of the template itself contains many design ideas.

2. Learn some basic design principles. You can refer to the design philosophy section on the Element official website. It discusses four aspects: consistency, feedback, efficiency, and controllability, each of which involves many details. By referring to mature products and comparing them with these basic design principles, you can be assured that you will make rapid progress.

Summary #

Today, we introduced five levels of DevOps product design, including: strategic existence level, capability circle level, resource structure level, role framework level, and perception level. In fact, when users complain about your product or when the product fails to improve, we may need to calm down and compare these five levels to see where the problem lies.

Thought-provoking Question #

Have you ever used any great DevOps products? What features of these products impressed you and made you want to give them a thumbs up?

Feel free to share your thoughts and answers in the comments section. Let’s discuss and learn together. If you find this article helpful, please feel free to share it with your friends.