我刚开始从技术岗位转向产品岗位的时候，看到产品需求，第一个想法是怎样做到“高内聚，低耦合”，而不是这个需求到底合不合理，我们这一期的迭代和更新是否需要排期等等。随着在产品岗位的发展，才逐渐学会怎样去成为一个合格的产品经理。
前言
我现在服务于一家从事 To B 产品的公司，公司的伙伴在对待客户的产品需求的时候，存在着比较大的三个问题：
一是盲目的听从客户的需求，客户说什么就是什么；
二是只注重当前阶段的产品设计，而忽略后期的规划和迭代；
三是数据思维不足。
上个月，我参加了一个小型的产品论坛，有一个伙伴提了一个问题，他们是从事一个法律服务的SAAS产品，怎样去做一个结合上下游产品的标准化产品，又能满足用户的各种需求呢，但是当时的会议嘉宾老师的回答，我其实是不太满意的。所以就有了这篇文章。
一、断
我先说一下什么是断，就是判断、决断。
这是从产品助理到产品经理转变必须要的一个能力。我们在接到产品需求的，第一时间应该做什么？这个需求产生的原因是什么，据此我们去判断这个需求是不是合理的，其次再是我们是不是需要接受这个需求，然后才是去排期和规划。
举个例子，我们服务的某个企业，需要在他的微信端 H5 页面上加一个手机号的输入功能。我们接到这个需求的时候，第一时间是去找技术部门的伙伴排期？还是这个手机号输入框该放在那个页面，手机号是不是要去判断是不是符合某种验证规则？我们应该第一时间明白这个客户为什么要加这样的功能。
比如：是为了用手机号来保证用户的唯一性，还是说仅仅只是为了获取用户的手机号？
至于具体的解决方法，我们要视实际的情况而定。确定了原因之后，就是发挥我们产品经理能力和职业素养的时候了，我们不仅要去判断这个需求是否实现，而且要去引导客户怎样提供一个好的方案解决他的需求。
我们怎么去判断一个需求是否合理？
第二，这个需求是否属于公司的业务范围之内；
第四，这个需求对应的产品和功能，基于现有的技术条件能否实现；
第五，我有没有更好的解决方法。
基于上述几点，我们去判断这个需求是否合理。
二、舍
“万物舍此而求生。”——《老子》
我的理解是，在产品需求阶段要做一定的取舍，特别是 To B 产品。如果我们不做一个的取舍，不聚焦与产品的核心功能，那么不仅是产品伙伴和技术伙伴，公司整个的业务线都会疲于奔命。
同样举个例子，之前我们的伙伴在给一个客户，设计产品的时候，按照客户的要求，提供了一个功能场景——用户扫描二维码，发起一个提货的请求操作，当客户和请求方都确认了操作后，这个流程才算完成。
我当时有一个产品涉及到这样的场景，我就问这个伙伴，你发起这样的流程操作，操作双方是需要面对面么？如果我发起了一个这样的请求，同时也有这样的请求达到客户怎么办？如果客户一直没有同意怎么办？
我们遇到实际的需求的时候，多想一些场景，多问一些为什么，就能避免产品设计的反复修改，我们才能从容的面对客户不断变化的需求、
回到刚刚的例子，实际我跟他沟通之后，我发现，客户的需求只是需要有一个方便用户申请和他自己查询申请，并且自己能够及时收到申请而已。这里的服务是基于微信端的，大家可以想象我们遇到这样的场景需要怎样来解决问题。
同样回到刚刚产品开始的问题，在做SAAS产品的时候，我们怎样来提供产品的标准化。
首先，我们要明确一点，我们提供的标准化产品不可能满足所有的场景、所有的需求，而我们尽量做的就是参考帕累托法则说的，满足80%场景下的功能，并且在产品初期阶段，我们要聚焦一个产品的核心功能上，围绕核销点打磨产品。并不是说要完全的舍弃剩下的20%，而是，必要的需求可以后期排期和迭代去实现。
当然，在实际工作中，也有就是我们不得不做的时候，这个大家就都心照不宣。
三、离
这里的离并不是说要离开，很多时候我的朋友说什么《Java从入门到放弃》，并不是这个意思。而是“载离寒暑”中，所表达的经历的意思。我表达的经历，一种是自己的体验，一种是学习。
作为 To B 的产品经理，自己要去多体验一些竞品或者其他行业优秀的作品，增加自己的储备。我身边有做App的伙伴，他们公司的产品岗位，入职前2周要求新同事每天至少体验10款以上的App。
还有就是学习的经历，我们要去不断学习。我对身边的产品岗位和技术岗位的朋友说，对于新技术我们不说要去处在前沿的位置，只是不能在落后于大趋势。
从机器学习和深度学习开始成为业内的热点之后，我也去学了些关于机器学习的常用算法，比如keras框架，TensorFlow框架，关于SVM，一级CART等。
当然作为产品不要求我们能够写一手漂亮的代码，而是基于当前的技术，我们能够给我们的客户提供怎样的服务，并且后期我们的产品规划和设计应该有一个怎样的方向去发展。
今天的这篇文章，文字部分比较多，后期的文章会结合产品的实例和代码的具体实现上，与大家分享。如果大家有问题，可以在下方评论区留言，部分问题我会在下篇文章中解答。
