For programmers, the biggest fear is bugs, which is the biggest reason for arguments between product managers and programmers. But many programmers are reluctant to adjust or change, in this case, what can product managers do?
01 Bug generation
99.99% of developers will be asked or complained about: "Why is your program buggy again?"
At this time, only the development himself understands: "Lao Tzu made a high-level mistake".
But he will feel embarrassed to say it directly.
In the end, I can only echo Haizi's verses in my heart: "You have laughed again and again, you must know that he has fallen above you." ”
This psychology makes sense. Because the complexity of the code is directly proportional to the probability of generating bugs, and has the effect of "diminishing marginal utility".
This means that the benefits of doing more verification are getting smaller and smaller.
So the responsibility of testing is huge.
When I led the team, I said to the test: You must have confidence, you are the goddess of justice: one hand scales, the other hand holds a sword, blindfolded to maintain inner justice.
So how do you reduce bugs at the root?
On the surface, the bug came from a programmer. But the complete steps of this matter are divided into 3 steps, just like building a house, you can see at a glance:
- Discuss and identify features with the product manager (identify design drawings that can be achieved in a house)
- Abstraction of each individual element (determination of the construction plan)
- Realization and combination of related components to complete construction (start construction with materials)
Let's take a closer look at these three steps: The first step, "discuss and determine the feature with the product manager", is mainly communication, relying on "seeing" and "understanding". Communication is mutual, and it's really too aggrieved to let the programmer recite this pot.
Unless you say that the product manager's PRD is flawless.
Let's be more specific, let's look at a small example:
In PRD we say update, but in fact the development is to use the insert after deletion. At this point, the product manager will notice that the data appears to have been updated, but the "creation time" has also changed. Therefore, you need to at least agree on the "update time" and "creation time" to avoid the implementation of the development from being deviated.
The second step is to develop the PRD, and the thinking behind it is to "abstract each individual component", which is mainly the embodiment of a person's abstraction ability.
Abstraction is the ability to "see the essence through the phenomenon". The more information you have, the stronger this ability will become, but it will never really reach 100%.
So, when the development has not so much information, is it not so abstract and reasonable?
Unreasonableness will not directly cause bugs, but it will be more likely to cause bugs.
- That's why it's so important to have a poor background and a scenario. Because "background" means "extended and compatible", it is exhaustive to think of this as "logic and judgment".
Behind mastering an ability, there are countless bugs. Either you have stepped on it before coming to this company, or you have stepped on it in this company. Therefore, the salary of experienced experience is also higher than the latter. Tuition is not the same.
At this level, product and development need to grow together. The way is to review, every accident, to do "four do not let go", one of which is the growth of stakeholders.
Expect not to fall into the same pit twice.
On the other hand, if you are too demanding and there are no bugs, it is equivalent to killing everyone's opportunities for growth and overdrawing the possibility of the future. People can become very conservative and afraid to try new things.
The third step, "realize and combine the relevant components to complete the construction" is the actual coding process, and coding is a subjective and completely subjective thing controlled by people. That's why technical seminars and expert arguments are needed.
Because even the pig killing is the first knife from the buttocks, the implementation of the same code, different teachers teach different languages, and their own cultivation is different in the later stage, and they may not be able to find the best practice path.
For example, there are three types of development in the video below:
02 Development: You see, the code of well-known manufacturers is also bad
Last month, the company hired two P6 backend developers. This level is quite "panda" in the team.
However, a week later, the two left one after another: the original code was too messy.
Subsequently, one went to Ali and the other went to Tencent.
After a while, I chatted again, and the one who went to Tencent said: Tencent's code is not much better, Balabala.
Even though he said that, we felt that the code over there was still of higher quality, like the moon abroad.
This story, in addition to the advantages and disadvantages of the platform, also shows a normality: iron-clad code, flowing development, and everyone's back kitchen is the same.
Even in companies like ORCAL, programmers complain, "I'll never work for Oracle again!"
A programmer with the nickname "oraguy" complains about the Oracle database code. It is to the effect that:
Oracle Database version 12.2 has nearly 25 million lines of C code.
It's not possible to change a single line of code without breaking thousands of existing tests.
Generations of programmers have written this code for a limited period of time, and it's filled with junk code.
Very complex logic, memory management, context switching, etc., all connected by thousands of flags.
The whole code is full of mysterious macros, and it may even take a day or two to really understand what a certain macro does.
Sometimes you need to straighten out the values and effects of 20 different flags to predict how your code will behave in different situations, sometimes as many as hundreds of flags!
The only reason this product is still alive and working is because millions of tests!
The end is that it takes 6 months to 1 year to develop a small feature (or 2 years if you add a new authentication mode, such as AD authentication).
The inner consensus of back-end developers is that the key to coexisting with a piece of code is "don't dig deep". Maybe somewhere will be dug up and you will be buried.
Throw a piece of code to Xiangshan, achieve your goal, and just run if you can. The rest of the development is all about tinkering with it, which eventually leads to a miserable overall code.
Vertically, this is true for one company, and horizontally, for other companies. Step into a forest of back-end code and you're on a thrilling adaptation journey.
A developer once said:
- Within 3 months of joining the company, spraying, such a big system, a system of hundreds of millions of PV actually did this, I proposed to do that, do that, you don't bird me, overthrow me, hey, you are all stupid.
- Half a year after joining the company, hey, it seems that what they said makes sense, if you do what I do, there will be those problems, those problems...
- After a year on the job, oh, you can only do this, do this, you are a newcomer, you know a fart, and you still do that and that.
- Two years in the job, oh, doing this, doing it has advantages and disadvantages, you can do that and that on top of that.
Existence makes sense, so understand that back-end development is deep, not pretended!
This deep kernel of back-end development, combined with the extension of smoking or chewing betel nut, also affects the product manager.
While the product manager of Xiaoxian Meat is still showing off cool interactions, debating user experience, and talking about human inspiration, the back-end product manager is thinking about: compatibility, business, logic, architecture, and performance......
Luo Zhenyu said: "Less nonsense, as long as there is an interface to communicate with the world, there is no opportunity to explain."
That's exactly right, but it's often not suitable for the back-end product ecosystem.
Silently, the back-end product manager and technology are closer, and the frequency of spiritual interaction is more coordinated.
The two sides found loopholes and avoided risks together, and this tacit understanding came naturally.
The product manager can't dictate the code. In order for the team not to fall into the pit, reduce rework, and avoid the entire product or team from capsizing, we can only improve the source of demand.
03 Don't bug my requirements
A developer once joked that you can't write the code too perfectly, or you'll be fired when you have nothing to do.
However, I was too worried. From experience, the demand for middle and back office products is endless.
After a year of using a back-end system, the demand is like a river, washing over the product manager and having to make adjustments.
In the life cycle of a product, as long as the business is still there, there is a need to reduce costs and increase efficiency. The system will not go to the point of obsolescence, it can only be upgraded.
Every time we abstract user stories, identify roles, events, and output use case diagrams and state machines, new businesses are also growing.
Moreover, a function itself often only forms a closed loop of small business scenarios, and it is a continuous iteration of requirements.
Examples of specific reasons for continuous iteration:
- Uncertainty: It is necessary to continue to observe and accumulate user preferences. lack of support for user behavior data,
- Step-by-step completion: the construction period is long, and it is iterated in an incremental way;
- The plan was not thought out: it was not designed.
- Transitional state: The user's business mode or scenario is immature
- Limitation of thinking: Not considered.
- Set demand: Gather together to make a big move.
- Resource limitations: Limitations on personnel or hardware resources.
- Other: omitted.
So both vertically and horizontally have to continue. "Go with the flow" or "add fuel to the fire", a large amount of demand is endless.
Product managers want to optimize architecture, unify functions, etc., independently, and their time and resources are squeezed and reduced.
There used to be a company's solution to strengthen the demand to come over the caliber. Here's how to do it:
- Any demand that has no income will not be done, unless the technical director makes a decision (throwing the pot);
- There is a demand for earnings, sorted by the size of the earnings, and only the top 5 are done every week.
- Set up a project team to extract and complete the demand with greater benefits.
In fact, it is essentially to extract a part of resources, carry out independent optimization, overall planning and reconstruction.
The benefits of refactoring are good, but the pressure of refactoring comes from the shackles of trivial requirements.
When resources, time, and quality converge, it is especially important to find ways to win resources for cost-effective projects.
For this purpose, requirements can be divided into five categories, each corresponding to different decision-making attitudes.
04 The demand for iron, the strategy of flowing water
These five types of demand are the author's qualitative division of the demand for B-end or pan-back-end products: shallow demand, gimmick demand, kicking demand, excess demand, and constructive demand.
1. The shallow needs of users
This kind of demand does not go through the brain, and does not consider the compatibility of the system and the compatibility of the business.
For example, in the e-commerce scenario, if the price is 0, it will be decisively removed from the shelves, and if the price becomes non-zero, it will be automatically put on the shelves.
This kind of compulsion is in the direction of the wind, and there are also exposure demand scenarios when the inventory is zero, and there are also scenarios for non-zero to be taken off the shelves. The two are not the same.
In this case, it is actually a fallacy of "concept stealing", no inventory = off the shelves.
For this kind of demand, the product can take a reserved attitude, continue to wait and see, and collect more in-depth data feedback from users. But don't act rashly.
2. The need for gimmicks from the boss
This is a very easy way to understand, and many companies actually don't play like this.
For example, if we see the functions that our competitors have, we must have them, and if we do not have them, we must also have them. This way you can blow.
Or is it a forced "combination innovation": a person who does pharmaceutical e-commerce, and you ask him to do live streaming to bring goods, not to mention whether it is compliant, can you imagine that the pharmacist is an Internet celebrity in front of the store manager in the store?
In this case, it is actually a "feeling fallacy". In theory, the product manager needs to take the data and try to convince the superior, but the actual operation may be limited.
So what the product manager can do is do it slowly and conserve resources. Look for opportunities to slowly infiltrate the opinions at the top. Trying to stop the loss.
3. The need to kick the ball next door
In multi-organizational teams, this kind of kick-and-back is fairly common.
For example, for pharmaceutical products, configure a disclaimer and display it in the mall.
Then let the product backend add fields in the product dimension and pass it to the front-end, it seems to be from the back-end to the front-end, and the product dimension seems to be right. But it's not necessary.
Because this is a common field, the commodity dimension requires little maintenance and no operational variability.
For this kind of demand, the product manager needs to consider the division of labor, system functions, and benefits, and objectively express things to complete the game.
4. Excess demand for customer service
This kind of demand is often the customer service to convey the demand from the user. Usually the purpose is clear, but there is interference with the functional design that may affect the analysis of the product.
For example, the customer service conveys the needs of an O2O user: to display the offline retail price next to the actual sales price of the product.
Product: And then?
Customer service: If you compare the difference, then modify the online price?
Product: How to modify?
Customer service: Calculate according to the formula on the basis of the offline retail price, for example, increase by 1% to get the online retail price, and then edit it one by one.
Product: Can it be understood that the purpose is to sell the online price according to your expectations, not the offline retail price?
Customer Service: Yes
Products: So why not address them at the root: create a set of prices for online sales and quote them directly?
This kind of problem must be excavated into the user's scenario, seeking empathy from the user's scenario, and not being subject to the setting of existing functions.
Only in this way can we find the original intention of the user without limitations. Problem-solving is the standard.
5. Product construction needs
The so-called constructive requirements may be a long-cherished wish in the heart of every product manager. The premise is that the product manager's mind is in their right.
For example, self-optimization of product models, splitting microservices, interface unification, etc., overall planning and refactoring of class content.
If there is too much demand for the first four categories, it will squeeze the constructive demand for the product.
Product managers are freed up to do something really right, often with a big picture.
05 Summary
In the face of development dilemmas, poor code, user fog, resource coordination, etc., product managers need to coordinate strategies and guide the way.
Go the extra mile and fuse the junction of penetration into the PRD!
It is necessary to understand the development trends, opinions, code quality vulnerabilities, the source of requirements, value, urgency, the intention of the boss, the way the market plays, etc., all of which are packed into the thinking ecology of the product manager.
Just as the product has a system, the industry has an ecology, and the world of product managers is also fully ecological. Rather than a peer-to-peer hand-shake role.
As Su Jie said, the product manager should be like the "Rutaceae" fruit, and the PRD should also support multiple compatibility and arbitrary hybridization.
Columnist
Product Ginseng Zhao, public account: Product Ginseng Zhao, everyone is a product manager columnist, 2019 author of the year. Author of "Back-end Product Manager's Manual", Master of Pharmacy has been switching to Internet products for many years, familiar with cross-border e-commerce business, pharmaceutical field, good at large-scale back-end system, social APP.
This article was originally published by Everyone is a product manager and is prohibited from reprinting without the author's permission
The title image is from Unsplash and is licensed under CC0.
The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.