What are the technologies that product managers must know?

Link:/question/19554113/answer/1483 1 16.

Source: Zhihu.

Copyright belongs to the author. Please contact the author for authorization.

I have been making Internet products for the last seven years. In the first five years, I worked in startups and listed companies to make other people's products. I started my business in the past two years and made my own products.

My experience is that product managers need to know technology, especially entrepreneurs. But only if you always have an irresistible impulse to do something. If you plan to live a stable life, especially in a big company, you don't need to know anything. But be careful not to "know too much", a fool is safe all his life.

In recent years, I have dealt with development engineers the most, and there are usually two taboos in communicating with them:

1. Don't be ignorant of technology.

More precisely, we should not lack the basic technical knowledge of designing and developing an Internet product, such as at least knowing what necessary links are needed from the time a website never exists to the time it is visited by users; Also understand what process an App needs to go through from your brain to the user's mobile phone.

Of course, common sense does not necessarily make a good product, but without common sense, it is like a person who has just arrived in the city and stayed in the village for half his life. No matter how careful he is, he will inevitably appear abrupt and discordant.

Many companies have product people who don't understand technology at all. Most of them are older. Perhaps when the Internet appeared, they had passed the age of being curious and yearning for the unknown. They don't want to lower themselves to learn new things. They like to spray only by imagination and their own life experience, or occasionally embellish some recent hot keywords 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 recruit engineers. They may not say anything, but they are already waiting for jokes. Naturally, the development needs given to them can be delayed again and again.

Step 2 avoid technology

I have met many engineers who like to say, "As long as the product requirements are clear, anything can be achieved technically."

This sentence sounds very heroic, and it also reassures product managers that technology is really the strong backing of products. But it actually sends a particularly bad signal.

When the engineer said this, the subtext was: "mind your own business and leave me alone!" " Moreover, this statement implies an optimistic but obviously unrealistic assumption: technology is omnipotent, and he (the person who masters technology) can realize any desire you want, just as you can clearly describe it.

I don't know if Aladdin will continue to ask the genie what technical solution he will take to realize his wish, and whether it will be stuffed into the lamp, but I know that many engineers will feel that their territory has been violated when they find that you pay too much attention to the technical level.

This is the instinct of engineers to maintain their own professional slots. Compared with other roles in the industry, the position of engineer is not the highest, and the salary is not the best. They often work overtime to death. The only unique advantage is that the professional slot is deeper than any role. Every employee can spray a few words about products, UI and even business models. Speaking of user experience, even outsiders dare to spray without psychological burden: anyway, I am a user, the more stupid, the more glorious. When it comes to code, most people are confused. Think about the hard jokes of UI designers. There is no interference from the sprayer when working, which is a unique gift from God to the engineer.

Therefore, when they think that an outsider is trying to cross this slot, they will naturally be wary and even show resistance and hostility. When a product manager finds that engineers start to use terminology intensively, or try their best to complicate simple problems, you should know that they start shooting arrows at you at the edge of the trough.

From the perspective of the whole product and even the company, the professional slots between professional roles should be filled in. Product managers should not play with engineers as princes, always pretend to be users' Theory of Three Represents theory, and always take imaginary "user needs" as "phoenix carrier"; Engineers don't have to pretend to be omnipotent and tired. Engineers must have the ability to compete with each other. In fact, sometimes the function can't be done or can't be done well, just because the ability of engineers is limited. If you are honest with each other, you can communicate effectively in advance and try to avoid those parts with low input-output ratio. Many engineers are unwilling 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 influence on the development progress, performance and even function of the product. If communication is in place, development engineers can often do a lot of useless work. I have a deeper understanding of this point after I started writing code myself.

Let's talk about why I started to learn to write code. This is the second half of answering the question.

In my first five years as an Internet product, my technical knowledge only stayed in the common sense category. The only code I can write by hand is html and css, not even js, let alone any programming language suitable for Web development. I always think that I can't even write the simplest dynamic website, which is a huge defect and shame as an Internet product person.

Engineers generally don't think so. When chatting with them, sometimes they casually spray some technical architecture views or some technical problems, and are immediately praised: "You know a lot about technology!" At this time, I immediately smiled and said, "I know a P, and I can't even write hello world. It is completely on paper. " So in laughter, a group of people put away their arrows.

But I don't want to talk on paper at all. In 2009, no matter I was 32 years old, I decided to learn Ruby, bought a book, installed the environment, started reading and coding, persisted for a few days, and then failed. Considering that Ruby might be too difficult for me, I tried Python again and failed. Depressed for a few days, I didn't give up, but bought another iPhone development book and decided to buy a 27-inch iMac. But the tragedy is that I just looked through the books and gave up even Xcode. There is nothing in this book! It will generate a lot of code! Moreover, the code of obj-c is extremely long and completely incomprehensible.

