06 Lean Startup: What Should You Do When Product Managers Are Unreliable? #

Hello, I’m Zheng Ye.

Earlier, when we discussed acceptance criteria, we were actually talking about deterministic requirements, meaning we already know how to implement these requirements and just need to make them happen. However, sometimes we are faced with uncertain requirements. For example, when a product manager has a new idea, how should we respond?

Today, let’s start with a very classic topic in the IT industry: How programmers should deal with product managers. Let me first tell you a story that happened around me.

Once, a large group of us were in a conference room conducting a product design review. Many people from the product team and the technology team were involved in this review. A product manager was standing in front of his design draft, explaining a new product feature to everyone.

The company was planning to turn its services into a cloud service, allowing third-party vendors to apply. The product manager was explaining the process of how third-party vendors could apply to open the service. After hearing the introduction to the basic situation, I raised my hand and asked a few questions.

Me: How many people will use this service?
Product Manager: This is for third-party vendors to use.
Me: I’m asking how many people will use this service.
Product Manager: Each third-party vendor applicant will use it.
Me: Okay, so how many third-party vendors are you expecting to apply?
Product Manager: Um, we haven’t really thought about that.
Me: Alright, now what is the specific process for opening the service for third-party vendors?
Product Manager: Third-party vendors apply, then we open it from our side.
Me: Okay, in this process, what are the current difficulties? Can this approval process simplify our work?
Product Manager: …
Me: Let me tell you, the most difficult part of opening the service for third-party vendors is the subsequent configuration part, which involves configuring service information and network information. Currently, this part has not been well automated. The previous approval part can be automated, but its impact on optimizing the entire process is minimal.

After I finished asking my questions, it seemed like the members of the development team understood something and expressed their agreement one after another. The product design of this approval process itself was not the problem, but our time and resources were limited. The key issue was whether or not to do this at this time. More accurately, it was a matter of priority.

At this moment, as a member of the development team, you may feel a sense of satisfaction in pushing back against the product manager, which is quite refreshing. Well, as a serious column, we do not intend to escalate conflicts between product managers and development teams. Instead, we want to explore what is the reasonable approach to doing things.

The reason why we were able to reject the inappropriate requirements of the product manager is because we asked some good questions, but more importantly, we asked these questions for a reason.

Product Manager is a New Profession #

Before further discussion, we must recognize a sad reality, most professionals in the IT industry are not competent enough.

The IT industry is a rapidly developing industry with countless opportunities. Compared to other industries, salaries in this industry are higher, which has driven a large number of people to enter this field.

Because it is a rapidly evolving industry, many positions have emerged recently. For example, before 2010, there were few dedicated front-end engineers, and engineers at that time often had to cover both front-end and back-end.

Product Manager is a position that emerged with the wave of entrepreneurship. Since this is a “new” profession, there are often no industry standards to speak of. Therefore, you will see many industry problems: many people want to enter the IT industry, but find that programming requires coding skills, so they start with Product Manager positions! These people understand the responsibilities of a Product Manager as simply telling programmers what to do.

This is similar to the idea that a layperson can understand Cross-talk as mentioned by Guo Degang. They think that knowing how to speak means they can perform Cross-talk, but they don’t realize that this is a highly skilled profession. Product Managers are the same, without good logical reasoning skills, how can they have good development in this industry?

If the Product Manager you encounter can provide a coherent logic, then congratulations, you have encountered a decent Product Manager. I’ll add that there are also many programmers in this industry who lack professionalism, even more than Product Managers, and the reason is simple: there are more programmers than Product Managers.

Saying this is not to criticize any profession, but to tell everyone that we must have our own independent thinking, ask more “why” questions, and try to minimize the number of times we need help after falling into a “pit”.

Returning to the previous topic, how should we communicate with Product Managers? The answer is still on the topic of this section: start with the end in mind. We are making products, so we need to think backwards. Who will use this product, and how will it be used in what scenarios?

This question was not a popular concept in the early days of the IT industry because the initial IT industry mainly served businesses. One characteristic of enterprise development is that someone has specific needs. In this case, as long as the development team analyzes the requirements clearly, they can start working. At this stage, a key role in the team is a business analyst. Even if the software developed is not very user-friendly, it can be forced upon by the enterprise and eventually used by end users.

Later, applications targeting individuals began to appear. In the PC era and the early Internet era, software development was still focused on the needs of professional users. Most software, as long as it could solve a problem, people would find a way to use it.

