Lessons from the development of mobile internet products

In the technical Team office area the entire wall whiteboard has been written three groups of words: breaking things (breaking things), FCX (Clear), simple (easy). This is written in 2013, this is the entire product technical team expectations, the first, and most importantly, ready to "break everything."

From "Breaking Everything", record the past two years in the content and technology across the border between the 9 experience and lessons, yes, most of them are lessons.

1. Be happy to "break things" and never be afraid of "breaking things"

The idea of "breaking things" is that the project is now starting from zero to almost 1.5. Because before, we have abandoned their own need to be broken things, the daily rampage is to break those who are reluctant to break. After more than 10 years of internet transformation, although not the digital generation, we have come to understand that the interval will have to forget all the "experience".

But one day in the middle of the year, we found ourselves unconsciously looking to reduce change and worry that seemingly functioning systems were having problems with the adjustment. When we see ourselves beginning to be negatively affected by the normal adjustment of technology, we realize that the weeds that are afraid of breaking are already burying the seeds, and the choice begins to break, breaking the past that we have accumulated: code modules can be discarded and replaced, products without hope can be discarded, and new systems can be built by abandoning the usual To make mistakes and make a big mistake in the adjustment.

"Breaking things" is difficult, to give up what is already, is contrary to the normal psychology of people. "Breaking things" is difficult, and when the plane is assembled on the ground, there is no fear of problems, but the break after a certain stage is "changing the engine in flight".

2. Structure is more important than detail

The choice of structure is more important than the choice of detail. Perhaps because of the different roles, I tend to look at the problem from a structural perspective, and often have to use the attention of the public to pull back to the structure of choice.

It is very easy to feel safe to focus on the details, and the person who makes the choice feels that everything is within his or her controllable range, thus creating a false sense of security. and the choice of structure is not to give people a sense of security, because the choice is obviously affected by the big environment, need a lot of people to reach a consensus, no one can have a sense of control.

This is where the fun is, and the choice of structure actually gives a greater sense of control, but in the process everyone lacks it. One does not believe what is imagined until it is truly seen, and when we see it, the structure is hidden by the details.

The concept of "product manager" has gone far beyond the internet industry for several years, but it is a great misconception that many people think of it as "interactive details". The details are variable and the structure is constant. For example, functional features are detail-changing over time, and interfaces are structures that should be relatively stable.

3. Simple

We often cannot choose the simplest, there are various reasons to prevent us from doing this, the biggest reason is laziness. Because of laziness, we do not want to be more painful, because of laziness, we endure all sorts of messy things that complicate the system; In the end, because of laziness, we give more strength afterwards.

"Simplicity" is often mentioned from the perspective of design, from the perspective of products and technology can also have a new understanding. Any technical system, is to continue to operate and maintain, if in the development phase to do everything possible to achieve simplicity, then naturally reduce the subsequent costs. Simple, is sustainable. Truly elegant solutions are also simple.

Always believe that there is a simple choice to exist in some kind, and then try to find it. Committee-style decision-making or mutual compromise, can never be simple, only willing to give up their views, choose the best solution can be found to be simple.

4. Quick

Fast is right. In early 2012, one of the few slogans in the Facebook office was "Code Wins Argument". Fast is, don't waste time on argument, use specific code, product to verify right and wrong. Not to spend time arguing, but to validate right and wrong directly with the implementation.

In the internet industry, my feelings are one quarter equal to other areas of the year; while in the mobile internet, one months is equivalent to another industry year. At the beginning of the internet there was a book called "21 Years of the dog: My Day in the Amazon", the dog of January quite a man of the year.

In the age of mobile internet, we are "one year" each month. The previous year's many specific industry insights, technical capabilities, technology implementation, product features, now have become meaningless. With such a "year" to understand, the best solution to the fast problem: No one will spend a year arguing, right?

5. Balance between self-building and integration

In the field of technology, a function is to develop itself, or to adopt the existing generic technology products, this is a problem.

We turned back and forth between the self build and the integration, some chose to integrate, but finally found that one day almost all the integration over the total discard, some chose to build, but later found that the use of common services simpler and faster. This choice may be a continuous process of adjustment, and change is not a statement of the wrong choice.

