I became a product manager for only 2 years or so, not that long as it sounds, however, the popular role has become so overwhelming not that long ago neither. So what does it exactly mean?

People often like to define a terminology in order to start with a topic, obviously Google or Baidu can be used to find out the exact answer, whereas in this post, I am going to list out the things I concluded from my past experience.

understand the product positioning

Positioning might refer to marketing as it is vital to your customers/audience, I will talk about the relation between product and marketing later on.

Nowadays, we often hear people want to launch a business by building a mobile app. That’s absolutely fine, as we heard so many successful stories around the globe. However, we are already in the post-mobile internet era, where almost every aspect of industries have been transformed into mobile internet and covered by tech giants. There are enough apps for everyone, if some types are missing, then there is big chance that the demand for that types is not exist at all. So when people are talking about building a app for whatever reason, the first question needs to be answered: what exactly the app is all about.

If the product positioning is not clear, customers will confuse, operator will confuse, developer will confuse, eventually, the whole project will collapse.

Answering that question is not simple as it sounds, and sometimes product manager plays a key role in finding out the answer. From my past experience, most people have startup ideas in a general term, and most ideas are drawn from existing products and mix with different aspects of products to form a “New” idea. Don’t make me wrong, it is one of the basic methodology to create things. However, due to the fact that the idea come from other existing mature products, the outcome would likely to be neither fish nor fowl. What is worse, since people wish their ideas work, they gather as many highlights of reference products as possible to minimize the risk of failing. The simple logic behind this sounds totally valid, one plus one must bigger than one, but please bear in mind the old saying, you can’t have both fish and bear’s paw at the same time. As a result, the products normally present in the form of giant monster. Again, building a giant monster may not sounds a too bad idea for startups, but in reality, this results in a serious consequence:

• Giant monster means heavy, big, complex, multifunctional, and resources consuming heavily. Startups normally do not have such resources to build such monster in a short time. Even if they build such monster eventually, they already missed the market opportunities because of the long development period.
• The cost of trial and error is too high to turned the boat around. The limited resources provided in startups often do not allow themselves to fail again over again.
• If the product can not be proven in the right path straight away, startup teams are normally easier to lose confidence. Think of launching the first beta in half of a year or in some cases a year time, by the time they find out things do not work out so well, and the time and enthusiasm they spend in the past, it is not hard to understand how they lose morale.
• Due to limited resources, the quality of products can not be guaranteed, as most developers are focus on complex new features to avoid project delay, normally bugs can not always get fixed on time, which might lead to bad user experience.
• In cases of the products are heavily operation-driven, the operational cost is significant higher for giant monster, every feature in the app need more or less resources to operate, otherwise the monster will look pale and weak when users requesting contents or services. This could also lead to a huge contradiction between the product and operation team. E.g. product blame operation is too weak to operate, whereas operation blame product is too buggy or feature poor to use; operation might even push stress on boss for heavy resource input, which might lead to performance unsatisfaction.
• In cases of the products are sales-driven, although the operational disadvantage is not that obvious, other disadvantages still apply.
• Most importantly, as a outcome of giant monster, it is very hard to define the product itself. Startups usually lose focus, shifting around on different aspects constantly, as a result, none of the features or services provided are good enough to draw attention to venture capitals.

All above I mentioned indicate some real scenario, certainly the failure might not all as a result of a bad product manager, but

a good product manager can minimize risks as many as possible.

I believe the following qualifications should apply to PM:

Good communicator amount cross-functional team.

• Most product idea come from executive level, chances are, they are not product experts, they only have the blur vision or rough idea. Good PM need to understand what the boss really want, even if the boss get confused occasionally, PM need to help with traffic grooming, try to find the real destination and suggest the possible diplomatic route.
• Translate the final product into human language, make sense for all team members, including both product and operation teams. In this case, prototypes need to be presented, since human beings adapt new ideas easily with graphical presentation. In development phase, PM needs to get in touch with developers in real time specially when the Product Requirement Document, PRD is not detailed enough during short development period.
• Understand the operation strategy and work closely with operation team. This is essential for most operation-driven project, because products need to be used eventually to be successful, and users’ feedback is vital for future improvement. Therefore by hearing people’s voice in reality means developers can quickly adjust existing problem before things are too off the track. Not mentioning some features need to be further developed under certain promotion activities, if the PM is not following close enough, they might just miss the opportunities.
• Be kind to developers. Being a good PM is not that easy, and most people describe this role as a hamburger. One side is boss, the other side is developer, PM is trapped between the middle. If the relationship between PM and developer is under rigid, then work will not go smoothly. PM need to do more research in advance and more communication to avoid such awkward situation, specially when they are not a industry expert.

Don’t be a feature manager.

• Most junior PM like to copy features from relative apps, this is pretty straightforward, virtually no skill is needed. There are mature reference apps out there in almost every industry, feature manager simply need to pick up the appropriate features from different samples and put them together becoming a new one, like piecing together a jigsaw puzzle. Without discussing whether this is right or wrong, appropriate or not, work or not, my judgement would always refer this type of PM as in very early stage, calling it feature manager already shows a generous respect, otherwise it is a pure copycat.
• Every tiny feature and design must be followed by comprehensive reasons, there is nothing wrong to draw lessons from other apps, but if the feature is not strongly connected to the mutual goal, then things could easily go wrong and a monster will be set free.
• Always remember subtracting is more difficult than adding, and only difficulties are worth challenging.

Be a dreamer.

• Dreamers are most likely have good imagination, and by presenting prototypes from rough ideas needs imagination. So next time when people ridicule you living in your own dream, you should be grateful as at least you have a good imagination.

To sum up, basically everyone can be a product manager, there is no academic barrier to stop people dreaming what a good product should look like. However, every industry specially involving product development need a PM, this role has large demand but always find hard to fulfill, I think one of the major issue here it is lack of good one. By what I mean is not necessary has to fully justify all the points above, this is only from my 2 years experience in my industry. But what I believe, the principle should apply to most industry, and hopefully this article is useful, and I wish to write again soon.