编辑导语：B端产品经理在工作过程中，需要注意哪些事情呢？多多学习前辈的经验可以帮助我们在工作上少踩一些雷，进步的更快。本文作者结合自己一年半的工作经验，从成长点以及工作习惯两方面为我们做出了回答，希望对你有所帮助。

从踏入产品经理至今，已经有1年半的时间了，本篇文章会总结一下我能感受到的自己成长点；其次，跟大家分享一下产品日常工作中需要注意的关键点。

一、成长点

考虑需求更加全面，提前告知业务风险点。

对于B端产品经理，很多需求来源于我们的业务方，他们会天马行空地跟我们说出很多需求。这个时候，我们需要快速地思考如下方面的问题：

1. 明确需求的合理性

这个问题需要回答的是要不要做的问题。

首先：引导业务明确地阐述为什么要做这个需求，如果业务只说结果，我们很难洞察到背后的原因。因此需要让业务描述出在什么场景下，遇到了什么问题，期望得到的结果是什么。通过了解背后的原因，可以探讨需求的本质。

其次：产品同学可以结合目前产品本身的功能，看是否有本身已经有的功能可以解决问题。如果没有，则分析一下需求的价值及合理性，很多业务提出的需求是伪需求，或者是在原本错误的逻辑上提出的解决方案，这种需求就不建议做。

2. 需求的优先级

这个问题需要回答的是该不该现在做的问题，很多需求是合理且有意义的，但不代表就要立马做，产品需要梳理本次需求的方向与产品的大方向是否吻合，产品本身是有自己的发展路径的，比如目前产品处于起步阶段，需要做到更多的是系统能力的搭建。

如果这时，业务提出比较大的活动引流玩法，在系统不够成熟的情况下，很容易造成系统崩溃，用户体验差，引流来的用户无法在持续地在系统上留存。这个时候，产品经理需要结合产品发展阶段给出需求在此阶段开发的合理性。

除此之外，在需求评估的时候，即使需求合理，也需要考虑使用的场景的频率和用户的使用范围，如果该需求无法成为后续可推广性的功能，那可以适当地把需求的优先级降低。

3. 是否有什么风险

在明确需求该做，且比较迫切时。这个时候，就需要发挥产品经理的洞察风险的能力，这也是资深产品和萌新产品经理很重要的区别点。

风险点一般出现在哪些方面呢？

• 提出需求的人，和真正的用户并非是同一类型的用户。提出需求的人，大多情况是站在管理者，平台方的角度。所以，站在他们的视角需求可能是合理的，但是站在真正使用者的角度，存在很多不合理或者体验不好的地方。这种情况，需要提出这样的风险点，避免需求上线后，真正的使用者不买账的情况；
• 需求要在哪个平台或者页面做，是否有权限的问题。这也是很多初级产品经理容易忽略的问题-权限问题，需要跟业务方明确，是允许哪种角色的人使用该功能。如本身系统无法满足该权限类别，这也是需求的工作量；
• 数据覆盖同步和覆盖问题，一旦涉及到数据问题，就需要系统之前的数据传递，需要提前告知业务，是实时同步，还是T+1同步，还是几个小时的延时同步，最好可以在后台系统上标明同步时间，避免用户产生歧义；
• 所有环节查看的数据是实时信息还是快照信息，一旦涉及到数据的修改，尤其是用户端已完成的数据，查看的是实时数据还是快照数据。这些都需要在方案阶段进行梳理，不同的决定方案，可能会影响后续的数据处理和存储方式；
• 重要行为用户行为操作记录，如商品的价格修改，上下架等业务认为重要的行为是否需要记录，并展示出来，这个也可以在需求沟通中明确要记录的用户关键动作，形成操作日志。

二、工作习惯

产品经理是一个信息的汇集地，每天需要输入，并输出大量的信息。在工作上多反思，每天给自己“长个记性”会让工作更加高效。

1. 数据的处理

很多产品经理在做需求时，只能考虑到此时，此刻的数据状态和现实情况，很容易忽略掉数据的动态变化过程。

比如，历史的数据该怎么处理？数据后续更改属性后，数据该怎么同步？数据删除后，该数据是否在前端显示，如果显示，用户端点击后，该怎么提示？A获取B的信息，B变动之后，A的同步机制是什么？

每次涉及到数据的处理，请默念【增】、【删】、【改】、【查】，每次条理清晰地把数据的状态分场景罗列清楚，开发和测试同时会爱上你的需求文档~~

2. 多思考异常情况

近期在设计优惠券在用户界面的展示逻辑，在设计这个需求的过程中，就需要产品经理结合运营诉求定义优惠券展示的排列规则。在定义好未领取的优惠券排序高于已领取的优惠券之后（目的：提高优惠券的领取率），就需要再对每一个类别的优惠券再次进行排序。

• 未领取优惠券中，新最发布的位置最高，发布时间以后台时间为准；
• 异常场景：发布时间按照后台记录的ms级进行记录，如果时间相同，随机取一个优惠券优先排列；
• 已领取优惠券中，最后领取的位置最高，以用户领取时间为准；
• 异常场景：当用户领取时间相同时（一键领取多张时会触发同时领取），顺序以优惠券的截止时间进行排序，距离结束时间越近的（即马上要到期的）顺序放在上方。

这些异常场景都需要产品在撰写需求文档的时候就要考虑清楚。每次在写需求文档的时候，多问自己问题，就会避免开发和测试同学来问你问题，也会让他们在读你需求文档的时候，觉得产品的思维是缜密的。

3. 可测试的场景

前几天开发问我，**需求的第3个场景在什么情况下发生？

这时候，我才发现我的场景3是针对于几个月后市场部推广成功后才会应用到的场景，因此，这种在开发和测试眼中就是“不可测试”场景。

这件事情也给我上了一课，产品经理可以把梳理的思路写到需求文档，但给到开发和测试沟通的文档一定是清晰、明确、可测试的。必要的情况下，可以提供如何达到这种场景的前置条件，方便开发了解场景的前因后果，也方便测试准备对应的数据。

三、小结

希望自己可以每天对工作进行反思，多总结，多归纳。不断磨练自己的思维。而且有一点点小的感悟就一定要记下来，这样每次写需求之前多看看自己的感悟，就可以规避很多问题，久而久之，能力就会提升一大截。

本文由@黑心老巫婆 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议