AI Product Manager Fundamentals: A Complete Methodology and Practical Workflow for Requirements Research

Title

AI Product Manager Fundamentals: A Complete Methodology and Practical Workflow for Requirements Research

Meta Description

How can AI product managers conduct effective requirements research? This article breaks down the requirements research methodology from a Bilibili AI product manager tutorial, covering three core stages: requirements collection, weight evaluation, and requirements analysis, while analyzing the unique challenges and practical key points of AI products in requirements research.

Article Content

One of the biggest differences between AI product managers and traditional product managers is the higher uncertainty of requirements. When a user says "I want a smarter recommendation," what exactly does that mean? Can the model capability support it? Where does the data come from? If these questions are not resolved during the requirements research stage, what follows will be a bottomless pit.

There is an AI product manager tutorial on Bilibili that has been recommended by many practitioners, claiming to cover the entire process from architecture design to development acceptance. This article focuses on the starting point—"requirements research"—and provides an in-depth breakdown combined with real work scenarios.

What Is Requirements Research: Breaking It Down

The tutorial offers a very simple but effective way to break it down: understand "requirements research" by separating it into "requirements" and "research."

Requirements refer to users needing some kind of help in certain aspects to achieve their goals. Research refers to understanding the truth of something through certain methods, and can also be called investigation and study.

According to this logic, requirements research means understanding how to satisfy users' specific needs through investigation and study. More completely, it is a process of exploring the essence of things through observation, interviews, and experience.

This definition looks simple, but it emphasizes a point that is easily overlooked: the purpose of requirements research is not to "collect what users want," but to "figure out what problem users are truly facing." This is especially true for AI products, where there is often a huge gap between the requirements users express and the requirements that can actually be satisfied by technology.

The Three Core Stages of Requirements Research

The tutorial divides requirements research into three progressive stages: requirements collection, weight evaluation, and requirements analysis. Each stage has clear outputs and objectives.

Requirements Collection: Building a Requirements Pool

The first stage is requirements collection. Through methods such as interviews or questionnaires, we can collect the requirements we want to obtain, and then build a requirements pool to store these requirements for access at any time.

The concept of a requirements pool is especially important in AI products. This is because the sources of AI product requirements are very scattered—they may come from feasibility feedback from the algorithm team, scenario demands from the business side, or behavioral data insights from users. Without a unified pool for management, it is easy to fall into a situation where "whoever is loudest gets their requirement done."

In practice, requirements collection for AI products also needs to pay extra attention to a special type of requirement: data requirements. For example, "we need to annotate 5,000 dialogue samples to fine-tune the model." Such requirements are often not managed as "user requirements," but they directly determine whether the product can be launched. It is recommended to mark data dependencies separately in the requirements pool.

A requirements pool is a container used in product management to centrally store and uniformly manage various requirements, usually carried in spreadsheets or professional tools such as PingCode, Jira, and Airtable. Each requirement records fields such as source, description, proposer, time, and status. Its core value lies in transforming scattered, verbal demands into traceable structured items, avoiding omissions and duplication. In AI products, the requirements pool also needs extended fields to adapt to new characteristics: for example, adding "dependent data type," "model capability requirements," and "expected performance metrics," so that the algorithm, data, and business teams can align their understanding on the same sheet. Without a requirements pool, teams easily fall into passive response, cannot accumulate a full picture of requirements, and find it difficult to make horizontal comparisons and trade-offs during version planning.

Weight Evaluation: Prioritizing

After the collected requirements are stored in the requirements pool, each requirement's weight will be evaluated and then ranked. The higher the priority, the earlier it will enter the design and development stage.

Weight evaluation for AI products has one more dimension than traditional products: technical feasibility. Even if a requirement has high user value, if the current model capability cannot reliably support it, forcing it through will only bring a poor experience. A common practice is to introduce a two-dimensional matrix of "feasibility × value," dividing requirements into four categories: high value and high feasibility (do immediately), high value and low feasibility (pre-research), low value and high feasibility (schedule to do), and low value and low feasibility (abandon).

