从0到1的B端产品方案,10年老兵的经验和总结

3 评论 7339 浏览 32 收藏 12 分钟

编辑导语:对于一名B端产品经理来说,如何写好B端产品方案是一个重要的技能。一方面,能够给公司及客户高层进行有效汇报,另一方面也有利于同事之间相互了解工作,提供沟通与协作效率。作者总结了10年的工作经验和总结,与你分享。

上一篇,我们讲了从0到1设计B端产品的总体方案。有兴趣的朋友可以阅读我的《5000字长文:B端产品从0到1,产品方案+案例》。

今天,我们继续讲详细方案,并且分析产品经理如何培养自己的方案能力。

一、 详细方案的结构和要点

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

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

对于大的B端产品,详细方案可能需要分解给多个产品经理完成。

对于一个完整的详细方案,需要包括以下内容:

  1. 需求分析
  2. 明确成功指标
  3. 方案要点说明
  4. 方案流程
  5. 原型图
  6. 接下来我们逐个阐述。

二 、需求分析

虽然在业务调研部分,我们已经对详细需求进行过分析,但是考虑到合理的需求是成功产品的基石,另外,也考虑到需要给开发、测试等部门承诺需求的可靠性。因此,我们可以在详细方案中对需求的合理性进行阐述。

除了对重点需求的描述,我们还需要明确三点:

  1. 是不是伪需求
  2. 是不是当前版本需求
  3. 是不是个性化需求

对于伪需求,需要我们秉持“究竟精神”,多问几个为什么。另外,有一些需求可能是真需求,但价值很低,需要综合考量以评估优先级

比如,客户可能希望在发货时,给订单对应的销售人员发送一条短信,告知订单已发货。但你可以告知客户,一条短信需要支付8分钱,客户如果明确表示不愿意支付,那么这样的需求可能就属于低价值需求了。

如果是0到1 的项目,当前版本需求是指:如果不满足这个需求,客户就无法走完整个流程,或者体验和效率存在明显缺陷。对于没有纳入当前版本的重要需求,我们也需要记录下来,便于从整体上对架构进行设计

比如,如果我们计划将产品扩展到财务核算模块,或者与专业财务系统打通,产品架构和技术架构设计就可以提前进行准备。

如果是SaaS产品,且面对大客户,则可能需要满足一些“个性化需求”。

首先,我们必须承认,所谓个性化需求往往都是“产品能力不足”造成的。因为运营和管理本身就是个性化的,毕竟每个企业都要面对不同的内外部环境(包括政治环境),因此大部分个性化需求都是合理的。

对于个性化需求,短期来说,需要做好低耦合的设计:即将个性化的功能做成可配置,这样就不会影响其他客户的使用。长期来说,我们需要完善产品的PaaS能力。只有能满足大多数“个性化需求”的SaaS产品,才能低成本、高效率满足大客户的需求。

比如,对于个性化报表需求,短期来说,我们可以做成单独的应用,完全和其他客户的应用隔离开。长期来说,我们可以研发BI报表平台,通过配置来满足客户需求。

三、 明确成功指标

所有的B端产品或功能,都有成功指标。成功指标不但可以衡量工作成果,更重要的是,通过明确和拆分成功指标,我们可以找到让产品变得更好的方法。

比如,对于“供应商自主上传商品”的功能,如果目标是减轻运营负担和增加商品上架速度,那么“上传商品数”、“商品上传成功率”都是重要的成功指标。

如果商品上传成功率偏低,或者商品数据质量不高,我们就必须分析原因并找到改善方法。比如,如果上传的条码数据错误率很高,我们就可以在上传流程中接入第三方服务对条码进行验证。

而对于SaaS产品,“活跃用户数”是一个通用指标。不过,有时候活跃并不能反映用户粘性。比如,如果用户使用的只是“打卡”、“日报”这类相对浅显的功能,那么用户的活跃质量可能并不高。只有用户通过SaaS产品来管理核心业务,比如销售订单、发货单等,这样的活跃才是有质量的。

因此,我们可以考虑使用“核心功能使用率”、“核心单据数量”等作为成功指标

