yesterday
In product development, we all face the problem of constantly changing requirements, which is not only painful for the product manager, but also for the R&D team. For example, if a request is coming from your boss, it may have to be done right away. And it is all in, as soon as possible, and the product manager should do as soon as possible to sort out the requirements into the product plan, and cooperate with the developers to complete the plan completion time, and promote the timely launch
When the requirements involve user experience, it is also necessary to communicate with THE UED department to complete the communication and negotiation of design time.
A product friend once told me about his case, and he said, “Because you’re on a zero-to-one project. So 2-3 months is inevitable in the planning. Because it is an app, or even IOS, it may take longer to review and apply for an account after the release.”
However, after the planning, we started to enter the research and development process as shown in the figure below. We began to plan resources. As a result, the boss’s highest priority requirements were temporarily inserted, resulting in the need to readjust the planning and focus resources on the newly inserted requirements
Better yet, we can choose to reuse such code structures, modifying only the front end as much as possible. The bad case is that we might be able to write all of our own is the fastest, but I believe the second bad case is common
Finally, the team enters the stage from 0 to 1, the technical team is thinking about the review again, and the product enters the demand research and product planning again. This repeated cycle, with no output and no growth in users, forced us to reflect on whether we came to this company for a dream or for a monthly salary.
In the growth of the enterprise, there must be a main core profit item. The department of the enterprise also has a main person responsible for the business direction. However, only relying on a certain business direction cannot support the growing market demand, so we try some transformation or even cross-border business, different new business has become the direction of continuous promotion of the enterprise
These are typical examples of innovative projects, unicorns, and start-ups. However, you will find that the truly competitive and business exploration process under the enterprise must have their own thresholds and technical barriers.
It may be the resource barrier of the industry, or it may be the technical barrier, but it just hasn’t found a way to cash out.
If you are in one of these companies, I suggest you continue to experiment and grow with the company, not only to learn more about the 0-1 direction, but also to learn more about the case and product planning boundaries.
When we officially went from 1 to 100, we started to get business demands for our products on the operational side and even on the partner side. Business requirements can be broken down into
After demand disassembly, continue to do product planning. But how do we balance business priorities? We were probably developing with a team of 10 people and two tests.
It’s impossible to get fat all at once, which is why we have a process: prioritizing needs
Following the above process, we can quickly summarize the importance and urgency of requirements. Of course, the business self-interest associated with the business needs may be a matter of resources or human resources.
I shared a previous post about the priority rating
Background product difficulties, need < EM > superior </ EM >< EM > first </em><em> level </ EM > cleaning
After the priority classification is completed, after the product manager conducts the product planning, we can start to prepare the development time, design time and the final launch time.
This scene is a conversation with another product manager: “Our boss is very keen on user experience, so he has to pay attention to the front-end experience.”
When I heard this, I first thought, is it the boss’s subjective grasp of front-end UE?
For example, a popover looks like this. We thought red would be better for the popover, but the boss thought yellow would be better.
This “boss demand” can drive product managers crazy and out of control, but it’s easy to check in with your boss before you go live.
But when my product friend gave the following example, I found that it was not the boss’s subjective problem:
The pickup button should be bigger, so I think the demand is good. It is caused by the lack of experience and cognition of product managers and designers.
This type of boss need is not to “disempower” the product manager, but rather to fail to take the user path and main interface design seriously.