我现在服务于一家从事 To B 产品的公司，公司的伙伴在对待客户的产品需求的时候，存在着比较大的三个问题：

1. 盲目的听从客户的需求，客户说什么就是什么；

2. 只注重当前阶段的产品设计，而忽略后期的规划和迭代；

3. 数据思维不足。

我刚开始从技术岗位转向产品岗位的时候，看到产品需求，第一个想法是怎样做到“高内聚，低耦合”，而不是这个需求到底合不合理，我们这一期的迭代和更新是否需要排期等等。随着在产品岗位的发展，才逐渐学会怎样去成为一个合格的产品经理。

上个月，我参加了一个小型的产品论坛，有一个伙伴提了一个问题，他们是从事一个法律服务的SAAS产品，怎样去做一个结合上下游产品的标准化产品，又能满足用户的各种需求呢，但是当时的会议嘉宾老师的回答，我其实是不太满意的。

所以，就有了这篇文章。

断

我先说一下什么是断，就是判断、决断。

这是从产品助理到产品经理转变必须要的一个能力。我们在接到产品需求的，第一时间应该做什么？这个需求产生的原因是什么，据此我们去判断这个需求是不是合理的。

其次再是我们是不是需要接受这个需求，然后才是去排期和规划。

举个例子：我们服务的某个企业，需要在他的微信端 H5 页面上加一个手机号的输入功能。

我们接到这个需求的时候，第一时间是去找技术部门的伙伴排期？还是这个手机号输入框该放在那个页面，手机号是不是要去判断是不是符合某种验证规则？我们应该第一时间明白这个客户为什么要加这样的功能。

比如：是为了用手机号来保证用户的唯一性，还是说仅仅只是为了获取用户的手机号？

至于具体的解决方法，我们要视实际的情况而定。

确定了原因之后，就是发挥我们产品经理能力和职业素养的时候了，我们不仅要去判断这个需求是否实现，而且要去引导客户怎样提供一个好的方案解决他的需求。

我们怎么去判断一个需求是否合理？

第一，这个需求是否在我的产品规划当中；

第二，这个需求是否属于公司的业务范围之内；

第三，这个需求是否属于产品缺陷，或者遗漏的产品设计功能点；

第四，这个需求对应的产品和功能，基于现有的技术条件能否实现；

第五，我有没有更好的解决方法。

基于上述几点，我们去判断这个需求是否合理。

舍

“万物舍此而求生。”——《老子》

我的理解是，在产品需求阶段要做一定的取舍，特别是 To B 产品。如果我们不做一个的取舍，不聚焦与产品的核心功能，那么不仅是产品伙伴和技术伙伴，公司整个的业务线都会疲于奔命。

同样举个例子，之前我们的伙伴在给一个客户，设计产品的时候，按照客户的要求，提供了一个功能场景——用户扫描二维码，发起一个提货的请求操作，当客户和请求方都确认了操作后，这个流程才算完成。

我当时有一个产品涉及到这样的场景，我就问这个伙伴，你发起这样的流程操作，操作双方是需要面对面么？如果我发起了一个这样的请求，同时也有这样的请求达到客户怎么办？如果客户一直没有同意怎么办？

我们遇到实际的需求的时候，多想一些场景，多问一些为什么，就能避免产品设计的反复修改，我们才能从容的面对客户不断变化的需求、

回到刚刚的例子，实际我跟他沟通之后，我发现，客户的需求只是需要有一个方便用户申请和他自己查询申请，并且自己能够及时收到申请而已。这里的服务是基于微信端的，大家可以想象我们遇到这样的场景需要怎样来解决问题。

同样回到刚刚产品开始的问题，在做SAAS产品的时候，我们怎样来提供产品的标准化。

首先，我们要明确一点，我们提供的标准化产品不可能满足所有的场景、所有的需求，而我们尽量做的就是参考帕累托法则说的，满足80%场景下的功能，并且在产品初期阶段，我们要聚焦一个产品的核心功能上，围绕核销点打磨产品。并不是说要完全的舍弃剩下的20%，而是，必要的需求可以后期排期和迭代去实现。

当然，在实际工作中，也有就是我们不得不做的时候，这个大家就都心照不宣。

离

这里的离并不是说要离开，很多时候我的朋友说什么《Java从入门到放弃》，并不是这个意思；而是“载离寒暑”中，所表达的经历的意思。

我表达的经历，一种是自己的体验，一种是学习。

作为 To B 的产品经理，自己要去多体验一些竞品或者其他行业优秀的作品，增加自己的储备。

我身边有做App的伙伴，他们公司的产品岗位，入职前2周要求新同事每天至少体验10款以上的App。

还有就是学习的经历——我们要去不断学习。

我对身边的产品岗位和技术岗位的朋友说：对于新技术我们不说要去处在前沿的位置，只是不能在落后于大趋势。

从机器学习和深度学习开始成为业内的热点之后，我也去学了些关于机器学习的常用算法，比如keras框架，TensorFlow框架，关于SVM，一级CART等。

当然，作为产品不要求我们能够写一手漂亮的代码，而是基于当前的技术，我们能够给我们的客户提供怎样的服务，并且后期我们的产品规划和设计应该有一个怎样的方向去发展。