To B 实例：从定制开发到通用性产品笔者在《To B 行业的 MVP：定制开发》一文中简单介绍了产品经理如何处理客户的定制开发需求。也就是在处理客户提出的需求时，理清以下六个关键性问题：

　　在产品圈内有一个老生常谈的话题——“如何识别客户的真实需求”，这个问题最常见的回答思路是：知道客户是谁，他们要做什么事，接着才是根据用户标签、业务场景等进行具体分析。

　　做需求分析时，识别客户真实需求是我们的首要目的，为了实现这个目的天博·体育，需要解决以上四个问题；在解决问题的过程中，会收集到很多信息；在这些信息中，产品经理不仅仅需要提取出真实需求，还要得出跟市场和公司战略相关的结论。

　　这是小白产品经理与资深产品经理最大的区别，资深产品经理能够时刻保持对市场和公司发展的关注，在接到需求的那一刻，能够马上想到自己要验证什么问题，所以可以快速回答这个需求能不能做，面临的难点是什么。

　　AD 公司购买了我方的一款财务软件，客户在业务交流中反映：影响 AD 公司收支平衡的最大不确定因素是合同账款统计的滞后性；由于集团无法及时收到子公司的报表汇总，导致报表合并与汇算工作滞后，不能即时反映集团财务状况；因此希望实现收款类合同账款的快速统计与汇总功能。

　　从这些沟通中我们发现，AD 公司项目的需求方主要是财务人员，他们只关注财务问题，尤其希望能快速收到下级部门的数据统计报表。但我们知道，最快速的方法不是让“报表”与“报表”之间形成联动，而是把触角伸到合同的具体数据，让财务“管”到业务上（业内称为“业财融合”）。

　　这就涉及到了商务方面的事情：AD 公司的业务部门并没有提出合同管理需求，并且该项目在 AD 公司的责任方是财务部天博·体育，占用的是财务部的预算；我方产品部无法与 AD 公司的业务部门取得联系。

　　当公司决定为客户进行定制开发后，就意味着这项“小型产品”即将成为公司产品线上的一个成员。如何才能提高投入产出比，让这个“成员”更好地发挥自己的价值呢？

　　我们需要在设计之初就考虑到这款产品一生的命运，也就是上文说的：是否需要把新功能规划到产品的下一代升级中，新功能能否独立成一个单元模块，新功能能否独立成一条产品线等等。

　　在规划产品生命线时，最容易陷入的误区就是一个劲儿地往里塞功能，相信很多产品都有体会。每个人的想法都很不错，也确实会有相应的目标客户，但一不小心就会把产品设计成一个四不像，甚至是根本没法做。

　　既然做加法容易出错天博·体育，那就做减法。在考虑到公司整体的产品布局和市场需求后，要给产品限定一个范围；比如说，坚决不做某某行业的此类业务，某项功能实现困难，短期内坚决不考虑等等（开个玩笑，只要客户粑粑钱给到位什么都做）。

　　通过与 AD 公司需求方的讨论，我们列出了在定制开发中要实现的功能清单，这里用 UML 用例图来表述：

　　通过这个用例图可以发现，其实这个定制开发对完整的合同管理软件来说，相对还是比较简单的（产品设计角度），连常用控制功能都没有，只需要挂一条审批流程即可，剩下的关键部分就是统计分析。

　　因为客户的需求就这么简单，“我只想知道截至目前还有多少合同没有收款，应收、欠收等数据的比例是怎样的”，“我想通过合同台账，直接生成财务报表”。

　　理清客户的需求并进行公司内部汇报后，BOSS决定借助这次定制开发的机会，做一款通用型合同管理软件，要能够覆盖合同管理的整个生命周期。于是产品部开会讨论，做出SWOT分析：

　　这时还要再考虑最后一种可能性：你家开发需要升级原来的技术方案吗？前后端框架要更换吗？市场部门有没有什么特殊要求（比如在线申请试用）？

　　之所以提出这些问题，是因为现在 SaaS 真的太火了，传统软件企业想涉足，确实有可能要更换一些技术方案。