Later, I thought that there were two gains in this matter: First, I found the boundary of my IQ. I have an iMac.

More than a year has passed in a blink of an eye, and the feeling of making an App on the iPhone is getting stronger and stronger. I can't help it. So one day, I forgot the scar-like pain and turned out the iPhone basic development tutorial with almost no crease. While waiting for Xcode to download, I made up my mind: recite if I don't understand.

Later, I found that the stupid method worked at least for me: code according to the book, and then close the book and type it again if it is normal. Usually repeat it four or five times and you will remember it firmly. When I closed the book, I skillfully knocked on the code that I didn't know what it meant, and Xcode's automatic completion was very powerful. In a few minutes, I can write a large screen color code and run it on the iPhone. At this time, I will have the illusion that I can already write an iPhone App, which is very wonderful.

The human brain is also wonderful. If you recite it, you will slowly and automatically understand what you don't understand. After reciting one piece of code after another, you suddenly find that I understand what is 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 realize one, I am ecstatic: I can display the button! I can pop up a dialog box! I can write a scrolling list! I can send a push message! ?

After mastering, these things may be as plain as drinking water, but they can bring great happiness to beginners. I have always felt that whether you can always maintain the enthusiasm and concentration as a beginner determines how far you can go and how well you can do a thing.

Because the Xcode version used in the book is different from mine and some printing errors, the code in the book will not always run at 100%, and sometimes it will report errors. You can only try your best to search online. In the process of searching, you will gradually see some specialized technical forums and blogs, and eventually you will find the magical website Stack Overflow, where most of your questions can be answered.

When the realization of the functions in the book can't bring ecstasy, you can't help but want to release all kinds of ideas that have been bound for a long time, and finally you can do it yourself, instead of being limited to drawing prototype drawings, writing demand descriptions, and finally wiping the magic lamp devoutly, calling on the lamp gods to take the spirit and make products in this way.

The process of development is full of fun for me, because when writing code, the world becomes simple and beautiful. You don't need to guess repeatedly by yourself, and you don't need to argue with anyone. The compiler is the sacred judge. Every operation can get timely and clear feedback, and there are almost extravagant opportunities for trial and error. From this perspective, the fun of programming is a bit like playing games.

Of course, you will encounter countless problems. Stack Overflow, Github, Bitbucket, and mailing list will gradually become your friends.

After I was able to write an iPhone application and put it on the App Store, I found that I still need to learn another language to develop websites and RESTful Web services that need to be called in the application. So regardless of the age of 35, I suddenly came up with the idea of Python. With the experience of learning obj-c, I know that the key is to calm down and calm down. In fact, it doesn't make much difference what books I read, so I use the free "Learn Python Hard", followed by the method mentioned above (the first half is relatively simple, I can do more than a dozen exercises every day, and the speed may be slower later). After learning how to write Python, I immediately started reading Django Book 2.0, and only saw Chapter 9. I couldn't wait to do the Django tutorial twice in the same way, and then I was surprised to find that I could write a simple but complete website. Then I quickly tried to write a very small tool website for a vertical field with Django. I ran online for a while, ended my free trial last night and started charging. Now it is gratifying to see that there are several paying users.

As for how much technology needs to be understood, I think it takes you a few months to learn something, and you can use it for a lifetime. This business is so cost-effective, especially in the technical field, you will definitely need to continue studying. But for me, I am no longer qualified to study as extensively as young people in their teens and twenties. At present, my principle in this matter is very utilitarian: if you need it immediately, you can significantly improve efficiency or learn as a best practice, otherwise you will not learn first and try not to toss.

For example, if you put the written code on the server, it will be deployed successfully as long as it can run, but it is recognized that the best practice is to use virtualenv to isolate Python environment, which can reduce a lot of troubles in the future, so it is worth spending more time to understand and apply it; Automated deployment using Fabric and Git 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 as a cache to improve application performance; Or use rabbit Mq and celery as asynchronous queues, which can improve the uncomfortable feeling brought to users by synchronous execution of long-time tasks; And Node.js seems to be more suitable for RESTful API than the traditional Web development language? However, these are not the most urgent problems at present, so although I can't yet and will certainly be useful, I won't study them yet.

I accidentally sprayed thousands of words. Let's stop. It seems that the verbosity of middle-aged men is hopeless.

Finally, to sum up, just one sentence:

Product managers know technology = hooligans know martial arts. If you think the gang is big enough and the brain is good enough, you can be a master, and you can make do without martial arts; It's a pity that he is a rogue who has no team spirit like me and always likes to be alone. He also hopes that he can even practice self-defense with his brain, so I'm afraid he can be easily beaten into a reptile.

The more serious conclusion is that product managers know technology, they can do things at the lowest cost when they have no resources, and they can use resources more efficiently when they have resources.