Senior PMs' Practical Requirement Research Framework: 4 Stages from Collection to Validation

Customers don't want a quarter-inch drill; they want a quarter-inch hole.

In daily product development collaboration, the most common pitfall for product managers is not inability to build features, but accepting a pile of fake requirements that no one uses after launch. Users often propose surface-level solutions rather than underlying needs.

How to filter truly high-value requirements from complex noise? This article systematically outlines a closed-loop practical methodology from requirement collection , fake requirement filtering to solution extraction .

Stage 1: Five "Scalpels" for Requirement Collection

Deeply engage with business and user frontlines; mature research typically combines the following tools:

Field Observation : Enter real work or life scenarios to observe users' natural operation habits, pain points, and compromise behaviors, capturing unexpressed implicit pain points.

In-Depth Interviews : Conduct one-on-one open dialogues with core target users or industry professionals. Key is finding truly knowledgeable, representative samples to explore motivations behind behaviors.

Focus Groups : Organize 6-10 typical users to discuss specific topics, leveraging group interaction to uncover more three-dimensional cognitive blind spots.

Prototype Testing (Beta Feedback) : Use paper wireframes, interactive demos, or minimal MVPs to let early seed users provide feedback in real operations, enabling low-cost rapid trial and error.

Social Media & Public Opinion Monitoring : Penetrate e-commerce review sections (e.g., Tmall, JD, Amazon reviews), vertical communities, and Q&A platforms to directly absorb users' most authentic, unfiltered complaints and expectations.

Stage 2: Fake Requirement Filtering & System Boundary Definition

After collecting massive feedback, the core task is "subtraction" — identifying fake requirements and out-of-scope demands.

1. Business Scenario Restoration: Judging Fake Requirements

Many seemingly reasonable features collapse when restored to specific operation flows.

Case : Operations reported "cash-on-delivery" out-of-stock orders piling up; canceling individually was too slow, strongly demanding a "batch cancel orders" button in the backend.

Scenario Restoration : Customer service must first call each customer to confirm agreement before canceling. Since confirmation is done one by one, single-click cancellation is the natural closure; "batch cancel" lacks landing premise in real workflow, making it an invalid fake requirement.

2. Functional Attribution Positioning: Avoiding System Overreach & Over-Coupling

Reasonable product architecture emphasizes "specialized systems do specialized functions." A demand may be real but not belong to the current system.

Case : Business requested CRM (Customer Relationship Management) to add English tag fields besides generating user profile tags, for European and American teams.

Boundary Analysis : Research found English tags are actually used in downstream SMS (customer service system). CRM's core responsibility is establishing unified basic data. If CRM directly handles all downstream personalized language adaptations, future integration with more systems would cause severe logical coupling.

Correct Approach : CRM only outputs standard basic data; downstream customer service systems perform secondary derivation and rendering based on their own business.

Stage 3: Requirement Splitting, Aggregation & Risk Detection

Facing vague or scattered demands, product managers need structured reconstruction capabilities.

Granularity Splitting : For a one-sentence requirement like "add automatic after-sales order creation for return orders," never start directly. Must horizontally split business scenarios: self-operated vs third-party, pre-payment vs cash-on-delivery, full return vs partial return, differences across category business units, etc., breaking the big package into independently verifiable small modules.

Cross-Department Requirement Aggregation : When different departments propose scattered but similar process optimizations, explore underlying common logic, merge similar items, output generalized solutions, avoiding reinventing the wheel.

Logic Pre-Testing (Mine Detection) : For changes involving underlying data flow (e.g., modifying email binding in historical orders), when uncertain whether it will break subsequent shipping or audit state machines, first design test cases covering states, checkpoints, and data flows, then simulate in sandbox environment to deduce and avoid chain-reaction collapse risks.

Stage 4: Solution Extraction & Value Validation

Transforming filtered real requirements into product solutions hinges on abstraction extraction and ROI evaluation.

1. Exhaustive Enumeration & Common-Sense Abstraction (NetEase Cloud Music "Playlist" Example)

Enumerate Possibilities : Music discovery methods cover active (search, song recognition, charts) and passive (friend recommendations, KOL guidance, algorithmic recommendations).

Focus Breakthrough Point : Target scenarios unmet by mainstream platforms yet with self-propagation potential, determine the focus.

Extract General Mechanism : Use "lists" to aggregate content, introduce "tags" to establish multi-dimensional connections, ultimately precipitating a general function — "Playlist" — actively created by UGC users, maximizing user creativity release.

2. 5W1H1V Evaluation Framework

Before project initiation, use seven dimensions for final gatekeeping:

What : What exactly does this feature do? What direct problem does it solve for users?

Who : Who are the core target audience? Which key roles to prioritize?

Where : In which terminal types or physical/digital scenarios does the feature occur?

When : At what node or trigger condition will users invoke this capability?

Why : Why would users choose us over competitors? Where is the core differentiation?

How : What are the user's specific interaction paths and underlying business flows?

Value : What is the ultimate business value brought by the feature (cost reduction, efficiency improvement, engagement promotion, or moat building)?

Truly professional product research is never about being a passive "feature entry clerk," but finding the core essence amidst chaotic user voices, using restrained yet clear system architecture to deliver long-term solutions with real business value.