How to be a programmer who understands products

"Guide" In many companies, programmers and product managers are "railway police, each section of the tube", the programmer is only responsible for implementation, do not care about who is in what circumstances with this product, what to do; The Product manager is only responsible for planning, not caring about whether the technology can be achieved or how much the implementation costs. It is estimated that in the minds of such an arrangement, programmers are like blind people who walk without looking at the road; The so-called division of labor Cooperation, is the lame conductor blind, everyone to escape.

About six years ago, I was working on an online RSS feed called "Catching shrimp" (if you don't know what the RSS-reading site is, refer to Google Reader). Readers need to display unread readings for the current user. The way to catch shrimp is to give accurate numbers, tell the user clearly "you still have 2,456 articles have not read", Google reader is shown as 10+, 100+ and other forms, told the user "I have more than 10/more than 1000 articles have not read." At first glance, this is just a common difference, but the product staff put forward 10+, 100+ form better, cause I now remember not very clear, it seems to say that this gives users less psychological pressure, because if the number is larger, users do not need to know the specific value, so the reading experience is better. Although programmers do not agree with this theory, but because the division of labor is different, the end of the development of the guys still completed this function. "It is conceivable that this feature was online and did not bring significant positive feedback." More interesting is, after a week, Google Reader's unread unexpectedly changed to the exact number!

A few weeks ago, I was talking about this story on Twitter, which was just a joke, but I was surprised by the reaction, because most of the feedback was a one-sided negative evaluation of the product manager. I also think of a friend of mine, he is in a product manager culture well-known big company to do development, talk about the ideal work, his request is "find a product manager less place is good." In this way, the contradictions between programmers and product managers are pervasive and profound.

According to common sense, if the cooperation between the two sides in this awkward state, will not be satisfied with the results of work. But what is the cause of this awkwardness? I think after careful thinking, one of the important reasons is the separation of work: In many companies, programmers and product managers are "railway public security, each section of the pipe", the programmer is only responsible for implementation, do not care about who is not concerned about who in what circumstances with this product, used for doing; The Product manager is only responsible for planning, and does not care about whether the technology can be achieved or how much the implementation costs. It is estimated that in the minds of such an arrangement, programmers are like blind people who walk without looking at the road; The so-called division of labor Cooperation, is the lame conductor blind, everyone to escape. However, just think about it, the product is an organic complex whole, "escape" is simply, purposeful short-term behavior, lame-blind this kind of cooperation, even if the real escape, is not suitable for products.

To step back, even if the product is really as simple as escape, the lame just run, the lame only command, such a combination can escape? You can escape every time? The answer is obviously negative, so in the real world we often see that this combination of blind and lame, after several failures, often people will not be reconciled, To work across the border, so the blind will fumble, and the cripple will walk a few steps-the programmer kicks the product manager or the overtly, and the product manager pulls up his sleeve and writes the code himself. Does such a thing not often happen?

As far as I can see, to really make good products, programmers and product managers must have a fairly consistent understanding of the ultimate goal, and must break the "impinging" Division of labor. In other words: On the premise that the final goal is consistent, product managers must have a technical thinking, must understand what can be achieved, which is not achieved, how to achieve difficulties, how to achieve easy; programmers must also have product thinking, not only concerned with the implementation, must be a broader perspective to understand and see their work. Together, it is possible to make a good product. Because I have a lot of programmer experience and thinking, the following only explains the product awareness that programmers should have.

Programmers with product awareness are very useful and necessary for at least three reasons.

First, excellent product managers are very few. The packaging of the "jobs" example misled too many people, it seems that product managers can be unreasonable, rely on talent and intuition. Actually, the real product manager needs talent, also inseparable from training, he should at least have strict thinking, in the product has not been developed before, can be in the brain comprehensive scrutiny, with good communication skills, to the product of the concept and planning accurately communicated to the relevant parties; In order to objectively judge the user's feedback, if you add a bit of technical background, it would be better. Unfortunately, there are so few product managers, a considerable part of the product managers are Pat Head pie (I think, this should be done, you do not ask), only pie (you do not ask me to say there is no reason, the boss is so required), or even simply is "functional manager." If the programmer does not have product awareness, and unfortunately with the product manager with the work, the result is often muddled to fall into the pit, and, more unfortunately, even have no room for reflection improvement (on the other hand, encountered a good product manager is very lucky and happy, this I have hands-on experience).

Second, product managers cannot be exhaustive. A product consists of a number of levels and aspects, they are ultimately done by programmers (developers) a little bit, product managers even involved in the implementation process, it is impossible to be responsible for everything. On the other hand, the user experience of the product is all-round, there must be a lot of details is the product manager can not be expected, users may be very concerned about them. If the programmer responsible for the implementation of these aspects of a little more thinking, often can play the icing on the cake or even 42 of the role. Some time ago on the network circulated an article, explaining Amazon Display category menu than other sites more rapid principle, this improvement is the engineer's own thinking results.

Third, the development work is actually a broader "product" part. Good products are inseparable from good development, only good development can not guarantee a good product. To make good products, developers certainly need to understand the product. Here are some things you can do to get familiar with the story of "three craftsmen": Planning the city is the designer, the craftsman is only responsible for brick, but only willing to work outside of the craftsmen, and know "This is a beautiful city part" and positive thinking of craftsmen compared to the latter to create a beautiful city is obviously higher, The work creates greater value.

Therefore, if the programmer wants to make a product of user satisfaction, rather than expect to meet the size of the reliable Product manager, it is better to cultivate their own product awareness, beyond the simple realization to think about the problem. Product awareness is not difficult to cultivate, in addition to the formal reading of the product information, usually even more thinking "who will be in what circumstances how to use my products", there will be no small progress. I've seen this kind of example, and here's a very small, simple example.

In the warehouse sorting line, the operator must check the weight of each package. When the volume of business is small, save the results of the day's work to an Excel form. But after the growth of the business, this approach is clearly unworkable and requires automated software to assist the operator. Developed software people know, to do is a very simple GUI program, the user login, read parcel information, confirm that the core information has a corresponding API, barcode scanning gun and electronic scale data reading also has a ready-made interface, they can be associated. But programmers in charge of development also focus on several issues outside the program:

How do I confirm that the weight of the review is accurate? It takes a while to weigh, so multiple samples are required to confirm the final weight, and this "multiple" is a few times can be set.

How to inform operator that the weight has been confirmed? The intuitive response is to allow operators to observe the software display numerical stability, think of the color to be labeled, not stable in red display, stable after the green display. The further idea is audible notification.

The electronic scale has the error to how to deal with? The answer is to add the "correction" option to the software setting so that the software can be corrected even if the electronic scale itself is temporarily out of alignment.

What if network communication fails when data interacts? The approach is to be compatible with synchronous and asynchronous interactions, and the results of communication failures can be localized and uploaded later.

These problems are not purely technical problems, but products. But without relying on product managers, active thinking programmers can solve them themselves. The end result is that the software developed entirely by the programmer is recognized by the user (operator) and is used reliably and conveniently, and future modifications will only add new functionality, and there is absolutely no need to change the usage. I also believe that programmers who develop this software, whether they work alone or with a product manager, will have more opportunities to achieve success than programmers who only "write code".

If anyone feels that this is not enough, want to know what other benefits the programmer has of product awareness? Let me tell a story: I have a friend to do finance, have participated in a lot of information Olympiad training, amateur also wrote a lot of small tools. One day he asked me: "Do you say that the programmer's work is so advanced?" is not writing code? You see I also have a lot of programming languages, but also wrote a lot of programs, so the programmer is nothing great. I replied: "So, have you ever written a program for someone else?" He thought for a moment and said: "Well, you won." The