Geek University Product Manager Training Camp: Lesson 12 Summary of Requirements Review

Lecturer: Qiu Yue

1. What is a needs review

  • Definition: Explain to all stakeholders what to do and why, mobilize input, reach an agreement, and start work.
  • Three considerations: what impact will be received, what benefits will be received, and what input is required.
  • Stakeholders: development (engineering & design), resources (business & finance), users, related parties.

2. Purpose and form of needs review

  • Purpose:
    ☞ Define clearly what is to be done; what is expected to be invested as much as possible? Try to analyze the consequences as much as possible.
    ☞ Brainstorm issues, impacts, and risks to prevent the limitations of the product manager and choke the problem at an early stage.
  • Format: documents, small communication meetings, large-scale presentations, and send PRD to related parties for 10 minutes to see and standard comments, and then review (Amazon, ByteDance).
  • Involved personnel: development, testing, design, project management, business, users, fiscal and taxation laws, decision makers...
  • Outputs: (almost unlikely ) unchanged requirements documents, project (preliminary) plans, expected inputs and benefits.

3. Requirements review process

3.1. Background & current situation & problems

  • Specific story
  • real data
  • Relationship with the overall planning
  • Relationship with other issues of the same level
  • Approximate input and output

3.2. Demonstration plan

  • This is the core link and the link that is most easily distracted.
  • Handle with the total score total advancement logic:
    ☞ Introduction: general page structure, use case list (total)
    ☞ Performance: specific functional logic, process plan (points)
    ☞ Review: look at the page structure, use case list (total)
  • Constantly attracting questions and doubts, the more questions, the more successful.

3.3. Data indicators and expectations

  • How to prove that you have a deep understanding of this thing?
    ☞ Wei Zhe 3+1 question: If this thing is successful, what changes will the data have, and will they be quantified and indexed?
  • How to prove that this thing was successful or unsuccessful?
  • How to prove that decision-making is not a brainstorm
  • How to ensure that the logic is perfect?

3.4. Impact and harm

  • Everyone should know what they will pay for this and what will be affected by this.
  • If the possible negative effects cannot be collected at this moment, then the project is likely to be at risk of collapse.
  • Judging by people with decision-making authority, there is no end to the dispute over positions.

3.5. Cost & Planning

  • Rough assessment
  • At least the proportion of different modules
  • Approximate possible duration, steps, priority
  • Various possible resource input ranges.

4. Some experience and insights of the needs assessment

  • Demand review is the triumphant song of victory, not the clarion call of charge.
  • Be prepared in advance and don't focus the problem on one [meeting].
  • Appeal to interest, not [communication].
  • (Under the premise of excellent demand) Excellent review: think well in advance, everyone is not distracted, and the explanation is clear.
  • Attitude: Professional, dedicated, and confident.
  • Confrontation in the needs review: keep the goal in mind, recognize the motivation, correct mistakes, and discuss offline.
  • There should be follow-up after the review.

4.1 Product release link

Demand analysis --> product design --> demand review --> completion of construction --> release and online --> operation iteration

5. Product release link

  • Participate deeply in the release process of development, and pay attention to whether there are strict step dependencies and pre-work for data migration.
  • If it involves downtime, communicate with users in advance; if it involves other systems, communicate in advance.
  • Prepare to verify use cases: roles, scenarios, environments, operations, results, database performance.
  • Contact information and backup list of all relevant people.
  • Respond to possible failures and prepare solutions.
  • Continuous heartbeat observation after release.
  • Remember to have a solemn announcement (and thanks)

6. Publish Checklist

  1. What are the related products or modules that may be affected by the business logic, and is the product manager/development clearly aware of this release and the possible impact?
  2. Who has the authority to approve the release, and is it clear about this release and its possible impact?
  3. If you need to add an emergency release, do you need to apply for permission, who can you apply to, and can you contact me? If it is released urgently, who needs to be synchronized to?
  4. Do you need to configure some service links in advance, such as the host binding of the advertising system.
  5. Whether database changes are required, and whether the DBA has clearly released and changed.
  6. Whether it is necessary to correct or migrate historical data, and whether there is a rollback script for the database change script.
  7. Whether there is a code rollback process, which systems will be affected by the shutdown, and whether the person in charge of the system is aware of it.
  8. Publish whether downtime is required, which systems will be affected by the downtime, and whether the person in charge of the system is aware of it.
  9. Whether it can affect users, whether to hang up the notification. Is the service department aware of this release, and whether Call Center has made a unified statement.
  10. Is there a sequence of different modules for the release, and is there a clear release plan?
  11. Are there key personnel on leave and what is the backup plan?
  12. Has the release notice been written, and whether it has been copied to all relevant personnel.
  13. Don’t add an exclamation mark in the announcement notice, and don’t forget to thank you in the announcement notice.
  14. Is it related to money, whether financial and legal affairs need or are already clear about this release.
  15. Will it be high and notify the PR?
  16. What external services are relied on, and whether the interface person of the external service is aware of this release.
  17. Have you borrowed someone else’s server? Will it have an impact on other services on the server?
  18. Is there UGC, and there is no content risk.
  19. Do not post on Friday. If you must post on Friday, determine the person on duty on weekends.
  20. Is it buried?
  21. Go to the speed test website to see if there are any networks or regions that cannot be connected.

Team management books:

"Leadership" Ram Charan
"Grove's First
Lesson for Managers " Grove "Bedtime Stories for Managers" Henry Ninzberger

Guess you like

Origin blog.csdn.net/zgpeace/article/details/114454861