Special Delivery Four, How the Jenkins Product Manager Designs the Product #

Hello, I am Shi Xuefeng. This is a special broadcast that has been added temporarily.

A few days ago, I attended the 2019 DevOps World | Jenkins World conference in Lisbon, Portugal. This annual community gathering lasted for three days and consisted of intensive communication and exchanges about Jenkins and DevOps. There was a tremendous amount of information shared at the conference, including new technologies, industry trends, and product design ideas, which I found very valuable and worth sharing with you.

2019 marks the 15th anniversary of Jenkins. For any software, 15 years is not a short period of time. At this milestone, the community reflected on the development history of Jenkins over the past 15 years and envisioned the changes that Jenkins will undergo in the next 15 years.

It can be said that from the perspective of DevOps products, Jenkins itself is an outstanding case study.

Initially, Jenkins was a personal project developed by its founder KK because he couldn’t tolerate his colleagues causing compilation failures every day. Until today, this project has had nearly 900 full-time or part-time contributors, over 260,000 Master nodes, and more than 30 million tasks. These numbers are just a part of what the official statistics could measure. If we also include instances within corporate Intranets and personal computers, the numbers would be countless.

This year, what impressed me the most was that during the main conference, Jenkins founder KK didn’t talk much about product details, design ideas, or future directions. Instead, he spent just over 10 minutes reviewing his own journey. At the end of his speech, he handed the stage over to a Jenkins Product Manager. So, who is this Product Manager? And why did a Product Manager give this presentation? This piqued my curiosity greatly.

KK has always been regarded as the top Product Manager for Jenkins. Indeed, it is quite common for technical experts to also work as Product Managers. This is because DevOps products have several distinct characteristics compared to typical user-facing products.

• High technical background requirements: DevOps products need to solve many frontline technical problems.
• Targeted users are developers: This means that if you don’t understand the real working methods of developers, it is difficult to design developer-friendly products.
• Multiple professional tools: The components and tools used by the product are specialized, such as Jenkins, which is a typical continuous integration system. Without understanding Jenkins, how can you design Jenkins?

During the conference, I had a special conversation with this magical Jenkins Product Manager to discuss the challenges faced by DevOps Product Managers. His name is Jeremy Hartley, a big brother from the Netherlands.

First, let me explain how the community operates. For example, for the Jenkins product, its main contributors come from CloudBees. Although these individuals belong to the same company, in reality, most of them work remotely from home and rarely have the chance to meet in person.

For instance, Product Manager Jeremy is in the Netherlands, founder KK is in California, Infrastructure Lead Oliver is in Belgium, and the maintainer of the K8S plugin is in Spain. Therefore, the annual FOSDEM (the largest European open source software conference in early year) and the Jenkins World conference at the end of the year have become rare opportunities for these developers from around the world to come together.

Returning to the topic, Jeremy is different from the typical image of a proactive and talkative Product Manager. He could be described as an anomaly. From beginning to end, he gives people a gentle impression. Even during public speeches, his tone is very calm, not showing much emotional expression, and he simply tells his and his product’s story.

Jeremy previously worked for an Internet video company for 10 years. Half-jokingly, he said that even after working for 10 years, it is not as well-known as collaborating on a project with Tencent. Later, he joined XebiaLabs, a company specialized in DevOps platform products, which may not be particularly well-known in China, but if you have heard of the DevOps Tools Periodic Table, you have undoubtedly heard of this company as they continuously update it.

Image source: https://xebialabs.com/periodic-table-of-devops-tools/

In April of this year, he joined CloudBees as a Senior Product Manager responsible for the open-source and commercial versions of Jenkins. I was deeply impressed by the part of our conversation regarding the role of a Product Manager. I have summarized some key points to share with you. If you are already a DevOps Product Manager or aspire to become one, you must take a serious look at them.

1. Self-subversion #

What is self-subversion? Let me give you an example. For example, Blue Ocean, the user interface project of Jenkins, which many people should be familiar with, has now ceased its main development. The community will still fix bugs and security vulnerabilities and accept PRs from developers, but there will no longer be dedicated engineers working on development, and new requirements are indefinitely on hold.

In fact, it’s not just Blue Ocean. Projects that shone at last year’s Jenkins conference, such as Five super power, Jolt in Jenkins, and Evergreen, are also in a semi-terminated and deferred development state due to changes in direction and personnel. So why is there such a disruptive change in such a short period of time? I threw this question to Jeremy.

His view is that these projects are not meaningless, but they have indeed not met the original expectations of the projects. For product managers, managing expectations is a very important skill. When the requirements come to the product manager, deciding which ones to do and which ones not to do is often a question. The team often negotiates and selects the most promising projects, but this does not mean that these projects are destined to succeed. On the contrary, many ideas will only be known if they are viable or if users actually embrace them. If there are limited use cases and no good growth potential, it is actually a good choice to stop it in a timely manner.

At the beginning of the creation of the Blue Ocean project, it can be said that it was a refreshing and highly anticipated project, and even at one point was considered the biggest feature of version 2.0 alongside Jenkins pipeline. However, after a few years, due to various reasons such as product performance and plugin extension support, there were not many opportunities for large-scale adoption in enterprises. Because the project did not meet expectations, the product team decided to stop it.

