19 How to create a product with minimum costs? #

Hello, I’m Zheng Ye.

Previously, we talked about task decomposition and requirement management, which are decomposition strategies for “things that have already been determined to be done”. Today, let’s take it a step further and discuss how to decompose uncertain product features.

Product managers have endless ideas, but if we blindly implement the product manager’s ideas, no matter how big our development team is, it won’t be enough. We need to learn how to create a product with minimum costs.

Speaking of the topic of product, in the article “Lean Startup: What to Do When Product Managers are Unreliable?"(http://time.geekbang.org/column/article/76260), I shared with you the concept of lean startup, where any idea needs to be tested in the real world.

Our instinct, of course, is to implement everything before testing it, but the world won’t wait for us. The fact has repeatedly taught us that the “big reveal” waterfall software development has become an obsolete practice. So how do we achieve our ideal? Through decomposition.

As mentioned earlier, lean startup is the practice of continuously testing product ideas in the real world, and one important practice is the Minimum Viable Product (MVP). This time, let’s discuss this practice in detail.

What is a Minimum Viable Product? It is a product that “just right” meets customer needs. Customer needs are easy to understand, but how do we determine what is “just right”? The key lies in understanding “minimum” and “viable”.

Minimum Cost #

Let’s start with “minimum”. Here, “minimum” refers to the minimum cost. What does it mean to have the minimum cost? It means that we should not do things that are unnecessary and should simplify things whenever possible.

First of all, we must be clear about one thing, what we want to do is to validate the feasibility of an idea, not even to develop a software. Developing software is just a means of validation.

Many programmers have a misunderstanding, often mistaking the solution as the problem. The purpose of developing software is to solve problems. If we can solve the problem without writing software, wouldn’t it be better?

Let me share an experience of my own to help you understand what “minimum” means. Once, a friend asked me for help. He had some manufacturing clients and wanted to do an Internet of Things (IoT) project to help these clients transform their equipment and implement IoT functions.

How should we approach this? Should we develop the software and let the clients try it out? This would take too much time and cost. So, how did we do it?

The first step is to validate whether this idea is feasible. We created a product document as if we already had the product, and let our sales colleagues use this document to talk to clients and see their reactions to this idea.

During this process, we validated the basic idea and confirmed that there was a demand for transforming existing equipment into IoT-enabled devices. When clients saw this concept, various ideas and requirements came up.

In addition, we obtained an additional benefit: we learned the price range that clients would accept for such a product, which helped our team to price the product appropriately.

After validating the direction of the idea, we moved on to the specific product design stage. In this stage, we wanted to validate whether users would accept the product design we proposed. So, we decided to create the product’s interactions.

Thanks to the rapid development of prototyping tools, we created a relatively complete user interface using a prototyping tool and implemented various interaction flows. From the perspective of users, it was almost a complete software.

They could even experience how this product would feel on their own devices. Once they started using it, they would raise various detailed questions: “It would be great if it could be done this way,” or “It would be perfect if it could achieve this.” Of course, some would say, “I don’t need this thing.”

At this point, we could know which assumptions about the product were good and which ones were not smooth. With this feedback, the team could adjust the product design and then let users test it again, repeating this process. Sometimes, the product would be updated several times within a day.

After multiple rounds of testing, the team had a wealth of user feedback, and it was real feedback from actual users. The next step was to organize this user feedback and decide which ones could actually be developed. Only then did the team truly enter the development stage.

I don’t know if you noticed it, but until now, the team validated a wealth of ideas without writing a single line of code. All the work done was targeted validation.

We often hear a joke that goes, “Just one programmer is missing.” It refers to a startup founder who has done all the preparation work and is just missing a programmer to develop the product.

According to the concept of Minimum Viable Product (MVP), this founder is doing the right thing, as long as they have indeed done all the necessary preparation work.

Developing software is a costly task. If we are only validating ideas, whether it’s the direction of a startup or product design, we can find various means to do so without writing code.

Even if we are not developing a new product, we can still apply the concept of “minimum cost” in our daily work. For example, how to evaluate whether a product manager’s product design is good. I would ask, what would happen if we don’t implement this feature? Are there any alternative solutions? In doing so, we can help the product manager clarify whether their product design really has value.

