Product Managers Solve Real Problems, Not Just Features: A 5-Step Framework with Case Studies

The article opens with a real-estate agent requesting a simple tag to highlight public listings in a list view. The product manager probes deeper: the system already has a dedicated page for public listings, so why does the agent need a tag in the mixed list? Investigation reveals a business rule — private listings automatically convert to public ("跳公盘") after prolonged inactivity. Agents miss the desktop notification because they are out showing properties. The real anxiety is not finding public listings but missing the moment their own listings turn public. The team replaces the tag idea with a mini-program push notification that reaches agents instantly on mobile.

1. Identify the Real Problem Before Deciding What to Build

Product work starts with understanding the user and the underlying business logic. In the listing system, listings are private or public, and also tradable or non-tradable. Agents normally view tradable listings, which mix both types; a separate page exists for public-only viewing. Adding a tag creates no new search capability. The request stems from the auto-conversion rule and the failure of the existing desktop notification. The agent's proposed solution (a tag) reflects their limited view; the product manager's job is to uncover the true pain point: timely awareness of ownership changes.

Comparing the two solutions: a list tag requires the agent to return to a computer, open the page, and visually scan; a push notification delivers the alert directly to the phone anytime. The team chooses the push notification. At this stage the product must document: who the users are, relevant business rules, the scenario where the problem occurs, and why the current solution fails. Without this, discussions devolve into trivialities like tag color and size.

2. Decompose Requirements, Set Goals and Boundaries

Understanding the problem does not mean packing every related feature into the current release. The team must define: which specific problem this iteration improves, which scenarios are covered, and the development cost. Business value, user impact, and development effort jointly drive trade-offs.

In the case study, "ensure agents receive timely conversion alerts" and "optimize public listing search experience" are two distinct goals. The former measures notification delivery; the latter evaluates search flows. Both may have value, but they cannot share the same justification in one sprint. If the core goal is solving missed alerts, discussion focuses on trigger timing, recipients, and usage contexts. A full listing redesign requires separate evidence and cannot piggyback on this effort. The deliverable must state the core problem, the chosen solution rationale, and what is explicitly excluded.

3. Turn Abstract Judgments into Concrete, Executable Solutions

The third responsibility is producing a clear solution and driving cross-functional execution. A second case illustrates this: finance requests full-screen viewing for reimbursement detail pages. The current modal can be maximized, but approval nodes are laid out horizontally, forcing horizontal scrolling; finance also prints each detail for archiving.

Deep diving reveals two pain points: (1) many approval nodes in a horizontal layout hinder reading; (2) printing is cumbersome. The team restructures the approval display: scattered department and store-manager approvals are grouped by store hierarchy, making relationships clear. A print preview is added so users can verify before printing.

This shows solutions must reach operational detail. "Optimize experience" gives designers and developers no direction. Once detailed, new rule questions emerge: after merging nodes, is each approver's status still fully visible? Does hierarchy grouping mislead users into thinking steps were removed? Does preview content match final print output exactly? These cannot be left to guesswork. The product selects appropriate artifacts: flow diagrams for business processes, prototypes for layouts, requirement documents for permissions, states, and edge cases. Consistency across artifacts prevents rework.

Collaboration starts at solution confirmation: business validates requirements, design shapes information presentation, engineering assesses feasibility, testing checks rule completeness. Any adjustment triggers updates to all materials; open items get an owner and deadline. The non-negotiable baseline: conclusions are confirmed, changes are synchronized.

4. Launch Acceptance: Walk the Complete Business Path

Acceptance is not verifying that a button clicks. For the listing alert, it is insufficient to confirm the system sent a message. The product must verify the message binds to the correct listing, reaches the intended agent, and conveys the change clearly at a glance. Trigger conditions and applicable scenarios must match the previously agreed business rules.

For the reimbursement optimization, layout simplification is only one change. The product must walk the finance workflow end-to-end: read the approval hierarchy, confirm each node's status, open print preview, and verify archival print content. A clickable button does not equal a usable business chain.

Acceptance requires product, business, and testing collaboration: product aligns business expectations and judges deviation from the solution; testing performs quality checks; release readiness is jointly assessed by engineering and operations. When defects appear, product evaluates affected users and whether core business is blocked, enabling the team to decide: fix, defer, or reduce scope.

Two often-overlooked launch preparations: user awareness of process changes, and pre-instrumented analytics. For the new print preview, operation guides and business communication must be ready at launch. If post-launch analysis of alert effectiveness is desired, tracking points must be planned during development, not discovered missing during retrospective. The verification questions for after launch need their prerequisites baked in at the requirements stage — this is why the five responsibilities form a closed loop.

5. Review Results, Decide the Next Iteration

The fifth responsibility is observing real usage, reviewing outcomes, and directing future work. For the listing alert, successful message delivery only proves the push pipeline works. Whether agents actually perceive listing changes in time requires combining delivery rates, user behavior, and business feedback — not just sent-message counts.

Similarly, preview page visits only show feature entry, not efficiency gains. The team must return to the original pain points: is approval information easier to read? Does print output meet archival standards? Are there new friction points? Quantitative claims (e.g., time saved) demand before-and-after data with defined scope and task conditions; without data, efficiency improvement cannot be asserted.

Retrospectives split into two tracks: (1) delivery process — review omissions, requirement change causes, communication gaps, external dependency impacts; (2) product outcome — compare actual usage against expectations, assess whether original pain points were relieved. A smooth project with disappointing business results demands re-examining problem definition and solution choice; a successful feature with repeated rework calls for process improvement. Neither can be dismissed with "project completed."

The article circles back to the opening story: the agent wanted a tag; the product manager's first move was to ask why. After the alert launches, the work continues — watching whether the feature truly solves the agent's frustration in real business scenarios. The starting point of a product is the user's problem; the end point is the improvement of that problem. Product management is not a checklist of features but a continuous practice of solving real problems for real people.