But at the same time, a brand-new Jenkins user interface project has already been put on the schedule. This new user interface borrows heavily from the design concepts of Blue Ocean and eventually replaces the existing Blue Ocean through a new set of user interfaces. I think it is this constant self-subversion that keeps a 15-year-old software always vibrant and innovative.

2. Simplify Complexity #

For products like Jenkins, many plugins are developed by developers. However, developers often tend to pursue comprehensive functionality, which can be seen from the design of many plugins.

Developers list all functions in front of users without filtering, which is naturally easy for them. However, for ordinary users, when they first see this complex product, their willingness to use it will be greatly reduced.

In addition, when faced with so many plugins, on the surface, users seem to have many choices, but some plugins have similar names, and you don’t know which one to use. Or, some plugins are suitable for the current version of Jenkins, but once Jenkins is upgraded, they cannot be used properly. However, users do not know whether they are compatible before the upgrade, and often discover the problem only after the upgrade is completed, and can only roll back to a previous version. Similar issues with plugin usage create significant barriers for users.

When discussing this issue, Jeremy also believes that the system being too complex is contrary to the initial intention of product design, but as an open platform, they cannot restrict the behavior of developers. Therefore, a method is needed to balance the comprehensiveness and ease of use of the functionality.

For example, when reconsidering the Jenkins plugin ecosystem, on one hand, the product team will provide official plugin support for new business scenarios. For example, in the cloud-native development scenario, by deep cooperation with cloud service providers, more official plugins will be provided to meet the typical usage scenarios of cloud service providers. Whether it’s for Amazon AWS, Microsoft Azure, or future mainstream cloud service providers in China, they will collaborate in this way. Whether you are using open-source products or commercial products, you can benefit from this project.

On the other hand, the product team will further categorize the existing 1600+ plugins and include some of them under CloudBees’ guarantee project. This means that CloudBees will ensure the compatibility and availability of these plugins. For professional users, they can still freely choose and develop plugins in their own ways, but for ordinary users, the plugins recommended by the official team are sufficient.

Usability of the product is reflected in various aspects of product design, not just plugins. Any issues that block users from using the product should be prioritized for resolution.

For example, for a product that has been around for more than a decade, the accumulated number of documents is huge, and many times, users cannot find truly useful information. Therefore, the Jenkins product team has launched a documentation governance project, where they will reorganize all the documents and migrate them to the GitHub platform. In addition, they will also consolidate best practices in conjunction with new product features. For example, for pipeline usage, the official team has summarized many best practices for beginners to refer to. You can learn them in conjunction with the content of the previous two lectures.

Always remember not to make your product usable only by experts. Simplifying complex problems is a question that product managers should always consider.

III. Step Back #

Most DevOps product managers have a technical background, so they tend to dive into the details right away, even into the implementation details.

Jeremy, who was also a programmer, had been doing frontend development for a long time. When I asked him, “How should a good product balance the user’s perspective and the implementation perspective?” his answer was to step back as much as possible to look at the problem.

By stepping back, he meant not just focusing on the surface of the problem, but trying to stand on the side and examine the problem from a third-party perspective.

He gave an example of Jenkins’ pipeline-as-code. In practical use, the pipeline file often contains a large amount of code. Sometimes, the pipeline code can even be thousands of lines long. The more code there is, the more unstable the system becomes, and the more difficult it is to test. At the same time, according to the current running mechanism, much of the code runs on the master node, which puts a lot of pressure on the cluster’s master node.

To solve this problem, from an implementation perspective, the idea is to provide a standardized and structured syntax format, which is the declarative pipeline syntax. This reduces the difficulty of writing pipelines, reduces the amount of pipeline code, and makes the code structure clearer. However, these optimizations still cannot solve the problem of excessive pressure on the cluster’s master node, which means that only part of the problem has been addressed.

Taking a step back, a new perspective is needed to improve the overall isolation of the pipeline. Therefore, the product team is currently designing a new pipeline component called “building block.”

The term “building block” refers to a whole block of code snippets rather than individual instructions. These building blocks, when combined, can solve a specific problem for a particular scenario. For example, in the scenario of Maven package building, building blocks can help solve a series of problems such as environment, tools, and build commands. These building blocks run code as subnodes, reducing the difficulty of writing pipelines and alleviating the pressure on the master node. For users, using building blocks is also simpler; they can directly execute them as custom steps.

For product managers, finding solutions and solving problems is naturally their responsibility. However, at the same time, they often need to maintain both user thinking and implementation thinking. Being able to freely switch between these two types of thinking is a sign of a mature product manager.

Summary #

Speaking of that, let me answer the initial question, that is, “Why is it the product manager who shares the product plan?” This is because, no matter how big or small a product is to be developed, there needs to be a group of people who can take a step back, find the real problems of the users, simplify them, implement this functionality, and constantly challenge themselves, continuously refine and improve. This is crucial for any product that aims to solve problems for more people.

Reflection and Discussion #

Is there anything else you would like to know about the Jenkins World conference? Feel free to ask questions, and I will be more than happy to provide answers.

If you found this article helpful, please feel free to share it with your friends.