关于产品,数据分析,商业的一些思考

最近,在产品设计及数据方向分析上让我踉踉跄跄,更让我对B端产品有了更深的见解。从数据分析到MVP尝试,从商业意识再到执行力。B端产品和C端产品有些类似但是却又有取舍,趁着清明雨上的时节,读了一些书,听了几次讲座,就在这里我把一些关于对产品的思考与想法分享给大家。


一、  验证产品创意

 

工作的时候,总是和我的导师有意见相左,这个就引出了一个问题,我们该如何验证自己的产品创意是否有价值,我们又该如何谨慎的决定一个产品或者一个方向的合理性。这块我栽了不少跟头,幸好有导师的帮助我才能在大部分时间保持正常的产品思维逻辑。

这里验证产品创意,借鉴之前看过的一篇产品方法论书籍就是“上下左右,古今中外”。

上下就是产业的上下游,比如要做kafka,一定要去调研kafka的上游产品有哪些,有什么开源方案底层架构是怎样的,下游是如何做消费的用户如何对接的,它的应用场景是什么。再比如,拿个通常的 C 端产品来看。想做一个音乐app,那一定要知道音乐的上游供应商都有哪些是个人厂牌居多还是唱片公司居多,这个app面向的对象都是谁,目标客户是谁。

左右就是行业环境,比如要在云端做kafka,你的竞争对手可能就不止是 Confluent ,可能是其他消息队列比如MQ,Redis等等。还有一些政策因素,就像 Confluent 18年宣布修改其平台部分组件的开源许可,从 Apache 2.0 切换到 Confluent Community License。这个举措会使开发kafka的成本大增,这里如何规避风险,也是比较关键的。

古今中外就是去看看广义竞品的具体情况,一个很好的例子就是微信和抖音,在两年前谁都不会想到一个即时通讯工具会和短视频app干起来。这里面最核心的就是互联网已经进入红海,用户的时间总是有限的,如何压榨用户仅存的时间就是这场战斗最关键的成败因素。套用一句老话 “打倒微信的一定不是下一个微信”。中外,这个很好理解,在套用一句老话“取其精华,去其糟粕”。

这里,还有一点就是我们需要做一些关于产品的沙盘推演来帮助我们快速回溯定位问题。打个比方,现在有一个场景是这样的,需要为女朋友买个裙子:

所有女孩都喜欢蓝色 → 女朋友是女生 → 买个蓝色的裙子

所以,这就是做沙盘推演的重要,女朋友是女生是一定的,但是最终决定买蓝色是因为所有女孩都喜欢蓝色。我们就可以很简单的推到出这里出现问题的可能是“所有女孩都喜欢蓝色”这个概念。

其实这里,验证产品的创意有很多种,可能无法穷尽,只供大家参考:

  1. 与行业内的专家深度交流:给大家举个栗子,比如现在要做微服务场景,那么我们第一件事并不是闭门造车,而是多听多看。而且这里的听我们一定不能没有做任何调研就去听,这里的看也不能仅仅是百度或者Google了几篇文章。还有一个问题是人家行业专家为什么愿意跟你聊?社交技巧固然有用,但更重要的是你能不能给对方创造价值。比如你也在某些领域有过人的见识,可以给别人带来启发和收获,那就很容易促成一段交流。还有一个是需要在跟别人交流时注意的细节,就是尽量提前有个准备,准备一些尽量具体的问题,同时对这些问题自己先有个提前思考。不要问一些大而化之又很虚的大问题,比如“你对企业服务市场怎么看”之类的纯开放式问题,尽量能用具体的小问题作为豁口,会更容易有实质性的收获。
  2. 读书,看文档:在工作中交流其实是验证想法最好的方式,和客户交流,和开发交流,和leader交流。但是仅仅只有交流是不够的。必要时应该自己去啃一些专业成体系的书籍,这点是非常必要而且实用的。可能和开发,客户交流并不会给你更多比较专业的东西,更多时候还是需要自己调研。
  3. 行业分析报告,行业资讯:像前些时间浑水对瑞幸的报告,就是我们应该重点去挖掘的报告。行业资讯很有可能是PR稿,对待检索出来的资讯,我们一定慎之又慎,这里的主观因素太多,甚至有的时候达到目标会篡改一些关键性数据。

