Product Managers Don't Build Features—They Solve Real Problems

Identify the Real Problem Before Building

A real estate agent requested a tag to highlight public listings in the property list. The product manager questioned why agents needed this when a dedicated public listings page already existed. Investigation revealed the true pain point: agents' private listings automatically convert to public listings ("jump to public pool") after prolonged inactivity, but existing desktop notifications were missed because agents spend most time showing properties off-site. The requested tag was merely the agent's conceived solution; the real problem was timely awareness of ownership changes.

Comparing solutions: a list tag requires agents to return to desktop, open the page, and visually scan; a mini-program push notification delivers instant awareness anywhere. The team chose push notifications.

This phase requires documenting: user roles, business rules, problem scenarios, and why current solutions fail. Without this, teams debate trivialities like tag color instead of resource allocation.

Scope Requirements and Set Boundaries

Understanding the problem doesn't mean implementing all related requests. The team defined the core goal: "ensure agents receive timely conversion alerts" — distinct from "improve public listing search experience." The former measures notification delivery; the latter evaluates search flows. Both have value but require separate justification. Scope was limited to trigger timing, recipients, and usage scenarios; broader list redesign was deferred.

Deliverables must specify: core problem solved, rationale for chosen solution, and explicit exclusions.

Translate Judgments into Actionable Solutions

A finance team requested full-screen reimbursement detail view. The existing modal allowed manual maximize but had horizontally laid-out approval nodes causing horizontal scrolling, plus cumbersome printing for archiving. Root pain points: approval chain readability and print workflow.

The solution restructured approval nodes by store hierarchy for clear relationships and added print preview for verification before printing. Detailed rules emerged: after merging nodes, are individual approver statuses still visible? Does hierarchy restructuring imply removed steps? Does preview match final print output? These cannot be left to guesswork.

Documentation formats: flowcharts for business processes, prototypes for layouts, requirement docs for permissions/states/exceptions. Consistency across artifacts prevents rework. Collaboration starts at design confirmation: business validates requirements, design structures information, engineering assesses feasibility, testing verifies rule completeness. Changes must sync across all materials; unresolved items get owners and deadlines. The baseline: confirmed decisions and synchronized changes.

Acceptance: Walk the Full Business Path

Acceptance goes beyond clickable functionality. For listing alerts: verify message binds to correct listing, targets right agent, and conveys change clearly upon opening. Trigger conditions and scenarios must match pre-defined business rules. For reimbursement: walk the finance workflow end-to-end — read approval hierarchy, confirm node statuses, open print preview, verify archival print content. A clickable button doesn't equal a usable business flow.

Multi-party acceptance: product aligns business expectations, testing performs quality checks, engineering and ops assess release readiness. Defects are triaged by impact and business blockage for fix/defer/scope-reduction decisions.

Often overlooked: user communication on process changes and pre-instrumented analytics. For print preview, operational guides and announcements must launch together. Analytics for alert effectiveness must be planned during development, not retrofitted. Defining success metrics upfront ensures post-launch validation beyond "feature shipped."

Review Results to Drive Next Iteration

Post-launch review examines two tracks. Process track: evaluation gaps, requirement change causes, communication breakdowns, external dependencies. Outcome track: actual usage vs. expectations, pain point relief. For alerts, message sent ≠ problem solved; combine delivery rates, user behavior, and business feedback. For reimbursement, preview visits ≠ efficiency gains; measure readability improvement, archival compliance, and new friction points. Quantitative claims (e.g., time saved) require pre/post comparison with defined scope and conditions.

If process smooth but outcomes miss, revisit problem diagnosis and solution choice. If outcomes met but process chaotic, improve collaboration. Neither is "project complete." The cycle restarts: from the agent's tag request, the product manager's first act was asking why; after launch, continuous observation determines if the agent's real frustration is resolved. Products begin with user problems and end with problem improvement — not feature completion.