To B 实例:从定制开发到通用性产品

1 评论 6173 浏览 30 收藏 10 分钟

本文从真实的业务场景出发,谈谈如何完成从定制开发到通用性产品方案的确定。

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

  1. 是否真正理解客户提出的新需求;
  2. 新需求与现有系统的关系;
  3. 新需求的实现是否会影响现有系统的运行;
  4. 是否需要把新功能规划到产品的下一代升级中;
  5. 新功能能否独立成一个单元模块;
  6. 新功能能否独立成一条产品线。

本文结合以上六个问题,从真实的业务场景出发,谈谈如何完成从定制开发到通用性产品方案的确定。

一、从客户需求中归纳出市场需求

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

从定制开发到通用性产品 | 实例

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

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

开始举例

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

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

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

针对这次需求讨论,我们得出了这些结论(简单描述)

  1. 项目的需求方是财务部,他们提出要做收款合同的财务数据汇总和统计分析功能;
  2. 业务部门没有提出合同管理的需求,客户不会为真正的合同管理模块买单;
  3. 合同管理在 ERP 系统内是不可缺少的一个环节;
  4. 该客户会是合同管理软件的潜在客户(因为他们已经定制了合同管理中最重要的财务汇总和分析模块)

二、产品规划vs公司战略:我们的边界在哪里

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

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

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

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

举例继续

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

从定制开发到通用性产品 | 实例

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

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

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

从定制开发到通用性产品 | 实例

随后,经过一系列的市场调研、竞品分析,我方产品部与开发部讨论后做出以下决定:

  1. 数据库设计要考虑多种类型合同的信息录入,考虑不同类型合同的信息组成差异;
  2. 保证合同财务管理模块的独立性,二期项目可能单独开发项目管理模块,与财务模块相关联;
  3. 考虑与公司财务产品的数据对接,能够将合同财务数据直接推送到财务系统,生成财务报表。

这三个决定分别涵盖 3 个方面:

  • 一是数据库设计,对 ToB 产品来说,能把数据库设计好,产品就算成功一半;
  • 二是产品未来的规划,尽可能保证已开发部分的独立性,方便后续进行二次开发;
  • 三是与现有产品的结合,使之尽可能成为一种可打包售卖的行业解决方案。

(记笔记!)

三、Do It !

明确客户的需求和自身的边界后,接下来就要开始设计了。

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

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

关于如何根据需求设计一款产品,本文就不多说了,这类废话网上比较多。

下一篇我会写一点关于产品设计不太常见的废话。

 

作者:产品路漫漫;微信公众号:产品路漫漫

本文由 @产品路漫漫 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 看一看,点个赞!

    来自上海 回复