But as the Internet became more popular, software began to spread to various fields. More and more people entered the IT industry, and different people started to experiment in various directions. At this point, the mainstream of software development shifted from addressing deterministic problems to addressing uncertain problems.

The IT industry is such an interesting industry. Once a problem becomes a common problem, someone will try to summarize various best practices. Once best practices accumulate, a new methodology will be formed. Agile development methodology was born in this way, and this time is no exception.

Lean Startup #

The earliest methodology focused on creating new things in the face of uncertainty is the Lean Startup, which was first summarized by Eric Ries. He shared his ideas in many places, refining them continuously, and ultimately wrote a book with the same name in 2011: “The Lean Startup”.

When seeing the name Lean Startup, most people will notice the word “startup” first. Although this name includes the word “startup”, it is not a methodology for guiding people to start businesses and make big money. As mentioned earlier, it aims to solve the problem of creating new things in the face of uncertainty.

However, the field of startups is an area with the highest level of uncertainty and the need to create new things. As long as there is uncertainty in solving problems, the Lean Startup is a methodology worth learning from. For example, building a new product.

The term “Lean” in Lean Startup is also interesting. Lean comes from Lean Production, a theory developed by Taiichi Ohno and Shigeo Shingo at Toyota.

This theory helps people understand the relationship between value creation and waste reduction. Creating value is something everyone can understand, but reducing waste is often overlooked by many. So, when these ideas are combined, the Lean Startup means creating new things in the face of uncertainty while minimizing waste.

So, what does the Lean Startup actually mean? It’s quite simple. Aren’t we supposed to create new things in the face of uncertainty? Since it’s uncertain, the only thing you can do is “try”.

How do you try? Trying requires a method. In the methodology of the Lean Startup, a feedback loop of “Build-Measure-Learn” is proposed. It means that when you have a new idea, you develop the idea into a product and launch it in the market, then collect data to obtain feedback and see if the idea is feasible.

The results obtained are nothing more than two possibilities: if it’s a good idea, you continue to strengthen it, and if it’s not feasible, you discard it. Regardless of the result, you will come up with new ideas and enter the next iteration. In this feedback loop, the knowledge you gain is the most important because it has been validated. In the Lean Startup, this is also a very important concept: validated learning.

Since it’s about trying and the validity of the idea is uncertain, the best approach is to try at the lowest cost, achieving the same goal while doing as little as possible. The Lean Startup introduces a very important concept, the Minimum Viable Product (MVP), also known as an MVP in many people’s minds. In short, spend less money and do more.

Many software teams fall into a very typical misconception, wanting to build and see every requirement, without realizing that fully building the software is the biggest waste.

Why do you want to learn Lean Startup? #

You may ask, as a programmer, and with no intention of starting a business, what’s the use of learning Lean Startup for me? The answer lies in the fact that Lean Startup provides us with a framework for thinking about product development, and most products that we encounter can be evaluated within this framework.

With a framework in place, our lives become simpler. When a product manager wants to develop a new product or feature, we can use the concepts of Lean Startup to assess whether the product manager has thought it through.

For example, what should be validated with this product feature? Are there measurable data for the desired goals? Is the problem to be solved the most important task currently, or are there other more important problems?

If the answers to the above questions are affirmative, then should we verify if there are simpler solutions to achieve this goal, or if it is necessary to develop a product feature?

With this foundation in mind, let’s go back to the previous example. In fact, what I was asking the product manager is whether or not this thing should be done. They were actually using a form tool to collect user information, which means there was an alternative solution available. Considering the many other requirements at that time, I suggested delaying the consideration of this requirement.

Summary #

The relationship between programmers and product managers is a classic topic in the IT industry. Many programmers tend to accept demands from product managers without questioning why, and then silently grumble.

In fact, product manager is an emerging profession, and even in the relatively new IT industry, it can be considered as new. Because the previous IT industry focused more on deterministic problems, it required more analysis. Only when facing uncertain work did product managers become a widely recognized profession. Therefore, currently, product manager is not a position with well-established industry standards.

The well-established methodology for creating new things in the face of uncertainty is lean startup, which proposes the feedback loop of “build-measure-learn” and the concept of minimum viable product.

When a product manager asks us to work on a new product feature, we can draw inspiration from the lean startup practices and ask product managers some questions to help us determine if the demands put forward by the product manager have been rigorously thought through.

If you only remember one thing from today’s content, please remember: default to not doing any requirements until we understand why we need to do them.

Finally, I would like you to reflect on how you communicate with product managers on a daily basis. Feel free to share your thoughts in the comments.

Thank you for reading, and if you find this article helpful, please feel free to share it with your friends.