To B 实例：从定制开发到通用性产品
笔者在《To B 行业的 MVP：定制开发》一文中简单介绍了产品经理如何处理客户的定制开发需求。也就是在处理客户提出的需求时，理清以下六个关键性问题：
- 是否真正理解客户提出的新需求；
- 新需求与现有系统的关系；
- 新需求的实现是否会影响现有系统的运行；
- 是否需要把新功能规划到产品的下一代升级中；
- 新功能能否独立成一个单元模块；
- 新功能能否独立成一条产品线。
本文结合以上六个问题，从真实的业务场景出发，谈谈如何完成从定制开发到通用性产品方案的确定。
一、从客户需求中归纳出市场需求
在产品圈内有一个老生常谈的话题——“如何识别客户的真实需求”，这个问题最常见的回答思路是：知道客户是谁，他们要做什么事，接着才是根据用户标签、业务场景等进行具体分析。
做需求分析时，识别客户真实需求是我们的首要目的，为了实现这个目的，需要解决以上四个问题；在解决问题的过程中，会收集到很多信息；在这些信息中，产品经理不仅仅需要提取出真实需求，还要得出跟市场和公司战略相关的结论。
这是小白产品经理与资深产品经理最大的区别，资深产品经理能够时刻保持对市场和公司发展的关注，在接到需求的那一刻，能够马上想到自己要验证什么问题，所以可以快速回答这个需求能不能做，面临的难点是什么。
开始举例
AD 公司购买了我方的一款财务软件，客户在业务交流中反映：影响 AD 公司收支平衡的最大不确定因素是合同账款统计的滞后性；由于集团无法及时收到子公司的报表汇总，导致报表合并与汇算工作滞后，不能即时反映集团财务状况；因此希望实现收款类合同账款的快速统计与汇总功能。
从这些沟通中我们发现，AD 公司项目的需求方主要是财务人员，他们只关注财务问题，尤其希望能快速收到下级部门的数据统计报表。但我们知道，最快速的方法不是让“报表”与“报表”之间形成联动，而是把触角伸到合同的具体数据，让财务“管”到业务上（业内称为“业财融合”）。
这就涉及到了商务方面的事情：AD 公司的业务部门并没有提出合同管理需求，并且该项目在 AD 公司的责任方是财务部，占用的是财务部的预算；我方产品部无法与 AD 公司的业务部门取得联系。
针对这次需求讨论，我们得出了这些结论（简单描述）：
- 项目的需求方是财务部，他们提出要做收款合同的财务数据汇总和统计分析功能；
- 业务部门没有提出合同管理的需求，客户不会为真正的合同管理模块买单；
- 合同管理在 ERP 系统内是不可缺少的一个环节；
- 该客户会是合同管理软件的潜在客户（因为他们已经定制了合同管理中最重要的财务汇总和分析模块）
二、产品规划vs公司战略：我们的边界在哪里
当公司决定为客户进行定制开发后，就意味着这项“小型产品”即将成为公司产品线上的一个成员。如何才能提高投入产出比，让这个“成员”更好地发挥自己的价值呢？
我们需要在设计之初就考虑到这款产品一生的命运，也就是上文说的：是否需要把新功能规划到产品的下一代升级中，新功能能否独立成一个单元模块，新功能能否独立成一条产品线等等。
在规划产品生命线时，最容易陷入的误区就是一个劲儿地往里塞功能，相信很多产品都有体会。每个人的想法都很不错，也确实会有相应的目标客户，但一不小心就会把产品设计成一个四不像，甚至是根本没法做。
既然做加法容易出错，那就做减法。在考虑到公司整体的产品布局和市场需求后，要给产品限定一个范围；比如说，坚决不做某某行业的此类业务，某项功能实现困难，短期内坚决不考虑等等（开个玩笑，只要客户粑粑钱给到位什么都做）。
举例继续
通过与 AD 公司需求方的讨论，我们列出了在定制开发中要实现的功能清单，这里用 UML 用例图来表述：
通过这个用例图可以发现，其实这个定制开发对完整的合同管理软件来说，相对还是比较简单的（产品设计角度），连常用控制功能都没有，只需要挂一条审批流程即可，剩下的关键部分就是统计分析。
因为客户的需求就这么简单，“我只想知道截至目前还有多少合同没有收款，应收、欠收等数据的比例是怎样的”，“我想通过合同台账，直接生成财务报表”。
理清客户的需求并进行公司内部汇报后，BOSS决定借助这次定制开发的机会，做一款通用型合同管理软件，要能够覆盖合同管理的整个生命周期。于是产品部开会讨论，做出SWOT分析：
随后，经过一系列的市场调研、竞品分析，我方产品部与开发部讨论后做出以下决定：
- 数据库设计要考虑多种类型合同的信息录入，考虑不同类型合同的信息组成差异；
- 保证合同财务管理模块的独立性，二期项目可能单独开发项目管理模块，与财务模块相关联；
- 考虑与公司财务产品的数据对接，能够将合同财务数据直接推送到财务系统，生成财务报表。
这三个决定分别涵盖 3 个方面：
- 一是数据库设计，对 ToB 产品来说，能把数据库设计好，产品就算成功一半；
- 二是产品未来的规划，尽可能保证已开发部分的独立性，方便后续进行二次开发；
- 三是与现有产品的结合，使之尽可能成为一种可打包售卖的行业解决方案。
（记笔记！）
三、Do It ！
明确客户的需求和自身的边界后，接下来就要开始设计了。
这时还要再考虑最后一种可能性：你家开发需要升级原来的技术方案吗？前后端框架要更换吗？市场部门有没有什么特殊要求（比如在线申请试用）？
之所以提出这些问题，是因为现在 SaaS 真的太火了，传统软件企业想涉足，确实有可能要更换一些技术方案。
关于如何根据需求设计一款产品，本文就不多说了，这类废话网上比较多。
下一篇我会写一点关于产品设计不太常见的废话。
作者：产品路漫漫；微信公众号：产品路漫漫
本文作者 @产品路漫漫
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
