In most people’s minds, product managers deal with requirements, prototypes, and functionality. While this understanding isn’t wrong, the template shared by the author sheds light on how product managers can truly demonstrate their value.
Recently, I had a brief interview with the head of the retail solutions line at a consulting company. Their team’s management approach really inspired me, and I’d like to share it with everyone.
In this consulting company, product managers are defined by three key responsibilities: requirement management, requirement creation, and requirement implementation.
Here’s a breakdown of each step in detail:
01. Requirement Design
Task 01: Collect Current Issues
Action 1: Communicate issues to the development team. For example, if users report that a field is missing in the export report, the product manager must ensure the developers address this.
Action 2: Receive and discuss requirements with the respective project product managers. For example, when users request a new feature, the product manager discusses feasibility with the development team.
Example: A user reports inaccurate navigation in a travel app. The product manager collaborates with the map supplier to seek a solution.
Task 02: Manage the Requirement Pool
Action 1: Add the requirement to the pool. For instance, if users suggest improving the search function, the product manager adds it to the requirement pool.
Action 2: Manage the schedule for requirements. For example, setting a quarterly or monthly requirement schedule.
In their team, scheduling is strictly followed according to the schedule calendar. For instance, if a one-month period includes two bi-weekly iterations, all requirements are scheduled according to these iterations. Any issues are postponed, but release dates remain unchanged. Even urgent demands, such as data exports, are handled during the next release cycle.
This approach ensures the stability of the product development rhythm, which is incredibly beneficial for consistent delivery.
Action 3: Requirement creation process: Bi-weekly/three-week iterations/monthly iterations.
Complete Process: BRD submission time → Requirement time → Review time → Testing time → UAT time → Release time.
What sets this process apart from many product managers’ workflows is that they require the requesting party to submit a clear BRD (Business Rule Description), which outlines the scope of the requirement. This document prevents unexpected changes or additional demands from stakeholders during the final stages of testing or implementation.
Action 4: Project management software entry: Create iteration files and add product documents.
Action 5: Weekly sync meetings: The team syncs up weekly to review the progress of requirements and ensure smooth workflow across all tasks.
Task 03: Requirement Creation
The requirement creation process is divided into the following five steps:
Action 1: BRD Review. BRDs that pass are added to production; those that don’t pass are not.
Action 2: Write PRD. Use a standardized template in the team for easy understanding and communication (e.g., background, use case diagram, UML, prototype).
Action 3: PRD self-checklist. Compile common challenges from previous reviews, such as field interactions and workflows, into a self-checklist that helps product managers identify potential issues before internal reviews.
Action 4: Formal Review. Organize the formal review with the team.
Action 5: Post-review Debrief. After the review, the product manager organizes a debrief to document modifications and identify issues. Add common issues to the self-checklist to improve future requirement production quality.
02. Requirement Implementation (A Stage Many Product Managers Haven’t Experienced)
During the implementation stage, the product manager ensures that every phase proceeds smoothly:
Action 1: Data Migration: Ensure a seamless transition of data between old and new systems. For instance, while migrating user data, make sure user information and transaction records are intact.
Example: An e-commerce platform undergoes a system upgrade. The product manager coordinates with the data team to create a data migration plan that ensures users are unaware of the migration process.
Action 2: User UAT & Testing: Organize UAT testing to validate whether the system meets user requirements, for example, by inviting typical users to test and provide feedback.
Action 3: Data Acceptance: After UAT passes, perform data acceptance to ensure migrated data is accurate.
Action 4: Follow-up During Migration: During migration, answer users' questions and establish the relevant processes. For example, create an emergency plan for the migration process.
Action 5: Pre-train Users on Key Migration Issues: Inform users of potential problems in the current version and the upcoming iteration plan, managing their expectations. For example, notify users in advance if batch function error messages are not yet optimized and will be resolved in the next update, to prevent dissatisfaction during product delivery.
03. Why is it Set Up This Way?
This workflow has a clear rationale behind it. In many companies, tasks are divided into very narrow roles, which is particularly common in large organizations. However, this extreme specialization can leave gaps in the process.
The most obvious issue is that people only work towards their own KPIs, caring little about the overall consistency of the product. Yet this lack of cohesion is detrimental to any company’s product.
To avoid this, their workflow requires each product manager to deliver two key values:
Value 1: Overseeing Both Creation and Maintenance
Creating a product is like raising a child. Often, the problem isn't the product itself but the lack of changes in business processes. Product managers must engage deeply in the product’s post-launch phase, adjusting business processes to ensure alignment with software functionality.
Value 2: Enabling Product Iterations
Rushing to release software can result in oversimplifications, but software can be iterated. Allowing for some minor issues initially is acceptable, provided these problems are addressed in subsequent versions. This requires product managers to optimize their requirement creation skills, such as using self-checklists to improve iteration efficiency. But it also requires the business side to restrain itself and submit clear BRDs to manage expectations and requirements.
Only when both the technical and business sides work closely together in continuous iteration will the product have the capability for sustained development.
Finally, a thought-provoking question: Does your company’s product manager provide these two values?