关于SaaS产品的指标分析,可以阅读我的原创《不懂这些指标,你就做不出优秀的SaaS产品。附案例》

四、方案要点说明

B端产品虽然体现为业务流程,但是真正解决用户痛点的,可能是其中几个功能。因此,在方案要点部分,我们需要对这些功能特性进行说明,以便于大家明确产品重点,确保关键功能的研发质量。

比如,在快消品行业中,及时了解各品牌的铺货数据,对于了解行业竞争动态,以及我方铺货质量非常重要。比如在便利店冰柜中,最外面一排一共有42个位置,如果百事可乐占据了21个位置,那么它的排面占有率就达到了50%。

如果不考虑其他因素,我们可以粗略认为客户有50%的概率会购买百事可乐。在以前,一个冰柜被哪些品牌占据,以及这些品牌分别占据了多少位置,需要由业务员在门店拜访时人工识别并手工录入,工作量非常大。

而我们的SFA(销售自动化)产品则提供了图像识别功能,通过拍照就可以识别品牌和排面占有率,从而大大减轻业务员工作量。

毫无疑问,图像识别功能将是门店拜访流程中的关键功能,需要我们在详细方案中重点说明,并将“识别成功率”作为关键指标。研发和测试同学也需要对图像识别功能重点关注,并确保满足指标要求。

五、方案流程图

一般来说,如果是0到1的产品,方案流程图是必要的。但如果是后续的小迭代,方案流程图则可以省略。

好的方案流程图,应该是从角色和行为两个维度,清晰、完整的对整个业务流程进行阐述。这样不管是开发同学,还是测试同学,都能够快速对所负责的功能流程有一个清晰完整的认识。如下图:

XX公司库存盘点流程

六、原型图

原型图是产品详细方案的主体部分,也是直接决定产品研发质量的部分。因此我个人认为,对于B端产品,原型图的页面和注释应该尽可能的详细。原因有如下几点:

1. 便于梳理思路

B端产品非常强调流程和交互的逻辑性,一旦考虑不周,小则影响用户体验,大则影响正常业务,甚至导致用户投诉。

做原型图的过程,其实就是我们梳理思路的过程。当我们把每一个新的交互都画出来,并且描述清楚相关逻辑,我们总是能发现自己的一些疏漏。

2. 便于与开发和测试协作

好的原型图,应该是方案评审以后,开发和测试都能独立完成自己的工作。我做产品经理的时候,开发和测试很少来找我沟通产品细节,就是因为他们总是能在原型图上找到答案。

这样一方面是大家的效率都很高,另一方面是,也最大程度上规避了口头沟通导致的bug。

3. 便于与其他产品经理协作

随着产品越来越大,我们难免需要把部分工作交接给其他同事,或者有新同事入职,你需要给他介绍当前的产品逻辑。如果你有一个详细的原型图,就可以减少很多不必要的沟通。

另外,我画原型图的时候,喜欢把历史版本都归集在一个原型文档,这样非常便于追溯。当然,前提是我们要做好版本更新记录,如下图是一个报表功能的版本更新记录:

七、如何培养方案能力

方案能力实际上是一种综合能力,培养的难点是架构能力和商业思维。当然,交互设计等能力也很重要,但是相对来说,这些能力培养起来相对容易得多。

关于产品经理的架构能力和商业思维,大家可以阅读我的文章:

  • 《我的实践:如何提升B端产品架构能力》
  • 《成熟的B端产品经理,都有这个能力》

如果我们想快速具备架构能力和商业思维,最关键的是要持续学习。包括向客户学、向对手学、向先进学和向自己学。具体学习方法,大家可以阅读我的文章:《这几个能力决定B端产品成败,你有吗?》

#专栏作家#

王戴明,微信公众号:To B老人家,人人都是产品经理专栏作家,多年互联网产品与信息化管理经验。

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

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 但是原型画的再好,注释在详细免不了开发不看还是问问问。并且画高保真原型和做好好的交互,是比较浪费时间的。

    回复
  2. 低保真+注释

    来自四川 回复
    1. 赞同

      来自北京 回复