从0到1了解B端产品方案+案例

上一篇,我们讲了从0到1设计B端产品的业务调研。今天,我们继续讲产品方案。限于篇幅,本文将重点阐述总体方案部分。对B端业务调研感兴趣的朋友,可以点击《没有这个能力,还是合格的产品经理吗?》阅读。

从0到1了解B端产品方案+案例

01 产品方案的要点

一般情况下,从0到1的B端产品往往聚焦于企业少数几个痛点,同时具备很强的可落地性。如果是SaaS产品,还必须长远规划,以减少后期迭代的成本。因此,B端产品方案主要有以下三个要点:

1、聚焦重点

从0到1的B端产品必须聚焦重点,以最小成本验证产品的价值。

聚焦重点的本质是“定位”,即面向哪一类客户,解决哪一个痛点。定位良好的产品,就像一把锥子,能够迅速切入市场,并且取得稳固的市场地位。

聚焦重点也是敬畏市场的表现。在互联网浪潮下,不管是创业公司,还是客户自己,往往都在一边探索一边调整。快速推出MVP版本,再根据用户反馈迅速迭代,是产品创新的最佳实践。

2、究竟精神

永远相信用户,但是永远也不要相信用户。

所谓相信用户,是相信当用户提出一个需求,它确实反映了用户存在一个困扰;所谓不要相信用户,是不要指望用户会透彻分析自己的需求,而他们所提出的方案往往也是“头疼医头、脚疼医脚”。这并不能归罪于用户,毕竟,对他们来说,达成业务目标才是最重要的事,系统只是辅助手段,不值得花费太多时间深入思考。

关于要不要听用户的,海底捞创始人张勇有一段经典的阐述:“消费者说海底捞不好吃,其实可能是嫌价格贵。我老婆说我回家晚,可能是我对她关心不够。如果我信我老婆的话,每天都在家待着,我相信我老婆会更讨厌我。”

在制作产品方案时,我们必须洞察用户需求,找到需求背后的真相。而这种洞察能力,很大程度上依赖于我们的究竟精神。

比如,用户提出,希望能够增加一个订单付款状态,且当状态为“未付款”时,不允许发货。如果我们能够进一步提问,就会发现用户更深层次的需求。模拟对话如下:

产品经理:为什么订单没有付款,就不允许发货呢?

用户:因为和这些客户不是长期合作,为了控制风险,所以必须先款后货。

产品经理:那么长期合作的客户呢?是不是就可以不付款也允许发货呢?

用户:要分情况,有些客户可以付一部分款就发货,有些客户可以不付款先发货。

产品经理:什么样的客户可以付一部分款就发货,什么样的客户可以不付款先发货呢?

实际上,有经验的产品经理,会根据信用管理的框架,对客户类别、信用政策、应收款管理等方面进行全面梳理。因为从产品架构角度来看,这个需求无疑应该纳入信用管理模块。

如果一个方案没有经过严谨梳理,在落地过程中就可能出现问题。比如,在上述例子中,如果直接根据用户需求设计产品,在后期很可能就需要对方案进行大改。

值得一提的是,B端产品经理的工作非常依赖冷静思考。如果外界给产品经理施加了过大压力,就可能导致产品经理“动作变形”,从而做出错误决策。作为产品经理,我们要警惕过大的外部压力,时刻提醒自己:没有慎重思考过的产品,不值得浪费宝贵资源。

3、长远规划

如果我们设计的是SaaS产品,则必须注重长远规划。

从0到1的SaaS,客群规模有一个从小到大的过程。当客户和功能数量都较少时,如果缺乏规划,产品就很容易野蛮生长。

比如,买赠是消费品行业常用的促销手段。在某些情况下,赠品需要关联到主品,比如买5瓶大可乐送1瓶小可乐。产品经理为了设计和操作方便,可能选择直接在订单行上新增两个字段,体现赠品名称和数量。

这样的设计在面对简单需求时,可能不会出现问题。但一旦遇到比较复杂的需求,就会出现问题,比如:

1)需要管理赠品发货;

2)一种售卖品送多种赠品,比如买2瓶大可乐送1瓶小可乐和1个杯子;

3)需要和ERP系统集成。

正确的做法是,主品和赠品都放在独立的订单行,拥有相同的字段,并且通过“赠品”字段来标识该订单行是否赠品(打勾即为赠品)。

因此,作为SaaS产品经理,不能够只盯着眼前的需求,而要放眼长远,做全面的考虑。

02 产品方案的结构

如果只是针对一小块功能的迭代,产品方案要求相对简单。重点说清楚1)解决什么问题;2)解决问题的方案;3)页面设计和逻辑即可。

但如果是从0到1设计一款产品,特别是设计一款SaaS产品,则必须从更高、更全面的视角进行方案梳理。

