Product managers and programmers have always been like fire and water. Many young developers starting out in the world have probably thought about picking a fight with a product manager.
But the bad thoughts can only depressed in the bottom of my heart, or will be product managers through a series of gripper to demand the underlying logical reasoning, thinking and combining with product, user, consciousness and cultivating the mind on the concept of combination of directly alignment directly under your leadership, abstract to concrete problem into different granularity of methodology, to form the dialectical closed loop, You don’t have the strength of your hand.
When I first entered the workplace, I also experienced several big scenes where I wanted to engage in verbal warfare with product managers. I wanted to engage in dialectical materialism without getting drunk. Later thought, or not, no need, mo angry.
So here are seven of the most annoying product behaviors that programmers find annoying.
1 Requirements documentation is not perfect
As the saying goes, code goes first. This means that the code developed is not created out of thin air, but is designed and implemented around the requirements document. Especially business-oriented technical teams.
In this process, the first arena where r&d and product managers fight is the requirements document, a battlefield full of smoke and ghost.
The foundation of a good product manager should be able to produce a thorough and detailed requirements document that describes the background purpose of the requirements as well as the details of improvements, while proposing key solutions or compatibility solutions on the product dimension.
It is possible to highlight the changes as clearly as possible, reduce the cost of understanding the different roles, and allow the r&d to design the technology around this document, which is probably a complete document.
But in reality, many product documentation is not as good as it should be, either completely immersed in their own expression and missing the point; Either you talk a lot, or you’re demanding details that don’t really matter.
Encountering such requirements documents often means endless validation, debate, and cost trade-offs. Ultimately, it affects the experience of the person in charge of each node in the development process.
Some people may feel that the requirements document proposed by the product is to be discussed with the development to come to a final, refined version. I think this view is completely irresponsible of the product and can be further discussed in the requirements document.
But the premise must be that the documentation is perfect, is the need for product managers to stand on the dimensions of the product to think and precipitation. Instead of relying on someone else to fill in the gaps.
2 Requirements are changed repeatedly
I believe this is the most disgusting thing for everyone involved in the requirements drive. In my opinion, the degree to which requirements change is directly related to the ability of the product manager.
In many cases, regular requirements have already entered the development stage, and even near the completion of development, the product manager always discovers the irrationality of some functions or changes by a strange combination of circumstances, thus wanton initiation of requirements change, or even repeated requirements change.
Repeated changes in requirements not only affect the overall efficiency of requirements drive, but also may lead to poor development quality and misalignment of multi-party collaboration. It may be just a matter of workload, but the impact is widespread.
From the perspective of development, I think as a mature product manager, we should be able to confirm all the requirements before the development intervention or the early stage of development, and be able to get through all the doubts and resource support, rather than think of successive ones.
I’ve seen a lot of products that can’t stand being questioned, and when they do, they change requirements to avoid controversy. This kind of behavior is really beyond ridicule.
Lack of focus on requirements
This point may be directly related to personal responsibility. The lack of focus on requirements means that product managers are no longer interested in the progress of requirements once they are live or even in development. Even after the requirements document is produced, it is as if the task has been completed.
Many product managers tend to follow multiple requirements synchronously, each of which may involve a different developer. Therefore, when there are too many requirements, some of them are ignored.
I’ve seen a lot of product managers leave the requirements development process behind once they’ve perfected the product documentation, or pushed through requirements reviews. When some need to communicate bottom-saving strategies or trade-offs, the enthusiasm is not high.
This is probably one of the biggest headaches for developers.
4. Project cost is not considered
“I can’t do this” must be one of the most common phrases among programmers.
A lot of times when a product manager comes in and says we need to implement a requirement, we politely say, it can’t be done.
Obviously, it’s not that we’re developing to be lazy, but a lot of the time, there are features that just aren’t possible based on the state of engineering and the cost of the technology.
So every time a product changes like this, we get a headache. When we make it clear that it is technically impossible, it may cause product dissatisfaction.
A lot of times we say that technology is for business, and it doesn’t make sense to be outside the business architecture. But the reality is that a lot of times the state of the technology just doesn’t allow the product to go anywhere. So the product is not to achieve its own purpose regardless of the technical status and engineering cost.
5 Compress demand scheduling
Generally in big factories, they follow the so-called “process, light human” rules. That is to say, in the process of project or requirement development, more rules are based on the process, including the various nodes in the R&D stage, such as requirements review, technical review and development estimation schedule.
The actual development time required by the project is comprehensively considered through the status quo research and implementation cost of the project, rather than the development cycle imposed by the leader or product manager.
Of course, this is only the most ideal situation, the big factory volume so serious, largely because some functions do not comply with the rules of the process.
Product managers may break through the restrictions of process rules and squeeze the schedule of projects or requirements crazily when they come on holidays or compete with competing products.
This results in changes that would normally take a month of development being compressed into two or even a week. The result is a sudden increase in staff stress, a sudden drop in the development experience, and a gradual “mountain of shit” on the project.
Blind pursuit of hot spots, lack of advance planning for holidays, and focus only on product competition can lead to a development process that is virtually empty, resulting in product managers acting recklessly in order to meet demand.
6. Pile up experimental variables forcibly
For a large product, the AB experiment is often adopted to verify whether the new features meet user requirements.
ABAn experiment is essentially a control group and an experimental group in junior high school biochemistry. Then control variables are used to verify whether a change has a benefit.
There is nothing wrong with validating requirements in this way, but control variables can often be abused.
For example, if you want to verify a button color with the best user experience, the only variable in the AB experiment is the color of the button, and then different colors can be used as different experimental groups. Finally, which experimental group has the best data can be recycled conclusions.
But with so many colors, how do you choose them? A product manager with little experience in product design might try to list all the colors for verification, and lack judgment and screening.
In fact, this is a very common problem, because the product does not know what the user wants, so in requirements development will choose to stack or permutation of all experimental variables.
This may not seem like a problem, but too many combinations of experiments can lead to high development complexity and severely affect the logic and architecture of the business code.
Therefore, I think a good product manager should be able to have his own judgment on product tonality among the experimental variables of permutation and combination, and screen out variables that are really worth experimenting with. So that the net benefit is maximized.
Ignore experience, data is king
In my opinion, product manager is an emotional and artistic position, but in the process of rapid product iteration, it is impossible to measure the value of products from the emotional and artistic perspective.
Therefore, rational quantitative standards will be introduced to measure the development level of products in the actual demand iteration process. We know DAU, MAU and so on.
Increasingly, many requirements may be made to improve one metric, and the criteria for evaluating whether a change is worthwhile is whether it has an impact on the core metric.
Over time, you get caught in the data trap.
Some changes have some requirements, and the final experimental result may have a good improvement in the index, but it may not be a good product experience.
Data itself is the induction and arrangement made by historical quantification, and there is no way to fully represent or predict the future. Therefore, the data can only be used as a prior reference, but not as a standard completely.
We all say that good product managers tend to be extremely restrained. There are many good ideas, but few that are truly valuable and worthy of acceptance.
Although product manager is not a very pleasant role in the majority of programmers, it is a joke. In many cases, the conflict between production and research depends largely on one’s ability and working level.
In fact, a long time ago, when I was a freshman, I almost became a product manager. It was an innovation team recruiting, and I went for an interview even though I had never learned C. But I don’t know the difference between each position.
That is, until I noticed the product manager position and said, “That sounds like a manager, a big man, probably in charge of programmers.”
Therefore, I applied for the position of product manager with full expectation. But it didn’t pass, or I might have made another life now.
In the end, as the most important role in the whole project process, the product manager’s ability to work will largely determine the overall progress of the project.
Hope in the process of cooperation and cooperation with the product, a little less routine, more sincere; Less blame, more responsibility.