In this article, the author of this article introduces his own product development experience and tools used. Their approach is to continuously communicate with stakeholders on a weekly basis and conduct “sprints” again and again. Of course, we can also compare the approach of the project management software company Basecamp.
Earlier we discussed the art of defining products, which is the first step in the journey of bringing products to market (or realizing dreams). After you define the MVP (Minimum Viable Product), you have to develop this thing, otherwise it is just another idea thrown into the four-dimensional space.
Our team has developed hundreds of products in total. The following is our development approach.
First of all, you need to remember a very simple but very important concept: the product will evolve. No, I’m not talking about the difference between the first and second editions of a marketed product; I’m talking about the difference between what you defined before you start developing the product and what you want to release.
Let’s take the house as an example:
To build a house, you first have to make drawings, including elevation, floor plans, and water and electricity diagrams. Since houses and rooms are all commonplace things, it shouldn’t be difficult to define exactly what you want. We tend to describe requirements like this:
I have been to Claire’s house, and I want one of the tables, but I want to put it in the restaurant.
It’s simple, isn’t it? No testing is required. If a certain table can be placed in the kitchen, it will probably be no problem in the dining room. But what if you want to create something you have never seen before and want to put something you have seen in it to change it?
I read CNN’s website, and I hope to put one of the good news boxes on my fruit-selling website.
Wait a minute… Put a news box on the fruit market?
Maybe it can, but some things need to be confirmed first:
- Do you want it because it is necessary or it looks good?
- Does it fit the design and information structure?
- Can it add value to the website?
- Does this make sense to users?
This sounds like a bit of a bone in an egg, but studies have shown that it takes less than 1 second for users to make a first impression of your website, and it is only judged from an aesthetic point of view. You need to let them enjoy the beauty, and the website needs to focus on accomplishing the goal. Naive product owners think that they can make their product “good-looking”, and then users will automatically fall in love with it, ignoring the fact that the experience is so bad that it is almost impossible to use it.
In order to summarize all product requirements, we first collect the main information with Trello:
These are called epics. Basically belong to a very broad and short independent function description. It is a high-level view of all the functions required for our final product. Epic makes the conversation with the product manager easier, and the communication between the two parties can involve more details, such as:
- “Which product field do you want to save?”
- “How should users edit the appearance of the page?”
- “What fields should the search function look for?”
…
As long as we have done this, we will verify it through the customer. And start to write user stories, which are the specific steps of each action. Many user stories consist of an epic. This stage is crucial. User stories allow us to tell stories, which often allows us to capture problems that we didn’t think about when we listed only high-level features (also called epics). Most importantly, it allows us to examine the product from the user’s perspective. This helps us identify problems that users may encounter or edge cases that may not be obvious in the first place. Then we can review the user story with the product manager and the customer to ensure that we have accurately understood the vision. As an incubator for start-ups, we are experts in products and software, but customers bring their expertise and they know what is needed for product launch.
Now that we have verified all the requirements, we have added the necessary things to make this happen: useful libraries, data structures, API interfaces, deployment strategies, server configuration, etc. After we have organized all the tasks, we split them into iterations within a predetermined time (usually once a week)-or called sprints.
The following is the Trello board of Kanban workflow software:
However, estimating time is always difficult. This requires a certain combination of science and art:
1) A: Ah ah ah ah! I am really bad at estimating how long a project will take.
2) B: Don’t panic-there is a simple way to help you calculate, which is to make the most realistic estimate, and then multiply by 2. A: Okay, but–;
3) B: Next, multiply by 2, add 5 minutes, and then multiply by 2. A: Ok…
4) B: After 30 seconds have passed, you have done nothing but double the number you imagined! You have made no progress at all and will never be done! A: Ahhhhh! Ahhhhhhh!
Every developer has his own method of estimating development time. We have also tried different methods, each with varying degrees of success, but these are things to be discussed later.
Estimation will change the function of MVP, because a function will consume a large proportion of resources, so it needs to be handled carefully.
In computer science, it is difficult to explain the difference between easy and almost impossible.
Product: When the user takes a photo, the app should be able to know whether he is in a national park;
Development: Of course, a simple GIS search will do. Give me a few hours.
Product: Then you should be able to know if you are taking a picture of a bird.
Development: I need a research team and 5 years.
Now that everything is organized, we need to start implementation.
As I mentioned before, our sprint lasts for a week. During this period of time, we intend to develop all the functions included in this sprint, but sometimes it does not happen. Why? In fact, the answer is simple: we cannot predict the future. No software engineer can. The only thing we can predict is the unpredictability of the future. The realization of the function may take longer than expected, and the design/content/project manager may create problems for you. Once we had to use the gateway to implement the payment system, but in the process of implementation, we found that they changed the working mechanism of the API, but did not update some of the dependencies. Result: We need to interrupt the development to half of the process and reintegrate with another payment system.
Doing in the field of innovation often means sailing in unknown waters. The setbacks should be conceivable. Plans are used to break, and few projects are finally carried out in accordance with the original plan and “standards.” Changes in history have come from all directions, whether internal or external. The key point for us is to adjust ourselves to these situations as soon as possible, and to be transparent about the process.
However, this does not mean that you should never allow time to estimate potential setbacks. When we do encounter unexpected problems, we will immediately communicate with the team to try to identify the image of the timetable. Adjusting the timetable does not mean that we will not be able to meet the deadline, but it means that we must continue to maintain this realistic expectation.
Another source of change is likely to be the customers themselves. Customers, especially those involved, think back to seeing how their product vision was advanced. This means that they will often make requests for changes or new features within the scope of the original project. It is easy to say “Yes, we can do this”, especially if the “that” thing is small. But small things can easily accumulate.
This by no means means that we say “yes” to all customer requests. One of the values we bring to this field is our experience and expertise. If we did reject a request, it must be because we have studied it, found some examples of it, and can give professional, objective and rational reasons for objection. This is especially important when customers often request changes out of personal preference.
Good communication with customers can make this process effective. We call once a week to explain the following things:
- What has been done and what has not been done
- The problem we are facing
- What is expected to be done next week
- What about the new timetable if we encounter any obstacles
In this case, we don’t need to add any “buffer” to our schedule.
This weekly system is also very important for verifying some visualization functions, flows, etc. Remember what I said about the changes in the product being developed? This is often where the change comes into play. Once you see that your thoughts have taken shape, you may find that there is a better way to do something, or that an idea that seems brilliant at first is not that good. A short sprint and verification along the way can have huge benefits, because with continuous verification and input, product managers, customers, and engineers will eventually be satisfied with the product.
This is how we handle product development at Codelitt. Of course, there are still many things to deal with, such as QA process, verification with customers, and sending products to the product department. We will discuss these things in a new article in the future.