二、  产品用户调研

 

刚刚,我们说到了 “所有女孩都喜欢蓝色” 这个例子,其实在工作中这样的例子会非常常见,所以我们一定会有一个步骤是做用户调研。从用户调研的结果来论证我们的沙盘推演是错的。下面是一些做用户调研的一些想法与方法:

  1. 搞清楚要做什么:根据调研目标,去进行拆解,设计具体的调研过程大纲,再基于这个大纲来设计问题。这个是基本功。
  2. 保证独立客观及流畅性:在设计问卷的时候经常会犯的一个错误是直接将问题目标转换成问题,换句话说,就是以问题的形式描述问题的目标。以SCF为例,对SCF做调研我们可能会去切在SCF这个产品下用户会不会拿它做WEB服务。这里很多人就会设计成,“你会不会拿faas服务搭网站”,这样做很少行得通,反倒投射出一种不负责任的态度。独立客观性,这个相当重要,就像我之前提的例子,其实我们已经假设了用户会拿Faas搭网站,所以我们在潜意识里给到用户的答案是我确定会拿这个东西干这件事。用户会有意无意地试图美化自己,迎合调研者;而调研者的小企图,往往就藏在这一句带有假设的问题里。这样的结果并不客观。更聪明的做法是给给到用户具体的选项,让用户选择常用搭web的方式,里面有Faas,这样的调研才是真正有效的调研。
  3. 不要相信问卷:回答问题的时候用户可能真的是那样想的,但身体却很诚实,不一定会像说的一样去行动,所以有时观察用户的行为会比单纯地询问他的想法更准确。能用整体行为数据做推测的,就不做可用性测试,能做可用性测试的,就不用调查问卷。

三、  MVP试点调研

 

在工作中,我们总是被大而全的方案给吸引,但是这里应该更冷静或者更谨慎的思考,做一些类似MVP的试点调研。MVP 是最小可用产品(Minimum Viable Product)的首字母缩写,意思是:剧烈缩减产品范围,用最少的资源构建出符合预期的最小功能集合并投入验证。

这里给我比较深刻的例子是这样的:维珍航空计划在自己的机上娱乐系统中加入一个新功能,为了测试乘客是否真的会对这个功能产生兴趣,设计人员在还没有设计任何功能的情况下,就向菜单中添加了一个入口按钮。如果真的有乘客点到了这个按钮,系统会显示:“该功能尚未完成,或许下一次搭乘维珍航空的班机时你就可以使用它了。”通过这个按钮的点击率数据,来验证用户动机和需求。类似的快速验证案例有很多,比如微信在刚改版订阅号展示方式时,长按订阅号文章会弹出菜单“未完成的功能”。又或者前些日子在朋友圈看到的一个案例,某软件的“设置”菜单点击后没有任何可设置项,而是弹出一个表单,向用户询问,他希望在这里设置什么。类似的 MVP 设计是最常见,也是最容易实施的,它的目的是验证用户动机或习惯,它甚至不考虑解决方案,而是用最少的资源去验证场景是否存在。这应该是所有产品创意和产品设计的逻辑起点,也是用户转化漏斗的开口。打个正在做的项目,kafka connect,验证这个场景的最快方式是加一个通用模板的入口,而不是刚开始就大而全的铺开。这个道理也是我工作中的导师给我最关键的指引。

在设计最小可用产品之前,一定要想清楚自己想验证的问题,要收集哪些数据项,还有这些数据项可能出现的结果,以及不同结果代表的结论。当然做最小可用产品必然会涉及裁剪,一个产品要能够完整提供服务,就需要有很多特性,那裁什么呢?答案是尽量裁掉短板,把资源放到长板上。比如类似 Instagram 要做 MVP 测试,它的核心优势,也就是它的长板是与众不同的图片分享体验。那就意味着它的评论功能、用户管理功能等等都不重要,有资源就做到及格,没资源的话即便不及格也不会受到太多影响。

