preface
Believe that a lot of research and development of junior partner for product managers have higher expectations, particularly in terms of demand management, because most of the meaningless to work overtime, basic it is demand management chaos, as a product manager, effective method of management requirements must be clear, is also of its own should have relevant skills.
Note: The main content of this article is compiled from the book From Idea to Product, but it has been simplified to make it easier to understand and get started.
Lifecycle of requirements
Phase of obtaining requirements
Records at any time
Whenever you hear any requirements, you need to record them for easy sorting and backtracking, even if it’s a one-sentence requirement.
Of course, for serious product managers, there is a more technical term called “product requirements pool.”
Determine the importance of requirements
Have a preliminary judgment of the importance of the requirements themselves, and can simply classify them according to new features, experience optimization, abnormal bugs, functional bugs, etc.
Generally speaking, the highest priority is the bug caused by the mainstream online business, which will lead to the main process blockage or the loss of user rights and interests.
And the lowest priority for some insensitive text display, user experience is agile, convenient and so on.
Consider sources of demand
When a requirement is received, it is important to consider the impact of the source on the requirement itself, whether the source is a real requirement from the user, or whether it is limited to the conjecture of the development team or superiors.
If the parts are not required by the users, you can ignore them.
Understand the background of requirements
The requirement background is why this requirement is done, and there are three main types of requirements that should not be met:
- Not giving a clear reason
- Can’t articulate the logic of the requirement itself
- Do not meet the real needs of users, just intention
Note: Always remember that it is more meaningful to figure out if a need is meaningful than to act on it directly.
Demand for the CARDS
When you receive a requirement, you need a good record, so this article provides a requirement record format to quickly organize the valid requirements you have collected.
| Name of demand | One sentence description of requirements (in 5W3H basic format) |
|---|---|
| Demand background | Detail what the requirements are and what they are intended to solve |
| Requirements describe | For this requirement, rough requirements segmentation, there are several segmentation requirements |
| precondition | Conditions met |
| postconditions | Conditions to be met for subsequent operations |
| The solution | Provide solutions for each segment requirement |
Discussion and design phase
The requirements in the requirements pool should be discussed at regular intervals and then prioritized. The default priority ranges from P0-P3.
| Requirement priority | describe |
|---|---|
| p0 | Urgent, critical needs that must be met and cannot be deferred |
| p1 | Major process features or serious bugs, must be completed, the split part completed |
| p2 | Do not affect the main process main business bug or function, strive to complete, time is not enough, can be postponed |
| p3 | Interactive experience optimization, copywriting optimization, do not require, can be postponed |
Note: In project management or testing, the priority of reference should be set according to the priority of requirements to make the whole process more controllable.
Four quadrants of urgency and importance
Important and urgent first, important and not urgent second, unimportant and urgent third, unimportant and not urgent last.
The KANO model
Evaluate from an emotional point of view how a need is, whether it is a must or an option.
| With/without | happy | It doesn’t matter | Not happy |
|---|---|---|---|
| happy | contradiction | pleasantly surprised | Looking forward to |
| It doesn’t matter | error | Has nothing to do | necessary |
| Not happy | error | error | contradiction |
Draft plan
Follow up the first stage requirement cards and provide product interaction solutions for each segment requirement
Specify responsible persons and time nodes
Assign a product owner for each requirement, which can be divided by module, but is not fixed. Provide a deadline for the specific implementation of each requirement, and move to the next stage when the requirements are refined enough to be developed.
Therefore, you need to add the requirements leader and the deadline for the first draft of the requirements to your requirements card.
The original link
How to become a product manager