Technical feasibility in the context of AI products usually refers to whether the current model capability, data reserves, and engineering resources can reliably support the implementation of a requirement. It is not a binary judgment, but a continuous spectrum: from "the existing model can be used directly" to "fine-tuning or new data is needed" and further to "breakthrough research is required." During evaluation, dimensions such as model accuracy, response latency, cost, robustness, and data annotation difficulty need to be considered. The common "value × feasibility" matrix divides requirements into four categories, helping teams direct limited resources toward directions with the highest return and fastest delivery, while also establishing a pre-research track for high-value, low-feasibility requirements so that future opportunities are not completely abandoned because of short-term infeasibility.

Requirements Analysis: Filtering Out False Requirements

Requirements analysis involves decomposing and analyzing requirements, thereby filtering out real requirements, avoiding false requirements, and at the same time providing a foundation for subsequent product design.

"False requirements" are especially common in AI products. When a user says "I want AI to help me write weekly reports," it sounds like a requirement, but after digging deeper, it may turn out that his real problem is "spending too much time organizing work records every week," and AI writing weekly reports is only the solution he imagines. The real solution might be automatically recording work logs rather than generative writing.

The core action of requirements analysis is to keep asking "why" until the essence of the problem is found.

Final Output: Research Analysis Report

After the three stages are completed, a research analysis report will ultimately be produced, detailing a summary of product-related descriptions, value, and risks.

This report is the foundational document for subsequent product design and development. For AI products, the report usually also needs to include: a description of model capability boundaries, a data preparation plan, and effect evaluation standards. These contents rarely appear in traditional product research reports, but they directly determine whether an AI product can be delivered on time.

A description of model capability boundaries is used to clarify on which tasks the current AI system performs reliably and in which scenarios it is prone to errors or unable to handle them. It usually includes accuracy on the test set, recall, types of false positives, and known failure cases. A data preparation plan describes the data sources, collection methods, annotation specifications, privacy compliance requirements, and timeline needed to support the product. Effect evaluation standards define how success will be measured after the product goes live, such as task completion rate, user satisfaction, and human intervention rate, and set quantifiable target values. These three items make technical uncertainty explicit, help all parties reach consensus on risks before development, and also serve as the basis for subsequent acceptance.

Why Requirements Research Is More Critical for AI Product Managers

In summary, requirements research is the beginning stage when a requirement is born, and the accuracy of the research determines the overall development path of the product in the later stages.

For AI product managers, this statement carries even more weight. Traditional product requirements are relatively certain—if users want a button, then build a button. AI product requirements are naturally vague: model outputs are unstable, user expectations are uncertain, and technical boundaries are changing rapidly. If the problem is not clearly defined during the research stage, all subsequent architecture design, development, and acceptance will be built on quicksand.

This Bilibili tutorial places requirements research at the starting point of the entire process, and that approach is correct. The subsequent architecture design and development acceptance stages are essentially answering the same question: has the problem defined during the research stage actually been solved?

One-line Summary

AI product requirements research should be broken down into collection, evaluation, and analysis, with extra attention to technical feasibility and data dependencies.

Paragraph Summary

Using a Bilibili AI product manager tutorial as background, this article provides an in-depth breakdown of the requirements research stage. It first defines requirements research as exploring users' real problems through observation, interviews, and experience, rather than simply collecting requirements. It then details three progressive stages: requirements collection requires building a requirements pool and separately marking data dependencies; weight evaluation introduces the dimension of technical feasibility to form a "value × feasibility" matrix; and requirements analysis filters out false requirements by continuously asking "why." The final output is a research analysis report, and for AI products it must also include model capability boundaries, a data preparation plan, and effect evaluation standards. The article emphasizes that AI product requirements are naturally vague, and research accuracy determines the success of subsequent architecture and development.