MVP 并不是唯一正确的方法论,很多人对 MVP 和精益思想提出过不同意见,其中包括 PayPal 的创始人 Peter Thiel,在他的书《从 0 到 1》中,他很不客气地批评精益思想只不过是缺乏规划的托辞,最多是帮助创业者进行一些小修小补的把戏。


四、  数据分析

 

这时我们可以通过一些第三方数据工具,看一下宏观指标,比如日活、用户新增、留存等。另外也会看一下收入情况,比如总收入、总订单笔数等等。

这里我们需要找两个东西来作参考:

第一个是纵向数据,另一个是横向数据。

纵向数据来自我们产品内部,比如我们在前面关于增长的分享中曾经介绍过的,如果我们可以推算出平均一个用户可以给我们带来多少收入或利润,我们就很容易判断我们能接受的获客成本上限。另外,我们还需要跟产品的现状做对比,比如我们摆脱对搜索引擎流量的依赖,那我们的获客效率和成本,还有留存情况应当至少不低于搜索引擎当前的指标。还要考虑我们可能投入的各种资源成本,如果成本很低,这些指标要求可以相应低一点,毕竟我们的任务就是保证公司投入的任何资源都值回票价。我们在未来的商业产品部分还会进一步去分析这些指标和具体的计算方法,在这里你应当记住的是,我们定的每一个数字,都应当是有逻辑的,能被讲出原因的。

当然,有时这个数字也可能来自于外部的对比,这就是第二种数据参考,也就是横向数据。横向数据来自类似产品,或来自渠道。我们之前在做产品设计目标的时候经常会去参考同类产品或相关渠道的指标做推算,比如小程序大概的获客成本是一个授权 1.2 – 1.5,次留平均做到 40% 以上就算优秀了,等等。这些数据从哪里来呢?上文中也有些到一些,比如财报(很多财报里会公布这些关键数据,或可以推算出这些数据),比如行业研究数据报告。当然还有个重要渠道,就是同行同事朋友,对于一些不敏感的数据,有时候可以互相有一些交流。当然还有一个就是凭经验,如果做了很多产品,大概什么样的东西能做出什么样的数据,应该能大概心里有数。这其实也是资深产品经理和我这样的初入行产品经理的一个显著的能力差异,就是心里有没有足够多的数据标尺。比如我可能还在努力优化某个产品方向,但我的导师一看就知道这个产品方向到天花板了,那就赶紧做别的。


五、  商业

 

这部分内容我知之甚少,大部都是从相关书籍中总结而来的,放到这里也算给自己一个备份。

定价空间:定价与成本无关。 这听起来有点违反常识,毕竟典型的定价思路是算出成本,然后加上我们想要赚取的合理利润,然后得出一个数字。但是事实上,定价的本质只与市场竞争和用户预期有关,尤其对于互联网行业来说,我们不是用自己的成本去向市场交出定价。而是从市场领回定价,再向自己的成本控制能力拷问盈利空间。换句话说,我们做事情的逻辑不是把东西设计好,定好价,然后拿到市场上去看能不能卖出去;而是去市场上看看某个东西可以卖多少钱,然后回到家里看看自己花多少钱能做出来,有没有的赚。

市场规模:市场规模决定了是否存在可能的扩展空间。在这里我们要先知道一个概念,叫做 TAM,TAM 指的是 Total Addressable Market ,也就是“潜在市场范围”,即产品理论上你的产品模式可能覆盖到的消费者人群范围。

作为一个刚刚摸到门槛的初级产品菜鸟,我能想到的也只有这些,希望可以给到大家一些想法和建议。总的来看一个产品的功能,可能来自于运营活动的沉淀,一处工程架构的设计,甚至是产品的发展方向。产品经理的工作方式更不能是“我的部分做完了,其他的事情我不管”。

三言两语,听得则罢了,也不作数,只是现阶段对产品的一些思考。可能下一篇博文就会把这一篇博文的结论推倒把。

希望给大家一些启发。