我建议的产品方案结构如下:

  1. 总体方案
  2. 详细方案
  3. 管理报表方案
  4. 集成方案
  5. 用户期望满足

在总体方案部分,需要对产品价值、整体方案和总体架构进行说明,一方面便于给公司和客户高层进行汇报;另一方面也便于产品经理们了解彼此的工作,提高沟通与协作效率。

在详细方案部分,需要对每个模块的需求进行分析,重点论证是否伪需求,并明确成功指标,然后通过文字说明和流程图对解决方案进行阐述,最后才是页面设计和相关逻辑说明。

对于B端产品,管理报表虽然功能相对简单,但反映了管理者的需求,需要和业务功能一并设计。否则,一旦后期发现产品不能支撑管理报表需求,就很可能导致返工。

对于针对大企业的B端产品,往往会涉及到系统集成。系统集成反映了上下游业务的需求,也需要尽早规划和设计。

最后,产品对用户期望的满足程度,往往决定了用户对产品的满意度。即便在MVP阶段无法满足所有需求,也需要纳入长期规划。

03 总体方案

总体方案是整个产品方案中最精华的部分。理论上,仅仅通过总体方案,高层就能够决策一个产品要不要研发。

总体方案又分为以下四个部分:

1)方案概要说明

2)总体流程图

3)应用架构图

4)多组织架构设计

接下来,我们挨个进行阐述。

1、方案概要说明

该部分内容主要说明产品的定位,以及MVP版本的范围。这也是B端产品从0到1,产品方案最核心的部分。

方案概要说明包含以下三部分内容:

1)产品定位:

定位决定成败。大部分产品失败的原因,都是没有回答好以下三个问题:

客户是谁?

痛点是什么?

客户为什么选择我们?

比如,某位创业者希望做一款组织管理工具,但具体解决客户什么痛点,以及和钉钉、飞书这些成熟产品有什么区别,都不能清晰表述。这样的产品大概率会失败。

在这个部分,我建议产品经理可以畅想一下:如果客户写来一封感谢信,诉说使用产品后给他们带来的改变,那么这封信的内容应该是怎样的呢?

比如,对于一款针对养生服务连锁门店的SaaS软件,产品定位如下:

客户是谁?

会员制的养生服务连锁门店,根据XX咨询报告,2020年全国约有700万家养生服务连锁门店。

痛点是什么?

痛点主要是两个。一是门店获客差,二是门店运营管理效率低。

为什么选择我们?

我们的产品是针对养生服务连锁门店的SCRM,能够针对性解决他们的痛点。更重要的是,我们的核心团队有丰富的养生服务连锁门店运营经验,在门店数字化运营方面也有成功经验。

客户感谢信示例如下:

你好小李,

自从使用你们的产品后,我们的获客成本大大降低,特别是省去了1000元/客的地推成本。同时,潜客进店成交率提升了20%,这得益于互联网裂变带来的更高质量的线索。

另外,使用了你们的产品后,由于运营数据都自动生成,门店行政人员的工作量大大减轻。更重要的是,由于可以在手机端实时查看运营数据,公司的决策效率大大提升。以前月初才能分析上月运营情况,现在每天都可以开运营分析会议。感谢你们设计出这么优秀的产品!

2)产品功能模块:

在明确用户痛点和产品价值后,我们还需要明确产品的功能模块。

首先需要明确MVP版本的功能模块。

MVP其实包含了两个要点。一是“最小化”,即只做最核心的功能;二是“可行”,即用户能够使用起来,并且满足他们最核心的需求。

曾经有创业者问我,如何判断一个产品已经完成MVP阶段?我个人认为就是客户是否愿意续约。之所以用“续约”而不是用“付费”,是因为担心客户付费以后,发现产品并不能很好的解决业务问题。

如果是SaaS产品,还建议区分标准化功能和定制化功能。如果是定制化功能,建议与标准化功能区隔开,避免对标准化功能造成干扰。比如,客户希望在订单上增加一个特殊逻辑,根据自定义公式自动生成商品价格。如果我们还没有计划对其进行标准化,就可以为这个公式设计单独的页面,并且默认商品价格计算不使用这个公式。

除了MVP版本的功能,我们还可以规划后续版本的功能。

长远考虑有利于提前设计好产品架构,降低后续迭代的成本。比如,如果未来计划建设财务模块,或者对接成熟的财务系统,那么就可以提前考虑“关账”的概念:对于财务核算来说,本月是不允许随意调整上月出库订单等业务数据的,否则会影响已经出具的上月财务报表。

当然,不能为了“确定性较低”的未来规划,给研发造成过大负担。这时候就比较考验产品经理的系统架构能力和业务洞察力。在这个方面,推荐大家阅读我的文章《成熟的B端产品经理,都有这个能力》。

