Product managers output product requirements as natural as drinking water and eating, but sometimes they feel that the scheme is a bit too complicated or too entangled in details, so there is a problem of over-design.
In theory, product managers should not make over-designed solutions. Just like a flawed design, over-design also indicates that the scheme is not reasonable enough, and the product manager's grasp of requirements still needs to be strengthened.
But reality does not align with theory, and there will always be some subtile different.
Since I've encountered some subtleties recently, I'm going to talk about the problem of over-design.
1. How to define over-design
As mentioned earlier, one of the cases of over-design is when the complexity of the solution exceeds the need itself.
For example, in the start-up stage of the business, a push system needs to be built. The original requirement of operation is to support the import of user lists and send them in batches. The requirement is very simple.
When creating a plan, you can set the plan name, import lists in batches, enter the content to be sent, set the message type, select the sending account, and set the sending time.
However, based on product design principles, product managers will consider versatility and scalability when designing, and will naturally think about whether to add the user attribute selection feature, whether to add the content template feature, whether to add the traffic distribution test feature, and add statistics module to track performance.
It can be done. The problem is that for a start-up business, the complex feature associated later cannot be used for a long time.
If the program includes these features, there will be an over-design problem. After all, resources are always tight, and there are always more important things to deal with.
In this case, the degree of matching between the scheme and the current business stage is the criterion for judging whether it is over-designed.
Another common case of over-design is that the product scheme is too entangled in the details, and repeatedly adjusts some small things.
A mature business is more likely to have this situation. Mature business means that the overall product framework is also very mature, so how to optimize it.
Just repeated to adjust some details, just a formality, a lot of work has been done, but the effect is very small.
For example, a loan application process (I am in the credit business, take an example that I am familiar with), all the platform product solutions in the industry are similar and very mature.
There are 5 steps in total:
- Fill in basic personal information (marriage, education, address, etc.);
- Fill in the work information (company name, company address, company phone number, etc.);
- Fill in the contact information;
- Upload ID photo and biometric identification;
- Bind the lending bank card (some platforms have it).
The only difference lies in the specific fields, the page order, and the page UI.
The other differences are really not big, and the system support for various marketing has been very mature.
In this case, it is necessary to optimize the application process, which is actually very unnecessary. Doing it is to make some adjustments to the UI and interaction of the interface, but it has little impact on the overall completion rate.
In extreme cases, the natural fluctuations are larger than the changes in the optimization effect.
In this case, we should actually compare it with the industry data. If it is similar to the optimal data, we can put it aside for a while and don't bother.
Really, if a business wants to be completed, it depends on the overall data. It makes no sense that the local data is 3-5 points higher than others.
2. Why is there an over design problem
If this is the first case, in fact, the product manager does not understand the business enough and is not related to the business.
The cost always needs to be considered in business . It is not necessary to invest some costs in advance. It can be invested when necessary.
If it is the second case, it depends.
Sometimes because the product manager‘s thinking is relatively limited and cannot make a good scheme for the time being, he adjusts some small details to ensure that there will be no major problems.
When doing it, the front-line people actually know what is going on, but they have to do it, otherwise the boss will think that the employee's ability is not good.
Don't think this won't happen, it's actually more common than you think.
I want to change and improve every day, but the logic of the real world is not like this. Where can a mature business have things that are improved every day. Every business has a ceiling.
Of course, I have also encountered a situation where the product framework is completed, and the business has passed the stage from 0 to 1, and started to move from 1 to 10. At this time, the focus of the stage is not product and R&D.
But the products and technology staff still can’t stopped. If the products and technology stop work, the company will lose money. The boss can't get through it. Boss must let everyone work.
The focus at this time is to let everyone work, not whether the product plan is too advanced or too detailed.
3. How to solve the problem of over-design
If it is a problem with the limited ability of the product manager, this can only be improved by oneself. The improvement of ability is a process of continuous improvement, but some people are fast and some people are slow.
If it is due to the requirements of the boss or the pressure of KPI, try to communicate with the boss with the scheme of industry data and competitive products, so that the boss can understand that the adjustment of the scheme is of little significance. The key to the problem is not here.
If the boss insists, don't bother, you are not obliged to take responsibility for an adult's choice, even if you got paid.
I know that some product managers advocate changing the world, and insist on persuading the boss if the boss is wrong. I neither approve nor disapprove, but I would never do it myself.
If it's because the technology is going to be idle, then my suggestion is to deal with the historical problems left over before, and do refactoring.
In fact, this job is not easy to do, because it cannot be reflected in performance, so it is difficult to convince everyone to do it.
I encountered this problem recently. The previous technical design framework was unreasonable, and the compatibility and rationality were not good.
However, because the performance could not be reflected, the code refactoring was urged several times and could not be done.
It has been repaired several times, but there are still frequent problems.
I have also encountered a situation where the boss took someone else's background screenshot and told me to refer to it. The implication is naturally to copy it.
I found that we couldn't use many feature for the time being. Of course, I didn't refute it, so I designed a complete solution.
Then tell the boss that the version is too big to make together, and it can be done in separate versions. Some features that are temporarily unavailable can be done later.
As for whether to do it later, it is not a problem at all, the boss will not remember this matter at all.
You may spend a little more time, but you can still effectively master the landing plan.
4. Write at the end
The problem of over-design is far less conspicuous than the unreasonable or incomplete solution. Everyone has different definitions of over-design.
But as product managers, we still have to judge this problem more carefully, which is part of our professional ability.
The product manager is the person who proposes the solution. The quality of the solution directly reflects the level of a product manager.
Try to ensure that the product solution is within a reasonable range, consider various factors, control costs, and include the loss of trust.
I don't think it's possible to completely avoid over-design, but I do need to avoid this problem as much as possible and make us professional.