Link: https://www.zhihu.com/question/19554113/answer/14831116
Source: Zhihu The
copyright belongs to the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.
In the past seven years, I have been working on Internet products. In the first five years, I worked in a startup company and a listed company, making other people's products; in the past two years, I started a business and made my own products.
My experience is that product managers need to understand technology, especially entrepreneurs. But the premise is that you always feel an irresistible urge to do something. If you plan to live a stable life, especially in a big company, you don’t need to understand anything, but be careful not to “know too much.” ", fools live in peace.
In the past few years, I have dealt with development engineers the most, and there are usually two taboos when communicating with them:
1. Don't understand technology
To be more precise, you cannot lack the basic technical knowledge of designing and developing an Internet product. For example, you must at least know the necessary links for a website from non-existence to being accessible to users; you must also understand that an app starts from your mind. To the user's mobile phone, what kind of process needs to go through.
With common sense, of course, you may not be able to make a good product, but without common sense, it is like someone who has lived in the village for half his life and arrives in the city.
Many companies have product people who do not understand technology at all. Most of them are older. Maybe when the Internet appeared, they have passed the age of curiosity and desire for the unknown. They are unwilling to lower their body to learn new things. Imaginings and their own life experience will be sprayed, and occasionally some recent popular keywords are used as embellishments to show that they are still at the forefront of the trend.
Such people may be able to fool some leaders, but they must not be welcomed by engineers. They may not say anything, but they have already begun to wait for the jokes in their hearts, and the development needs handed to them, naturally, they can be delayed or delayed. Then Mongolia.
2. Avoid technology
I have met many engineers who like to say, "As long as the product requirements are clear, everything can be achieved technically."
This sentence sounds quite heroic, and it also reassures the product manager that technology is really the strong backing of the product. But it actually sent a particularly bad signal.
When an engineer says this, the subtext is: "Just do your own thing, leave me alone!" And that statement implies an optimistic but apparently unrealistic assumption: technology is omnipotent Yes, he (the person who masters the technology) is also like the Djinn, and can realize any wish you want, as long as you can describe it clearly.
I don’t know if after Aladdin finished his wish, if he dared to continue to ask what kind of technical solution Deng Shen will use to realize it, he would be stuffed into the lamp, but I know that many engineers are finding that you are too concerned about the technical level. At times, there will be a sense of territory being violated.
This is the instinct of an engineer to maintain his professional slot. Compared with other roles in the industry, the engineer's status is not the highest, and the salary is not the best. They often work overtime and die. The only unique advantage is that the professional slot is better than any role. both deep. Every practitioner can say something about the product, about the UI, and even about the business model. When it comes to user experience, even people outside the industry dare to say something without any psychological burden: I am a user anyway. Well, the dumber the more glorious. And when it comes to code, most people just get paralyzed. Thinking about the hard work of UI designers, there is no interference from trolls pointing fingers at work, which is really a unique gift given by God to engineers.
So when they think that outsiders are trying to cross this slot, they will naturally be vigilant, and even show resistance and hostility. When a product manager finds that engineers are starting to use terminology intensively or trying to complicate simple problems, you should know that they are starting to shoot arrows at you in the groove.
From the perspective of the entire product and even the company, the professional slots between various professional roles should be filled. Product managers should not play with engineers to make princes, and should not always pretend that they are the three representatives of users. Always use the imaginary "user needs" as "Fengtian transportation"; engineers don't have to install the lamp, pretending to be omnipotent and tiring, engineers must be able to distinguish between superior and inferior, in fact, sometimes the function can not be done Or do it poorly, purely because of the limitations of the engineer's ability. If you are more honest with each other, you can communicate effectively in advance, and try to avoid those parts where the input-output ratio is too low. Many engineers are reluctant to discuss the details of technical implementation, which are worthy of the participation of product managers. How to choose and choose these details will have a great impact on the development progress, performance and even functions of the product. If the communication is in place, it can often save the development engineers from doing a lot of useless work. After I started writing the code myself, I got a deeper and deeper understanding of this.
Let's talk about why I started learning to write code, which is the second half of answering the question.
In the first five years of my Internet product development, my knowledge of technology was limited to common sense. The only code I could write by hand was html and css, not even js, let alone any programming language suitable for web development. I've always considered myself incapable of fully hand-writing even the simplest dynamic website, a huge flaw and a shame as an internet product person.
Engineers generally don’t think so. When chatting with them, they sometimes spout some opinions on technical architecture or certain technical issues, and they are immediately praised: “You know technology very well!” At this time, he immediately said with a haha: "Understand p, I can't even write hello world, it's all on paper." So a group of people put away the arrows in their hands amid the laughter.
But I didn’t want to think about it and could only talk about it on paper. In 2009, regardless of my age of thirty-two at the time, I decided to learn Ruby, bought a book, set up the environment, started reading, typed code, persisted for a few days, and then failed. Well, considering maybe Ruby was too hard for me, tried Python again, and it still failed. After a few days of depression, I didn't give up, bought another book on iPhone development, and took the opportunity to buy a 27-inch iMac, but the tragedy was that I just flipped through the book, and I gave up without even Xcode. Nothing to say! It's a lot of code! And the code of obj-c is huge and completely incomprehensible.
Later, I thought that there were two gains from this incident: 1. I discovered the boundaries of my own IQ. 2. I have an iMac.
In the blink of an eye, more than a year has passed, and the feeling of wanting to make an iPhone app by myself is getting stronger and stronger, and I can't hold back anymore. So one day, as if I had healed the scar and forgot the pain, I turned out the basic tutorial for iPhone development with almost no creases. While waiting for the Xcode to download, I made up my mind: I would memorize it even if I didn’t understand it.
Later, I found that the stupid method worked, at least for me: typing the code according to the book, and if it works properly, then close the book and type again. Generally, it can be remembered very firmly after four or five repetitions. Co-authored a book, and skillfully knocked on the code that I didn’t know what it meant. Plus Xcode’s auto-completion is very powerful, I can toss out a large screen of colorful code in a few minutes, and it can also run on the iPhone. , At this time, there will be an illusion that you have already written iPhone App, which is wonderful.
The human brain is also very wonderful. If you have memorized it, you will gradually understand it automatically if you don’t understand it. After reciting a piece of code after another, you suddenly find: I understand what’s going on. After that, I began to put forward various small functional requirements for myself, and tried to implement them with these codes. Every time I implemented one, I was ecstatic: I can display the button! I can pop up the dialog! I can write scrolling lists! I can send a push message!
After these things are proficient, they may be as dull as drinking water, but they can bring great joy to beginners. I have always felt that whether I can always maintain the enthusiasm and concentration of beginners determines whether I am doing something. How far you can go, how well you can do it.
Due to the difference between the version of Xcode used in the book and the one I used and some printing errors, the code in the book will not always run 100%, and sometimes an error will be reported. Slowly see some specialized technical forums and blogs, and eventually you will inevitably find Stack Overflow, a magical website, where you can find answers to most of your questions.
When the realization of the functions in the book can no longer bring ecstasy, I can't help but want to release all kinds of ideas that I have been shackled for a long time, and finally I can do it myself, instead of being limited to drawing prototypes, writing At the end of writing the requirement description, you must wipe the magic lamp religiously, and call on the gods of the lamp to make products so easily.
The development process is full of fun for me, because when writing code, the world becomes simple and beautiful, and a certain approach is right or wrong, you don’t need to guess again and again, and you don’t need to argue endlessly with anyone, compile The instrument is the divine judge. With immediate, unambiguous feedback on every action you take, and a near-luxurious opportunity for trial and error, programming is a little like playing a game.
Of course there will be countless questions, and Stack Overflow, Github, Bitbucket, and mailing lists will slowly become your friends.
After I was able to write an iPhone App by myself and put it on the App Store, I found that I needed to learn another language to develop the website and the RESTful Web Service that needs to be called in the App, so I ignored the age of thirty-five. The old age, once again outrageously hit the idea of Python, with the experience of learning obj-c, I know that the key is to be able to calm down and calm down, what book to read, in fact, the difference is not particularly big, so I use I got the free Learn Python The Hard Way, followed the method mentioned above (the first half is relatively simple, you can do more than a dozen exercises a day, and the speed may be slower later), after understanding how to write Python , I started to read Django Book 2.0 right away, I only saw Chapter 9, I couldn't wait to do the Django Tutorial twice in the same way, and then I was pleasantly surprised that I could write a simple but complete website. Then I quickly tried to use Django to write a very small tool website for a certain vertical field. After running for a while, I ended the free trial last night and started charging. Now I see a few paying users, I am very pleased.
As for how much you need to know about technology, I think that if you learn something in a few months, it will be enough for a lifetime. This business is too cost-effective, especially in the field of technology, you will definitely need to continue to learn, but for me, there is no Qualifications are like young people in their teens and twenties who can learn only on the basis of broad interests. At present, I am very utilitarian on the principle of this matter: what will be used immediately, can significantly improve efficiency or be recognized as the best practice, otherwise Do not learn first, try not to toss, and strictly control the time and energy invested.
For example, if the written code is placed on the Server, although the deployment is successful as long as it can run, it is generally accepted that the best practice is to use virtualenv to isolate the Python environment, which can reduce a lot of trouble in the future, so it is worth spending more time to understand. Go to application; using Fabric with Git for automated deployment can greatly improve efficiency, so it is worth taking the time to learn how to use it.
I also know that Memcached or Redis can be used for caching to improve application performance; or Rabbit Mq and Celery can be used for asynchronous queues, which can improve the discomfort caused by synchronous execution of tasks that take a long time; and Node. js seems to be more suitable for RESTful APIs than traditional web development languages... But these are not the most pressing problems at the moment, so although I don't know it yet and I'm sure it will be useful, I won't learn it yet.
If he didn't pay attention, he spat out a few thousand words, so let's stop, it seems that the middle-aged man's long-winded words are hopeless.
Finally, to sum up, just one sentence:
Product managers understand technology = hooligans know martial arts . If you think the gang is big enough and your brain is good enough to be a master, then you can’t do martial arts; The brain can even practice a little self-defense, I am afraid it is easy to be beaten into a reptile.
A more serious summary is: product managers understand technology, can do things at the lowest cost when resources are unavailable, and use resources more efficiently when resources are available.