初入职场时，我对产品经理的理解停留在表面——不过是收集各方需求的“收纳员”。销售反馈客户需要新功能，运营提出用户希望增加按钮，老板指出竞品推出了新模块，我便将这些需求一一记录在案。短短半年，产品文档里竟堆积了37个待开发需求，团队因此陷入无休止的加班，用户却抱怨连连，直言功能冗余、操作繁琐。
那时的我逐渐意识到，仅会收集需求的产品经理，与“垃圾桶”无异。真正的挑战在于如何筛选和判断这些需求的真正价值。这一转变，源于两次深刻的教训。第一次，是公司开发“智能标签推荐”功能的经历。几位活跃用户提出，希望根据浏览内容自动打标签，以便快速查找历史内容。销售团队认为这一功能能吸引新用户，便果断拍板。我未加思索，便投入原型设计，开发团队耗费两个月完成功能上线。然而，使用率却不足5%。原来，提出需求的用户多为内容运营人员，普通用户并无此需求。我们错误地将少数人的特殊场景当成了普遍痛点。
第二次教训更为惨痛。公司为争取一位行业大客户，对方提出报表功能需按其特定格式导出，否则拒绝签约。在老板和销售的催促下，我妥协了。为快速交付，开发团队直接将定制逻辑写入核心代码，导致后续迭代时频繁出现兼容性问题，重构工作耗时三个月。客户使用半年后便解约，而定制代码却成了产品架构中的“毒瘤”。这次经历让我深刻反思，产品经理的核心职责并非“接需求”，而是“判需求”。
判断需求并非易事，需克服心理障碍。许多人不敢拒绝需求，担心得罪销售或老板。我曾也是如此，直到学会用数据和逻辑支撑决策。例如，运营提出增加“分享到朋友圈”按钮时，我查阅数据发现现有分享率不足1%，用户反馈中也未提及此需求。我建议优先优化搜索功能，待数据提升后再考虑分享按钮。这一决策不仅未引起不满，反而让运营团队认可了我的专业性。
需求可分为通用需求与定制需求。通用需求是产品的骨架，如微信的聊天功能、淘宝的购物车，不可或缺；定制需求则可能成为赘肉，看似丰满，实则拖累。判断通用需求的关键在于观察用户行为，而非仅听其言。例如，我们曾误以为“夜间模式”是刚需，调研后发现80%的用户白天使用软件，夜间几乎不打开。而“快捷键自定义”功能则因满足用户高频需求，数据显著增长。
面对定制需求，需谨慎评估。我总结了三个问题：这是真痛点还是个别情况？能否通过配置而非硬编码解决？未来三年需付出何种代价？例如，有客户提出“导出PDF时加水印”的需求，我询问其他同行业客户后发现，仅1家有类似需求，其余4家表示无所谓或可用第三方工具解决。最终，我们通过配置功能满足需求，避免硬编码带来的维护成本。又如，客户要求“不同部门看到不同菜单”，我们通过“角色权限配置”功能实现，既满足需求，又保护了产品架构。
产品经理的价值不在于完成多少需求，而在于做对多少需求。就像厨师做菜，需挑选新鲜、搭配合理的食材，而非将所有食材一股脑扔进锅里。从“需求收纳师”到“需求裁判”，我走了三年。踩过的坑、掉过的泪，都成了判断需求的底气。用户要的未必是他需要的，老板说的未必是对的，竞品有的未必适合你。产品经理需像老中医一样，望闻问切，才能开出对的药方。守护产品的核心价值，该做的做，不该做的拒，产品才能走得远、活得久。毕竟，好产品不是堆出来的，是筛出来的。