2、总体流程图

B端产品往往需要支持多部门、多角色协同,因此对于业务链条较长的产品,需要绘制总体流程图,以便于从整体上鸟瞰整个产品的业务流程,避免错漏。

在范围上,整体流程图需要覆盖所有关键流程和业务类型。在颗粒度上,整体流程图主要描述关键步骤,不需要细化到具体功能甚至页面。对于比较简单的业务流程,比如客户信息管理,可以跳过总体流程图,直接绘制详细流程图。

示例如下:

从0到1了解B端产品方案+案例

在上图中,现结和落地结算是XX制造企业的两种关键业务类型。对于现结业务,出库即可确认商品所有权转移,因此根据实物出库数量冲减系统库存数量,并且生成财务结算单据即可。对于落地结算业务,出库只是实物转移到客户现场,到月底时,需要根据客户实际使用数量生成财务结算单据,并冲减系统库存数量。上述流程图正是描述了两种关键业务的整体流程。

3、系统架构图

对于比较复杂的系统,我们还需要绘制系统架构图。

特别是SaaS产品,合理的系统架构可以有效减少功能重复、避免数据混乱和降低系统扩展难度。反之,一旦在不合理的系统架构上搭建起页面,特别是在拥有一定数量的企业客户后,修改的成本可能会很高。

相对来说,自研产品的纠错成本就低得多。毕竟只有一家企业在用,只要和业务部门协商好,推翻重建也是可行的。

系统架构设计的重点要做到低耦合、高复用。

所谓低耦合,是将功能按照业务相关性,分为多个系统应用。系统应用之间通过API进行交互。这样,单个应用的升级,对其他应用的影响就小很多,从而提高了系统的敏捷性。比如,销售订单管理、仓库管理和CRM就可以独立为多个应用,并且在必要的时候分配给不同的产品经理负责。

当然,对于同一类应用,有时候我们还需要进一步拆分。比如,针对大客户的销售订单管理,和针对小客户的销售订单管理,由于需求差异较大,为了避免彼此影响而增加系统复杂度,可以考虑划分为两个独立应用。毕竟,相对于研发成本,业务匹配程度和用户使用成本更为重要。

所谓高复用,即将各个模块所共用的功能抽离出来,单独形成一个系统应用。这样,一方面确保了信息来源的一致性,另一方面也简化了系统架构,避免了重复开发。比如,客户信息在销售订单管理、CRM、TMS(运输管理)等系统应用中都会用到,可以考虑合并成一个应用。

系统架构设计虽然没有标准答案,但实际上不管是传统的Oracle ERP系统,还是新兴的各大电商、SaaS系统,都有非常成熟的架构设计。多研究竞品,再结合实际情况进行适当的调整是系统架构设计的好方法。

示例如下:

从0到1了解B端产品方案+案例

在该示例中,品牌商系统主要面向年销售额50亿以上的品牌商,经销商系统主要面向年销售额2千万到1亿之间的经销商。考虑到前端业务需求差异较大且相互排斥,同时用户对产品体验和效率要求较高。为降低系统复杂度,采取了首先按企业类型划分大版本,再按业务类型划分功能模块的系统架构策略。而对于客户信息管理、商品信息管理等基础模块,考虑到业务需求差异较小且相互包容,同时也不是高频操作,为了增加可复用性,采取了共用一套模块的系统架构策略。

4、多组织架构设计

企业业务的开展,是基于多个部门的相互协同和相互监督的。当用户在使用B端系统时,流程流转、数据安全性都必须符合企业协同与管控的要求。这就需要我们设计好组织、角色和权限功能。

对于存在多事业部或分子公司的大企业,还可能需要设计多组织架构。

示例如下:

某电器公司为扩大销售规模,分别在A市和B市建立了分公司,各负责一个大区的销售工作。为便于管理和激励分公司团队,公司决定两个分公司独立核算利润,并根据实现的利润进行分红。

为支持两个分公司的独立核算,并防止数据泄露,该公司IT团队决定分别给两个分公司建立一个“利润中心组织”。在“利润中心组织”下面建立了相应的“角色”,并分配了相应的“功能”比如销售订单、发货功能等等。最后,将相应的“角色”分别分配给了两个分公司的员工。

从0到1了解B端产品方案+案例

04 结语

到这里,B端产品方案的总体方案部分,就告一段落了。下一篇,我们接着阐述以下部分:

1、详细方案

2、管理报表方案

3、集成方案

4、用户期望满足

业界动态

视频号炮灰简史

2021-7-13 10:36:52

业界动态

北京大暴雨,其实蕴含许多营销启示

2021-7-13 11:07:23

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索