Self-built, you can build an integrated overall effect, integration, you can quickly achieve the goal. In general, the principle is that the core of the business should be as far as possible to take the self-built, rather than the core, the use of generic products. The complementary principle in this regard is to build only those features that have long-term value that will be developed and upgraded for long periods of time. For those one-time, day-cast (month-cast) characteristics, you can consider directly negative.

This, on the other hand, what kind of principles, often sound worthless, but in the engineering field is so, the absolute principle is often divorced from the actual situation in the field of engineering.

This seemingly vague matter is the lesson we think we need to remember, because the experience of it permeates every day, and it gives us a better understanding of engineering principles. This kind of engineering considerations, because we from the beginning of the development of the platform to develop the path, so the specific products and the engineering system behind is both.

6. Continuous reconstruction

Reconstruction, if used in terms of development, is "refactoring". For a technical team, it takes a while to refactor the code, and also to refactor the entire product structure to ensure that the code does not become maintainable in the ongoing development and functionality process, thereby turning the asset into a liability. In plain terms, refactoring, by grooming, always keeps the code as an asset, because the maintainable code is the asset, and the code that can be run is not necessarily.

In the mobile Internet, the outdated speed of the code (especially the client part) is much faster than the Internet, which makes refactoring must shorten the time interval. In the past, we often left the code to the next person to solve (most of the time they would curse the code is bad, and sometimes choose to rewrite themselves from scratch), in the mobile internet era is too fast to solve the problem on our own.

In terms of product characteristics, the need for continuous reconstruction. One new version may be seemingly unchanged, but in reality it must be a fundamental change. This kind of change needs to give up many of the features that have been put into resources before, and may need to make more difficult sacrifices. Reconstruction is a must, otherwise, the product will gradually lose its vigor in the process of growth.

7. Early integration, early testing, early product to market

Early integration, early testing, early product to market, better than late. One of the core principles of Toyota Lean (lean) production is to expose the problem early so that it can be solved earlier. For example, finding problems, "anyone" can stop the entire production line design, is to expose the problem. Looking at the calm water, we often unconsciously estimate the surface is flat, very safe, lowering the water level to expose the stone, you can force us to face problems, solve problems.

In the process of development, as early as possible to integrate the modules, you can find the gap between the modules, as soon as possible to the product to the user, can be in the actual trial run process to discover product design problems, the early formal operation of products, can be through the market to actually test the many assumptions on the product

No "earlier" is the most painful lesson of the past few years. The trouble is that it is one of the few lessons to be learned when there is no "earlier" lesson to be found.

8. Focus on core data, never cheat yourself

Find those really valuable core data, focus on the changes in the data, and never cheat yourself. Data statistical analysis system, often at the last minute to think of to do, in fact, it should be the whole project planning when the focus on the functional characteristics.

The data is not so complex, there is no big data, a simple data graph can solve the problem. If you can't understand with a simple datasheet, then talking about big data is just empty talk.

In lean entrepreneurship, the author refers to a "vanity indicator" of self deception, which mainly refers to the cumulative number of users. Mobile application of the biggest false prosperity is the cumulative download, in fact, we all know that there is no continuous return of the user, but a passer-by, and many of the passers-by are just a number.

9. Build a technology-led team

Finally, and perhaps most importantly, companies with mobile Internet as their main business should build a technology-led team. At least in terms of product development, you should build a team of tech-led people rather than being an engineer as a silent programmer. Only technical staff-led product technology team, is healthy, long-term development, because technology is now the core source of all changes.

It's easy to talk about technology drivers, but the companies and teams that really do it should be scarce. There are many sayings, engineers do not understand strategy and do not understand the strategy, for reasons of Chinese education engineers do not understand the product, in order to no longer first-line engineers do not understand the demand these are just other people used to try to grasp the idea of dominance.

Like everyone else, technicians have long established mental inertia, for example, some people like to consider all the possible circumstances, resulting in his design of the solution is too complex, some people are easier to compromise, leading him to accept the wrong plan, some people tend to choose their familiar technical solutions, rather than try new. This is the human nature that exists in other fields.

On the other hand, technicians have a common inertia that is valuable, and technical people tend to build "systems that can run for a long time", and "long term" means that they have considered their long-term value at design time, and "system" means taking into account all aspects of it, especially those gaps; Running "means that the final deliverable must be a functioning" live "system.

If you can go back to the past, here's the lesson here is to give each engineer a greater ownership of the technology product and to gain greater leadership for the product technical team.