产品经理充当着与用户沟通的桥梁角色，确保用户需求和反馈得到妥善处理。在用户痛点解决的过程中，产品经理需关注关键的信息交互节点。本篇文章从需求梳理、产品功能、展示逻辑和开发周期四个角度分析了与用户交互过程中的重点。一起来看看吧！

产品经理的工作核心是解决用户痛点（文章链接见：https://www.woshipm.com/share/5969298.html）。用户在痛点解决后会给出各种反馈，或理性的，或感性的。痛点从用户提出的时间节点起始，至痛点真正得到妥善解决，这期间产品经理处在沟通桥梁作用的核心，是关键的信息产生方，用户就像信息受体那样，通过接受到的点点滴滴信息，整合加工后输出最终感受反馈。因此，产品经理在与用户交互的过程中，更要有意识地关注每次信息交互的节点，积沙成塔地营造用户满意的交付体验。

痛点解决全生命周期中关键的信息交互节点包括：需求梳理、产品功能、展示逻辑、开发周期等。（图1）

图1 信息交互关键节点

一、需求梳理节点–相对独立性意识

产品经理深入到业务领域通过用户调研获悉痛点的背景及用户期望达成的效果。而用户从业务角度剖析遇到的痛点，还会根据自己的理解给出“合理”的产品解决方案。产品经理如何自处？是顺从用户，并完全照搬用户理解，用户说啥做啥？还是发挥产品经理的专业能力，利用理解业务的契机，引导用户思考，共同寻找对于痛点的更全面理解，有利于更全面设计产品解决方案。

产品经理是专业技术人才，从实践经验来看，正确的做法是将从用户那里得到的痛点剖析和解决方案作为解决问题的参考依据，然后保持产品经理的相对独立性及专业性，在全面理解业务痛点的基础上构思完善的产品解决方案。为什么呢？关键在于产品经理相比较用户拥有更全面的视角。（图2）

图2 用户视角VS产品经理视角

用户是从前端页面来介入产品，用户实操业务，再结合使用产品功能的经验、体会建立个人角度的产品理解。而产品经理是产品功能模块的制造者，不仅从前端页面理解产品，还从对业务不可见的后端逻辑来拆解产品，再加上产品经理对业务现状的理解，产品经理相比较用户对产品全貌所能够理解的深度、广度都有很大不同。

二、产品功能节点–供应链闭环思维

对用户而言，最期望、最核心的是自己提出的全部痛点都转化成了合理的产品功能模块。用户作为产品方案的评估方，产品经理要相对用户想的更全些，才能保证用户痛点解决的真正落地。

经常会出现的情况是，用户有A方面的痛点，产品经理按照解决A方面痛点的目标来设计产品方案，但A方面痛点的解决会关联导致B方面业务执行操作难度/风险的增加。因此，作为合格的产品经理，要从产品功能维度和业务实操维度更全面统筹考虑。从供应链的角度，供应链是由实物流、信息流、资金流组成的，产品解决方案都应该在这“三流”维度来验证，否则，可能遗留/产生漏洞风险点。

以实际工作中遇到的产品功能模块为例，作为采购平台，采购订单在下达到供应商后，供应商会基于实际生产备货情况来分批发货，从而将单个采购订单分解成多个发货单，产生发货单后采购订单状态从待发货更新为发货中，发货单状态置为已发货，待某些发货单到货后，供应商会操作到货验收，发货单状态更新为已到货，然后采购单位会操作单个或多个发货单到货验收，发货单状态更新为已验收。如果采购单位需要退货，可以在验收单维度操作整单退货申请。（图3）

图3 不同类型单据转换逻辑

原有逻辑下，采购单位可以在当采购订单状态为待确认（供应商确认采购订单可支持，操作确认后采购订单状态更新为待发货）时，可以操作订单取消。后来，采购单位希望针对全部类型商品增加2个采购订单可取消场景：

1. 采购订单状态为待发货的，可以操作采购订单整单取消；
2. 采购订单下产生发货单且发货单状态都为已到货的，可以操作采购订单整单取消。

供应商在采购订单确认支持逻辑中，会先确认是否可以支持，如果能支持则开始备料、排产生产、质检，最后通过物流运输将生产的合格实物运输到需求目的地。在此用户痛点需求中，产品经理给到的解决方案是可以支持采购单位在如上2个场景下整单取消采购订单，并按照逆向流程资金流要求将对应款项返回到原账户。

此产品解决方案虽然考虑了供应链的信息流、资金流，但实物流呢？在采购单位计划取消的时点，供应商或已将实物发出，对应发货单状态为已发货，或已备料、排产生产、质检，或在发货前的打包准备期。已发货状态的发货单必须等到货后才满足如上采购订单场景2.的取消条件。但无形中增加了供应商物流运输及备料、生产、库存成本。

从产品功能维度采购单位虽然可以对没有发货的实物发起禁止发货的指令，但对无形中同样增加了供应商备料、生产、库存成本。

长此以往，供应商会寻找各种隐形手段来降低自己的潜在损失，最终降低用户的满意度。此时作为产品经理，理应返回到需求梳理节点，发掘用户痛点的真实原因，然后分门别类依次处理。

三、展示逻辑节点–UX优化思维

此阶段产品经理是重要参与方，还是评估方。作为参与方通过原型设计输出产品交互逻辑的功能框图；作为评估方，对UI同事设计的高保真设计图进行评估，并给出修改、更新意见。但实际产品经理在此阶段更倾向于投入更少时间。那么用户的体验有很大风险由于与业务使用习惯及业务场景存在不小偏差而导致用户满意度下降。接下来会以实际产品为例来说明此问题。（图4）

图4 实际产品页面示例

此产品功能虽然能够解决用户线上填充信息的痛点，但用户完成全部信息的填写要至少滑动四屏。本产品页面的不合理设置，对用户体验会产生很大负面影响，经分析至少有两处可再提升的地方：

1. 填写的字段信息堆叠展示，页面右侧大片空间浪费；
2. “提交”“保存”“取消”按钮长显在下端，在未完成全部信息填写后可直接点击“提交”“保存”“取消”，用户容易误操作。

四、开发周期节点—合理项目管理

用户痛点从下达到建设上线验证通过后的全流程所花费的时间周期，反映出用户需求的满足效率高低。产品经理要结合用户实际预期，合理协调研发、测试资源，保证用户痛点解决的高标准达成。日常工作中单个研发资源所承接的研发项目任务不止一个，研发资源紧缺是常态。

产品经理身肩项目经理角色，需要通过加强与用户的沟通，让用户理解实际情况，并及时更新进度信息到用户侧，保证用户的全面理解。理解产品团队真正重视并正在解决他们的痛点，理解产品经理付出了很大努力来各方协调来最快解决他们的痛点。