Feasible Path #

After discussing the concept of “minimality”, let’s now focus on the concept of “feasibility”. Feasibility refers to finding a feasible path that provides users with a complete experience. As someone with a programming background, we tend to approach software systems by breaking them down into modules. However, a weakness of this approach is that we often lack a complete picture.

From a product feasibility perspective, we need to shift our mindset. It’s not about how complete each module is, but rather whether the user’s path is smooth.

Let me share an experience I had when working on a P2P (peer-to-peer) lending platform from scratch.

The project was like any other project, where the project team wanted the platform to go live as soon as possible. They gave us a timeline, and the first version was scheduled to be launched one month later.

The problem we faced was that it was not feasible to build a complete lending platform from scratch within a month, given the limited resources.

Due to the time constraint, we could only focus on the most basic features. Many operational ideas, such as giving out red envelopes or vouchers, were put on hold for the first phase. Even with these limitations, we still believed it was unrealistic to complete a full lending cycle.

So, we started brainstorming from the perspective of requirement completeness. In this lending system, the basic model was that after a borrower received a loan, they would repay it in equal monthly installments with interest, and finally, in the last month, they would repay the remaining balance in a lump sum.

We identified a key point in this model - monthly repayments. In other words, the earliest repayment would occur one month after the first loan was made.

Therefore, we made a decision - the first version would only include the ability to borrow money. Yes, users could only borrow money and not make repayments in this version. Because within a month, users would not have any repayments due. From the user interface, this missing functionality was not noticeable, as there were no outstanding repayments within that first month.

By reducing the scale of the project, we were able to complete all the development within the expected one-month timeframe and successfully launch the project. The early adopters started using it. From the users’ perspective, it was a fully functional project, albeit a simplified one.

Of course, we planned to add the repayment feature in the next phase. Following our bi-weekly iteration schedule, we would launch the repayment feature two weeks after the initial release. At that point, borrowers would have a proper repayment function.

However, even with the addition of the repayment feature, we still did not support the final lump sum repayment of the remaining loan. According to the requirements, the final repayment was expected to happen one year later.

After launching all the basic features, the system became a truly complete lending platform. But compared to other platforms with the same functionality, our system was still quite simple. For example, common operational features and short-term loan plans were not available on our platform.

But we had a foundation to build upon. With our team growing and gaining enough capacity, we could start working on multiple major features simultaneously.

In this way, a few months later, we gradually launched a P2P platform with relatively complete functionality. Throughout this process, we would release new features at each stage. From the user’s perspective, they always saw a complete platform, and the changes were only visible to us as the internal implementers.

I shared this example to challenge the notion of what a “complete” system means. When time is limited, we need to find a feasible path and strike a balance between providing a complete user experience and building a full-fledged system.

From a development team’s perspective, how can we apply the MVP (Minimum Viable Product) concept to our work? When the product manager has a bunch of features they want to implement, we can use the MVP concept to identify the minimum feasible path from these features and rearrange a reasonable development plan.

Summary #

Products also need to be decomposed. Currently, the best practice for exploring the uncertainty of the product is lean startup, which includes the approach of breaking down the huge product: Minimum Viable Product (MVP). The Minimum Viable Product is a product that “just right” satisfies customer needs.

To apply the concept of Minimum Viable Product effectively in practice, it is important to find a feasible path with the minimum cost. The minimum cost means not doing what can be avoided and simplifying what can be simplified.

Programmers usually prefer to solve problems with code, but writing code is often an expensive solution. It should be the final solution for the product.

A feasible path is a complete user experience path, at least in the user’s perspective. We often want to provide customers with a complete system, but in limited time, we must learn to decompose.

If there is only one thing you can remember from today’s content, please remember: The most feasible way to develop a good product is to use MVP.

Finally, I would like to invite you to share any cases you have encountered or heard of that solved problems using MVP or similar methods. Feel free to write your thoughts in the comments.

Thank you for reading. If you find this article helpful, you are welcome to share it with your friends.